GB2539266A

GB2539266A - Generation, configuration and authentication of a temporary code

Info

Publication number: GB2539266A
Application number: GB1510315.3A
Authority: GB
Inventors: Taylor David; French George
Original assignee: Barclays Bank PLC
Current assignee: Barclays Bank PLC
Priority date: 2015-06-12
Filing date: 2015-06-12
Publication date: 2016-12-14
Also published as: GB201510315D0

Abstract

Methods for generating temporary codes such as a Dynamic Card Security Code (DCSC) or Dynamic Card Verification Value (CVV) are disclosed. One method is for generating a temporary code by an electronic device 100 and comprises obtaining a first value that changes periodically with a first period; receiving an adjustment indicator for setting a second period; generating, using at least the adjustment indicator and the first value, a second value that changes periodically with the second period, wherein the second period is greater than or equal to the first period; and generating the temporary code based at least in part on the second value. The adjustment indicator may be received from a payment terminal and is considered to address clock-drift. Another method for generating a temporary code is disclosed where a code length indicator is received at the electronic device which then generates a code to have the indicated code length. The indicator may be received from an ATM or POS and allows a certain level of security or user-friendliness to be requested on a per transaction basis.

Description

GENERATION, CONFIGURATION AND AUTHENTICATION OF A TEMPORARY CODE Technical field The present disclosure relates to methods and apparatuses for generating a temporary code, such as a Dynamic Card Security Code (DCSC), configuring an electronic device for generating a temporary code and authenticating a temporary code.

Background

Display cards are payment cards (for example, a credit card, debit card, pre-payment card, etc) that comprise a display, such as an LCD display. Display cards may be configured to generate a temporary code (TC) and display the TC on the display.

The TC may be, for example, a Dynamic Card Security Code (DCSC), such as a Dynamic Card Verification Value (DCVV2), or Card Validation Number 2 (CVN2), or Card Validation Code (CVC2), or Card Identity Number (CID), etc. The TC may be generated using a time value, such that when the time value changes, the TC changes. The time value may be taken from an internal clock on the display card, such as a quartz clock.

However, using a time value to generate a TC may cause problems in the payment authorisation process. For example, in order to authorise a payment, an authorisation entity may need to authenticate payment data comprising a TC. To do this, the authorisation entity would need to generate an authentication code that matches the TC generated by the display card. The authorisation entity would thus need to generate the authentication code using the same time value that the display card used to generate the TC. Thus, the clock used by the authorisation entity will need to be synchronised with the internal clock on the display card. This may be difficult to achieve for all issued display cards, particularly given that clock-drift may occur in the display card internal clock and/or the authorisation entity clock.

Furthermore, there may be a variable period of time between TC generation and authentication code generation, caused by delays in submission of the payment data comprising the TC to the authorisation entity and the processing time at the authorisation entity. This might mean that even if the display card internal clock is synchronised with the authorisation entity's clock, the authentication code may still not match the TC generated by the display card.

To try to overcome these issues, the time value used for generating the TC and authentication code may change at periodic time intervals. For example, the time value may -2 -be set to change once every 24 hours, such that the time value stays the same for a 24 hour period and then changes at the beginning of the next 24 hour period. In this way, a TC and authentication code generated in the same 24 hour window will be the same. Thus, even if the display card internal clock and the authorisation entity clock fall out of synchronisation by, say, 30 minutes (for example, due to clock drift), and the amount of time between generating the TC and generating the authentication code is two hours (for example, due to delays in submitting the payment data to the authorisation entity, etc), the authentication code should still match the TC generated by the display card.

US 2009/0271853 Al describes a transaction card configured to generate a DCVV using periodic time intervals. The DCVV is generated based on a time window (for example, 1530 is used for generating the DCVV code between 15:30:00 and ten seconds later 15:30:10).

A shorter periodic time interval (for example 1 hour, such that the time value used to generate the TC changes every hour) results in a shorter time window, and a longer periodic time interval (for example, 72 hours, such that the time value used to generate the TC changes every 72 hours) results in a longer time window. A shorter time window might have greater security than a longer time window because the generated TC will change more often. However, it may make authentication more challenging and less reliable because it is more likely that the authentication code will not match the TC due to clock-drift and/or delays in submitting the TC to the authorisation entity. The size of the periodic time interval is set at the time the display card is created (or personalised) and setting the size of the periodic time interval used by the display card will usually be a compromise between security and reliability.

Display cards may be configured to generate TCs of any length. For example, a display card may be set-up to generate a 3 digit TC (such as a DCVV), but may alternatively be set-up to generate a shorter or longer TC. A longer TC may provide greater security, but may be more difficult for users of the display card to use. The length of the TC is set at the time the display card is created (or personalised) and setting the length of TC to be generated by the display card will usually be a compromise between security and usability.

Summary

The present disclosure provides a method for an electronic device to generate a temporary code, the method comprising: obtaining a first value that changes periodically with a first period (for example, by receiving the first value from a clock internal or external to the electronic device, or by generating the first value); receiving an adjustment indicator for setting a second period; generating, using at least the adjustment indicator and the first value, a second value that changes periodically with the second period, wherein the second period is greater than (i.e., longer than) or equal to the first period; and generating the temporary code based at least in part on the second value.

A first value that changes periodically with a first period is a value (for example, a numerical value) that changes every time a first interval of time elapses. For example, a first value that counts the number of seconds that have passed since a reference point in time will change periodically with a first period, wherein the first period is one second. Likewise, a second value that changes periodically with a second period, wherein the second period is greater than or equal to the first period, is a second value (for example, a numerical value) that changes every time a second interval of time elapses, wherein the second interval of time is equal to, or longer than, the first interval of time.

The adjustment indicator is variable. Therefore, according to the method of the present disclosure, by generating the second value using at least the adjustment indicator and the first value, the second period may be changed by changing the adjustment indicator that is received by the electronic device. Thus, the electronic device may be reconfigured to generate a temporary code that changes more or less frequently by changing the adjustment indicator that is communicated to the electronic device.

Preferably, the electronic device comprises a periodic oscillator (such as a quartz oscillator), and wherein the first value is obtained at least in part from an output of the periodic oscillator. The periodic oscillator may be part of an internal clock (such as a quartz clock) on the electronic device.

The adjustment indicator may be set to a value n; and the second value may be generated by truncating the n least significant places of the first value.

Preferably, the electronic device is configured to interface with a payment network terminal, the method further comprising: receiving the adjustment indicator via the payment network terminal. In this way, existing payment network architecture and equipment may be used to configure the electronic device, thus simplifying configuration and reducing costs.

The payment network terminal may be a Point-of-Sale (POS) terminal or an Automatic Teller Machine (ATM). Alternatively, it may be any entity configured to interface with a configuration system and the electronic device, for example a mobile device such as a mobile telephone or smart phone, a tablet computer, or a card reader.

The electronic device may be configured to generate a plurality of types of temporary code and the method may further comprise receiving a Function ID indicating to which type of temporary code the adjustment indicator relates.

The electronic device may further comprise a user interface element (for example, a keypad), with which a user may identify the type of temporary code that they would like to be generated, the method further comprising: receiving an indication of the type of temporary code that the user would like to be generated and generating the second value using at least the adjustment indicator corresponding to that type of temporary code and the first value.

The method may further comprise: receiving a code length indicator; and generating the temporary code to have a length indicated by the code length indicator. The code length indicator is variable, thus the length of the code that the electronic device generates may be made shorter or longer by communicating a new code length indicator to the electronic device.

Preferably, the electronic device further comprises a display for displaying the generated temporary code, the method further comprising displaying the generated temporary code.

The present disclosure also provides an electronic device for generating a temporary code, the electronic device comprising a processor; and a memory storing a software program, wherein the software program, when executed by the processor, causes the processor to perform the method disclosed above.

Preferably, the electronic device is a payment card, such as a debit card, or credit card, or display card.

The present disclosure also provides a software program configured to perform the method disclosed above, when executed on a processor of an electronic device.

The present disclosure also provides an electronic device (for example, a payment card, such as a display card) for generating a temporary code, the electronic device comprising: a communication module configured to receive an adjustment indicator for setting a second period; and a temporary code module coupled to the communication module, the temporary code module being configured to: obtain a first value that changes periodically with a first period; generate using at least the adjustment indicator and the first value, a second value that changes periodically with the second period, wherein the second period is greater than or equal to the first period; and generate the temporary code based at least in part on the second value.

Preferably, the electronic device comprises a display for displaying the generated temporary code to a user of the electronic device. Additionally, or alternatively, the electronic device may comprise a keypad for use by a user of the electronic device to request the generation of a temporary code, wherein the temporary code module is configured to generate the temporary code in response to a request from the user.

The present disclosure also provides a method for configuring an electronic device, wherein the electronic device is configured to generate a temporary code using at least a value (for example, the second value identified above) that changes periodically, the method comprising: communicating an adjustment indicator to the electronic device, wherein the adjustment indicator sets the period (for example, the second period) with which the value changes.

The electronic device may be configured to generate the temporary code in accordance with the above disclosed method for an electronic device to generate a temporary code.

The adjustment indicator is variable, so by communicating the adjustment indictor to the electronic device, the electronic device may be reconfigured such that the temporary code that it generates changes more or less frequently.

Preferably, the adjustment indicator is communicated to the electronic device via a payment network terminal. In this way, existing payment network architecture and equipment may be used to configure the electronic device, thus simplifying configuration and reducing costs.

The payment network terminal may be a Point-of-Sale (POS) terminal or an Automatic Teller Machine (ATM).

The electronic device may be configured to generate a plurality of types of temporary code and the method may further comprise: communicating a Function ID indicating to which type of temporary code the adjustment indicator relates.

The method may further comprise: communicating a code length indicator to the electronic device, wherein the code length indicator sets the length of the temporary code generated by the electronic device. In this way, the length of temporary code generated by the electronic device may be changed by communicating a new code length indicator to the electronic device.

The present disclosure also provides a configuration system configured to perform the above disclosed method.

The present disclosure also provides a software program configured to perform the above disclosed method, when executed on a processor of a configuration system.

The present disclosure also provides a method for an authorisation system to authenticate a temporary code generated by an electronic device, the method comprising: obtaining a first value that changes periodically with a first period (for example, obtaining it from a clock internal or external to the authorisation system, or generating the first value); obtaining an adjustment indicator associated with the electronic device, wherein the adjustment indicator is for setting a second period (for example, looking up that adjustment indicator in memory in the authorisation system or elsewhere, or requesting it from an entity external to the authorisation system, such as a configuration system); generating, using at least the adjustment indicator and the first value, a second value that changes periodically with the second period, wherein the second period is greater than or equal to the first period; generating an authentication code based at least in part on the second value; and performing an authentication process on the temporary code using the authentication code.

In this way, the authorisation system may repeat the same process used by the electronic device in order to generate the authentication code. Thus, even when the electronic device is reconfigured to generate the authentication code using a new adjustment indicator, the authorisation system may use the same adjustment indicator to generate the authentication code.

The method may further comprise: obtaining a code length indicator associated with the electronic device; and generating the temporary code to have a length indicated by the code length indicator.

Thus, even when the electronic device is reconfigured to generate a temporary code of a different length, the authorisation system may use the same code length indicator to generate an authentication code of the correct length.

The present disclosure also provides an authorisation system configured to perform the method disclosed above.

The present disclosure also provides a software program configured to perform the method disclosed above.

The present disclosure also provides a system comprising the electronic device and the configuration system disclosed above, wherein the electronic device is coupled to the configuration system.

The present disclosure also provides a system comprising the configuration system and authentication system disclosed above, wherein the configuration system is coupled to the authentication system.

The present disclosure also provides a method for an electronic device to generate a temporary code, the method comprising: receiving a code length indicator; and generating the temporary code to have a length indicated by the code length indicator.

The code length indicator is variable. Thus, the length of the code that the electronic device generates may be made shorter or longer by communicating a new code length indicator to the electronic device.

Preferably, the electronic device is configured to interface with a payment network terminal, the method further comprising: receiving the code length indicator via the payment network terminal.

The electronic device may be configured to generate a plurality of types of temporary code and the method may further comprise receiving a Function ID indicating to which type of temporary code the code length indicator relates.

The present disclosure also provides an electronic device comprising: a processor; and a memory storing a software program, wherein the software program, when executed by the processor, causes the processor to perform the above disclosed method.

Preferably, the electronic device is a payment card, such as a debit card, a credit card, or display card.

Preferably, the electronic device comprises a display on which the generated temporary code is displayed. Additionally or alternatively, the electronic device may comprise a user input means, for example a keypad, using which a user may request that a temporary code is generated.

The present disclosure also provides an electronic device (for example, a payment card, such as a display card) configured to generate a temporary code, the electronic device comprising: a communication module configured to receive a code length indicator; and a temporary code module configured to generate the temporary code to have a length indicated by the code length indicator.

The present disclosure also provides a method for configuring an electronic device, wherein the electronic device is configured to generate a temporary code, the method comprising: communicating a code length indicator to the electronic device, wherein the code length indicator sets the length of the temporary code generated by the electronic device.

The code length indicator is variable. Therefore, by communicating a code length indicator to the electronic device, the electronic device may be reconfigured to change the length of temporary code that it generates.

Preferably, the code length indicator is communicated to the electronic device via a payment network terminal. By using a payment network terminal, the electronic device may be configured using existing payment network architecture and equipment.

The electronic device may be configured to generate a plurality of types of temporary code, and the method may further comprise: communicating a Function ID indicating to which type of temporary code the code length indicator relates.

The present disclosure also provides a configuration system configured to perform the method disclosed above.

The present disclosure also provides a software program configured to perform the method disclosed above, when executed on a processor of a configuration system.

The present disclosure also provides a method for an authorisation system to authenticate a temporary code generated by an electronic device, the method comprising: obtaining a code length indicator associated with the electronic device; generating an authentication code to have a length indicated by the code length indicator; and performing an authentication process on the temporary code using the authentication code.

Drawings Aspects of the present disclosure will be described, by way of example only, with reference to the following drawings, in which: Figure 1 shows a highly schematic representation of a payment card, a payment network terminal, an authorisation system and a configuration system, and an example process for configuring the payment card; Figure 2 shows a highly schematic representation of a temporary code (TC) module on the payment card of Figure 1; Figure 3 shows a highly schematic representation of the payment card of Figure 1 and an example process of generating a temporary code (TC); Figure 4 shows a highly schematic representation of a TC module on the payment card of Figure 3; Figure 5 shows an example flowchart illustrating an example method by which the TC generation module of Figure 4 generates a TC; and Figure 6 shows a representation of an example payment card in accordance with the present disclosure.

Detailed description

The present disclosure relates to temporary codes (TC) generated by electronic devices. A TC is a code that changes periodically over time. A user of an electronic device may require a TC as part of an authorisation process. For example, the authorisation process may be required in a Card Not Present (CNP) transaction (such as a mail-order transaction, or an over the telephone or internet transaction) and the required TC may be a Dynamic Card Security Code (DCSC), such as a Dynamic Card Verification Value (DCVV). Alternatively, the authorisation process may be an Identification and Validation (ID&V) process required in order to verify the identity of a user requesting access to a service, for example requesting an on-line banking log-in and/or an on-line banking financial transfer, etc, and the required TC may be an ID&V code. Alternatively, the TC may be a SIGN code, for example a hash or cryptographic signing of data, such as a transaction amount and/or reference code (for example, the account number of a payee), as part of an on-line banking financial transaction.

As part of the authorisation process, the TC may be submitted to an authorisation entity for checking. For example, where the authorisation process is part of a CNP transaction, the authorisation process may be carried out in accordance with CNP transaction standards that require a TC to be submitted by the card user or merchant to the authorisation entity (for example, via an internet portal, or mobile banking app, or Interactive Voice Response (IVR) system, etc) along with any other required authorisation data (such as card number, card expiry date, etc, etc). If the authorisation entity authenticates the TC as being correct, and if all other aspects of the authorisation process are successfully completed, the authorisation entity may signal that the authorisation process has been passed so that the transaction can take place. If the authorisation process is part of an Identification and Validation (ID&V) process, or a SIGN process, the TC may be submitted (for example, via an internet portal) to the authorisation entity (such as a bank) along with any other required authorisation data (such as user password, customer number, account number, etc). If the authorisation entity authenticates the TC as being correct, and if all other aspects of the authorisation process are successfully completed, the authorisation entity may signal that the authorisation process has been passed so that the requested service may be provided to the user.

In the present disclosure, 'periodic' and 'periodically' means 'occurring at equal intervals of time'. For example, a value that changes periodically is a value that changes at equal intervals of time.

Figures 1 shows a highly schematic representation of a payment card 100, a payment network terminal 200, an authorisation system 300 and a configuration system 400.

The payment card 100 comprises a TC module 110, a microcontroller 120, a clock 130, a keypad 140 and a display 150. The TC module 110 is configured to generate at least one type of TC (i.e., have at least one TC generation function) for at least one type of authorisation process. For example, the TC module 110 may be configured to generate a DCSC for use in a CNP transaction authorisation process and/or an ID&V code for use in an ID&V process and/or a SIGN code for use in an on-line banking transaction. The functionality of the TC module 110 is described in more detail below.

The TC module 110 may comprise at least one of: one or more processors and/or microprocessors; one or more memory elements; programmable logic; firmware; software program(s) and/or any other form of configurable system. Likewise, the microcontroller 120 may comprise at least one of: one or more processors and/or microprocessors; one or more memory elements; programmable logic; firmware; software program(s) and/or any other form of configurable system.

The clock 130 is configured to count units of time, for example minutes, seconds, milliseconds (ms), microseconds (ps) etc. The clock 130 may output a periodically incrementing number, counting units of time that have elapsed since a reference point in time, for example the number of minutes that have elapsed since 1 January 2010, or the number of seconds that have elapsed since 20 March 2009, etc. Thus, the clock 130 outputs a first value that periodically increments with a first period, the first period being, for example, one hour, or one minute, or one second, or one millisecond, or any other integer or non-integer interval of time etc. The clock 130 may be a quartz clock, or any other suitable type of periodic oscillator that can generate a first value that changes periodically with a first period.

The keypad 140 is suitable for actuation by a user of the payment card 100. The keypad 140 may be suitable for the entry of a user PIN and may comprise any number of keys, for example 10 keys, one for each digit 0-9. The keypad 140 may additionally or alternatively comprise at least one key for use by a user of the payment card 100 to indicate which type of TC they would like the payment card 100 to generate (for example, a DCSC for a CNP transaction, or an ID&V code for an ID&V process, or a SIGN code for an on-line banking transaction, etc). The keys of the keypad 140 may be any suitable type of keys, for example push-button keys and/or touch sensitive keys, etc. The display 150 is suitable for the display of a TC generated by the payment card 100. The display 150 may be any form of display, for example an LCD display, an LED display, an OLED display, a TFT display, etc. The payment card 100 may be any type of payment card, for example a debit card, credit card, prepayment card, etc. Optionally, it may additionally comprise at least one of the following elements: a battery, a magnetic strip, wireless interface elements (such as an NFC aerial and NFC interface module; and/or a Bluetooth aerial and Bluetooth interface module; -12 -and/or a Wi-Fi aerial and Wi-Fi interface module, etc), external contact terminals for interfacing with a Point Of Sale (POS) or Automatic Teller Machine (ATM), etc. Figure 2 shows a highly schematic representation of the TC module 110. The TC module 110 comprises a TC generation module 112, a communication module 114, a TC key 116 and a secure script key 118. The TC generation module 112 is configured to generate a TC in accordance with the processes described below. The communication module 114 is configured to communicate securely with the configuration system 300 via the payment network terminal 200.

Figures 1 and 2 show an example configuration process in accordance with the present

disclosure.

In Step S210, the communication module 114 communicates with the payment network terminal 200. The payment network terminal 200 may be a POS terminal, or an ATM, or any other terminal in the payment network with which the payment card 100 may interface. The communication module 114 may interface with the payment network terminal 200 in any suitable way, for example using Near Field Communication (NFC), or via chip contacts on the payment card 100 (for example, when the payment card 100 is inserted in a POS or ATM). Communications between the communication module 114 and the payment network terminal 200 may be made in accordance with any relevant standards or protocols, for example EMV standards, etc. The communication in Step S110 may be an Authorisation Request. The Authorisation Request may comprise an identifier of the payment card 100, for example a card number and/or any other unique identifier of the payment card 100.

In Step S120, the Authorisation Request is forwarded by the payment network terminal 200 to the configuration system 400 via the payment network. The configuration system 400 is responsible for maintaining and/or updating the configuration of the payment card 100 and may be, for example, an Issuer Host Platform for the payment card issuer, or any other suitable configuration entity.

The configuration system 400 comprises a secure script key corresponding to secure script key 118, such that a secure issuer script may be communicated from the configuration system 400 to the communication module 114 via the payment network terminal 200. Any security technology may be utilised for this purpose, for example symmetric or asymmetric encryption, etc. -13 -In response to the Authorisation Request, the configuration system 400 generates an Authorisation Response and a secure script. In this example aspect of the present disclosure, the secure script comprises: an adjustment indicator (Al); a code length indicator (CLI); and a Function ID. The secure script is secured by encryption using the secure script key such that the Al, CLI and Function ID may be securely communicated to the communication module 114. Details of the Al and CLI are explained in more detail below in relation to the generation of a TC.

The Function ID identifies the TC generation function of the payment card 100 to which the Al and CLI relate. For example, the TC generation function may be the generation of a DCSC for use in CNP transactions, or the generation of an ID&V code for use in an ID&V process, or the generation of a SIGN code. The Function ID might identify each of these different functions in any appropriate way, for example 1 = DCSC, 2 = ID&V, 3 = SIGN.

The secure script may comprise a single Al, a single CLI and a single Function ID. In this case, the Al would indicate an adjustment for a particular TC generation function of the payment card 100, and the CLI would indicate a code length for the same TC generation function. Alternatively, the secure script may comprise two or more adjustment indicators (Al1, Al2, etc), code length indicators (all, CLI2, etc) and Function IDs (ID1, ID2, etc). In this case, the secure script would have an adjustment indictor (Al1) and code length indictor (CLI1) for a first TC generation function (ID1) of the payment card 100, an adjustment indicator (Al2) and a code length indicator (CLI2) for a second TC generation function (ID2) of the payment card 100, an adjustment indictor (A13) and a code length indicator (CLI3) for a third TC function (ID3) of the payment card 100, etc. For example, the secure script might take the form of: [Al1, CLI1, ID1; Al2, CLI2, ID2; A13, CLI3, ID3] In Step 3130, the Authorisation Response and secure script are communicated from the configuration module 400 to the payment network terminal 200.

In Step S140, the Al and CLI (and optionally the Function ID) are communicated from the configuration module 400 to the authorisation system 300, along with an identifier of the payment card 100 (for example, the card number, or any other suitable identifier). The authorisation system 300 will store the Al and CLI (and optionally the Function ID) with an association to the identifier of the payment card 100. This is so that the authorisation system 300 can look up the Al and CLI for a particular payment card during an authentication process (as described later). The Al, CLI and identifier of the payment card 100 (and -14 -optionally the Function ID) may be stored in memory in a database in accordance with standard data storage processes.

In Step S150, the payment network terminal 200 forwards the Authorisation Response and secure script to the communication module 114. The communication module 114 may use the secure script key 118 to decrypt the secure script and obtain the Al, CLI and Function ID.

In Step S210, the secure script module 114 forwards the Al, CLI and Function ID to the TC generation module 112. The TC generation module 112 then stores the Al and CLI for the relevant TC generation function(s) that it is configured to perform. The Al and CLI may be stored, for example, in memory in the TC generation module 112, or in memory elsewhere in the TC module 110, or in memory elsewhere in the payment card 100. Thus, an Al and a CLI are set for at least one of the TC functions that the payment card 100 is configured to perform.

Whilst in the above example the payment card 100 is provided with the Al, CLI and Function ID in response to an Authorisation Request, it will be appreciated that the Al, CLI and Function ID may be provided to the payment card 100 at any suitable time. For example, the Al, CLI and Function ID may be provided at any time while the payment card 100 is connected to the payment network via the payment network terminal 200.

At any time during the life of the payment card 100, the above described process may be used to change the Al and/or CLI for one or more of the TC generation functions of the payment card 100. For example, an Al and a CLI may be set for the ID&V function using the above described process. At a later time, the Al and/or CLI for the ID&V function may be changed by providing a new Al and/or CLI to the payment card 100 in accordance with the above described process. Thus, changes may be made to the Al and/or CLI for each TC generation function that the payment card 100 is configured to perform.

Figures 3 and 4 are similar to Figures 1 and 2 respectively, but show the steps of generating a TC in accordance with the present disclosure. Figure 3 also shows a user of the payment card 100, a user device 320 and the authorisation system 300 and example steps of using the TC in an authorisation process.

In order to generate a TC, the user 310 of the payment card 100 may use the keypad 140 to select a TC generation function (for example, DCSC, ID&V, SIGN, etc). The selected TC function is communicated from the keypad 140 to the microcontroller 120 in Step S160. The selected TC generation function may be communicated using the same Function ID code described above (for example, 1 = DCSC, 2 = ID&V, 3 = SIGN), or in any other suitable way.

-15 -Optionally, the user 310 may also enter their user PIN on the keypad 140, which would then also be communicated to the microcontroller 120 in Step S160.

In Step S165, the microcontroller 120 obtains from the clock 130 the first value. As explained earlier, the first value is a value that increments periodically with a first period.

The first value may be of any suitable data size and type, for example, it may be a hex number, a decimal number, a binary number, etc. The first value may by represented by 't', wherein t has T places: t = [tT, tT-1, 4-2. * *t3, t2, t1 J Each of to to tT are places in the first value. The least significant place is to and the most significant place is t1-.

By way of example only, t may be "362439587", which indicates that 362439587 units of time (for example, seconds) have elapsed since the reference point in time. In this example: t9= 3, 4 = 6, t7 = 2, t6 = 4, t5= 3, ta = 9, t3 = 5, t2 = 8, ti = 7 T = 9 In Step S170, the microcontroller 120 communicates to the TC generation module 112 a request for a TC. The request comprises the first value and an identifier of the TC generation function selected by the user 310. Optionally, the request also comprises the user entered PIN.

Before generating the TC, the TC generation module 112 may be configured to carry out user authentication by checking that the user entered PIN is correct (if one is received and required for the TC that the user would like to generate). This may be checked in accordance with standard PIN checking processes. Additionally, or alternatively, the microcontroller 120 may be configured to carry out user authentication by checking the user entered PIN and only communicate the request for a TC if the user entered PIN is correct.

In a further alternative, in addition, or as an alternative to, the microcontroller 120 and/or TC module 110 performing user authentication, the user entered PIN may be incorporated into the TC, as described below, so that user authentication may be performed on-line.

Figure 5 is a flowchart illustrating an example method by which the TC generation module 112 generates the requested TC.

-16 -Initially, the TC generation module 112 looks up the Al and CLI corresponding to the TC generation function identified in the request for a TC (i.e., the Al and CLI that are stored in memory for the TC generation function).

In Step S310, the TC generation module 112 generates a second value using the Al and the first value. The second value is generated to increment periodically with a second period, wherein the second period is greater than or equal to the first period. The second period may be any integer or non-integer interval of time.

In this example, the Al indicates the number of least significant places of the first value to truncate in order to generate the second value. For example, if the Al is set to 3, it would indicate that the 3 least significant places of the first value, i.e., tl, t2 and t3, should be truncated in order to generate the second value. The first value may be truncated by removing the indicated least significant places, or setting the indicated least significant places to zero.

Continuing with the earlier example where the first value is 362439587, if the Al is 3, the second value will be "362439" or "362439[000]". The second period will therefore be 1000 times larger than the first period. Thus, the same second value would be generated for first values of, for example, 362439102, 362439228 and 362439910.

If the Al is set to 2, the second value would be "3624395" or "3624395[00]", and the second period will be 100 times larger than the first period. If the Al is set to 4, the second value would be "36243" or "36243[0000]", and the second period will be 10000 times larger than the first period. If the Al is 0, the second value would be "362439587", and the second period will be the same as the first period.

Thus, it can be seen that the Al indicator sets the amount by which the second period is greater than the first. A larger Al sets a longer second period and a smaller Al sets a shorter second period.

In Step S320, the TC generation module 112 generates a raw TC. The raw TC is generated by performing a cryptographic operation on the second value and optionally any other suitable data (for example, at least one of the payment card number, the account number corresponding to the payment card 100, the sort code corresponding to the payment card 1 00, the expiry date of the payment card 100, the valid from date of the payment card 100, etc) using the TC key 116. For example, the second value may be combined with the other suitable data (for example, by concatenation and/or hashing and/or XORing, etc) and then encrypted or securely hashed using the TC key 116. The generated raw TC may have any -17 -suitable data size, for example 4 to 20 bytes. The cryptographic operation may utilise any suitable cryptosystem, for example Triple DES, RSA, Elliptic Curve Cryptography (ECC), SHA-1, SHA-2, etc. By generating the raw TC using at least the second value, the raw TC will change periodically with the second period.

Optionally, the other suitable data may additionally or alternatively comprise the user entered PIN (where one has been entered and communicated to the TC generation module 112). In this way, the user entered PIN is incorporated into the raw TC (and thus also the TC, as explained below) and may therefore effectively be checked by the authorisation system 130 as part of the TC authentication process. As such, on-line user authentication may take place.

In Step S330, the TC generation module 112 generates the TC from the raw TC. The TC generation module 112 generates the TC to have a length corresponding to the CLI that it looked up earlier. The CLI indicates the number of digits that the TC should have. For example, if the CLI indicates that the TC should have a length of 3 (for example, because the CLI is set to 3) the TC will be 3 digits long (for example, 653). If the CLI indicates that the TC should have a length of 7 (for example, because the CLI is set to 7), the TC will be 7 digits long (for example, 9785112).

The TC generation module 112 may generate the TC by taking the first n digits of the raw TC, where n is the length indicated by the CLI. Alternatively, the TC generation module 112 may generate the TC by taking the last n digits of the raw TC. Alternatively, the TC generation module 112 may generate the TC by taking n digits from any other part of the raw TC. Alternatively, the TC generation module 112 may hash the raw TC to generate an output of length n, such that the output of the hashing algorithm is the TC. Regardless of the way in which the TC is generated from the raw TC, the outcome of Step S330 will be a TC with length equal to the length indicated by the CLI. Because the TC is based, at least in part, on the second value (by virtue of the raw TC), the TC will change periodically with the second period. The TC will be a human readable and human usable code (for example, of suitable length to be read by, and used by, humans) and will comprise human readable characters, for example at least one number and/or letter and/or symbol, etc. In an alternative, Step S330 may be omitted and Step S320 may be configured to generate the TC based on the second value, the TC key and the CLI (and optionally any other suitable data). For example, Step S320 may be a secure hashing algorithm configured to hash the second value (and optionally any other suitable data) with the second key, wherein the length of the output hash is set to the length indicated by the CLI, such that the output hash -18 -is the TC. Again, because the TC is based, at least in part, on the second value, the TC will change periodically with the second period.

In Step S180, the TC is communicated by the TC generation module 112 to the microcontroller 120. In Step S190, the TC is communicated by the microcontroller 120 to the display 150. The TC is then displayed on the display 150.

The user 310 of the payment card 100 will thus be presented with the requested TC, which they may use as part of an authorisation process.

For example, as part of a GNP transaction authorisation process, the user 310 will be asked for various payment card 100 details. The requested details might include a DCSC. By selecting DCSC using the keypad 140, the TC displayed on the display 150 will be a DCSC.

Alternatively, a user may be requesting a service, for example an on-line banking log-in or an on-line financial transfer, and might be asked for an ID&V code or a SIGN code. By selecting ID&V or SIGN using the keypad 140, the TC displayed on the display 150 will be an ID&V code or SIGN code.

In Step S340 shown in Figure 3, the requested TC is entered by the user into the user device 320. The user device 320 may be electronic device using which the TC can be submitted to the authorisation system 300 as part of an authorisation process. For example, it may be a desktop or laptop computer, or a mobile device such as a tablet computer or mobile telephone or smart phone, whereby the TC is submitted via a web-portal or software application. Alternatively, the user device 320 may be a telephone (such as a fixed-line telephone or a mobile telephone), whereby the TC is submitted to the authorisation system 300 using an IVR system, or it may be any other type of device that interfaces with the user 310 and the authorisation system 300 in such a way that enables the user 310 to submit a TC to the authorisation system 300.

Optionally, in Step S340, the user 310 may also submit any other data required for the authorisation process, such as at least one of the card number, card holder name, card expiry date, card valid from date, user password, customer number, etc. In Step S350, the TC and any other submitted data is forwarded to the authorisation system 300. The authorisation system 300 will generate an authentication code in order to check the TC that it has received. The authentication code will be generated in an analogous manner to that described above with reference to Figure 5. In particular, the authorisation system 300 looks up the Al and CLI corresponding to the payment card 100 (and optionally also the type of authorisation operation that the authorisation system 300 is performing, -19 -where the authorisation system 300 has also stored the Function ID). The authorisation system 300 may use any identification of the payment card 100 (for example, card number) that it has received in Step S350 in order to look up the AL and CLI, or it may look up the AL and CLI corresponding to the transaction card 100 in any other suitable way. For example, it may identify the relevant payment card 100 from knowledge of the payment card linked to the bank account that the user 310 is attempting to log-in to or use, or because the IC has been forwarded in Step S350 by a mobile banking app operating on the user device 320 and the authorisation system 300 has knowledge of which payment card is associated with the mobile banking app operating on the user device 320, or by virtue of an earlier log-in to a payment system, for example using 3-D Secure, on the user device 320, etc. As necessary, the authorisation system 300 will also look up in memory on the authorisation system 300 any other data that it requires to generate the authentication code, for example, at least one of a TC key corresponding to the payment card 100, a PIN corresponding to the payment card 100, the payment card number, the account number corresponding to the is payment card 100, the sort code corresponding to the payment card 100, the expiry date of the payment card 100, the valid from date of the payment card 100, etc. The authorisation system 300 will then generate an authentication second value using an authentication first value from an authentication clock and the Al that it has looked up (analogously to Step S310). The authentication clock may be part of the authentication system 300, or may be external to the authentication system 300, and will be at least approximately synchronised with the clock 130. However, it will be appreciated that when the second period is greater than the first period, some amount of time drift between the authentication clock and the clock 130 and/or some amount of time difference between generation of the TC and generation of the authentication code may be tolerated.

The authorisation system 300 will then generate a raw authentication code using the second value, the TC key that it has looked up (analogously to Step S320) and any other required data that it has looked up. The authorisation system 300 will then generate the authentication code from the raw authentication code and the CLI that it has looked up (analogously to Step S330).

Alternatively, the authorisation system 300 may be configured to generate the TC directly from the second value, TC key and CLI (and optionally any other suitable data), analogously to the alternative Step S320 described above in respect of Figure 5.

-20 -If the data used by the TC generation module 112 are the same as the data used by the authorisation system 300, the TC and authentication code should be the same. In this instance, the TC will have been successfully authenticated by the authorisation system 300 and any remaining procedures in the authorisation process may continue. Optionally, if authorisation is successful, an indication of success may be communicated to the user device 320 in Step S360 so that the user 310 may be notified.

If the authentication code is different to the TC, the TC will be considered not authentic and authentication will have failed. The authorisation process may then be terminated by the authorisation system 300 in accordance with its standard procedures. Optionally, an indication of failure may be communicated to the user device 320 in Step S360 so that the user may be notified. The user may optionally be given the opportunity to submit at least one further TC.

In the example where a user entered PIN has been used by the TC generation module 112 in generating the TC, if the user entered PIN does not match the PIN corresponding to the payment card 100 (i.e., the PIN that the authorisation system 300 has looked up), authentication will fail. In this instance, therefore, on-line user authentication is effectively performed by the authorisation system 300. However, the authentication code may be different to the TC only because the second value used by the TC generation module 112 was different to the authentication second value. This may simply be a result of the way in which the second value and authentication second value are generated. For example, the first value could be 555891 and the second value used to generate the TC be 5558[00]. The authentication second value could be 555913 (for example, as a result of clock drift between the clock 130 and the authentication clock and/or due to a period of time passing between generating the TC at the payment card 100 and generating the authentication code at the authorisation system 300) and the authentication second value be 5559[00]. In this example, the TC would be different to the authentication code, even if all other data used to generate the TC and authentication code were correct. Therefore, the authorisation system 300 may be configured to generate at least one further authentication code using at least one further authentication second value before considering authentication to have failed.

In the example above where the authentication second value was 5559[00], the authorisation system 300 may deduct 1 unit from the authentication second value (i.e., 5558[00]) and generate a further authentication code. The further authentication code should then match the TC, and the TC will have been successfully authenticated. If the further authentication code does not match the TC, the authorisation system 300 may be -21 -configured to consider the TC to be not authentic, or to generate an even further authentication code by repeating the above process (i.e., using 5557[00]). Additionally, or alternatively, the authorisation system 300 may generate an even further authentication code by repeating the above process, but add 1 unit to the authentication send value (in this example, 5560[00]), to account for the possibility that due to clock drift the first value is ahead of the authentication first value 0.e., for example, the first value is 556002 and the second value is 5560[00], and the authentication first value is 555998 and the authentication second value is 5559[00]). In any event, the authorisation system 300 may be configured to generate at least one further authentication code before considering the authentication process to have failed.

As previously explained, the Al and CLI used by the payment card 100 to generate a TC may be changed over the life-time of the payment card 100. It can be seen that by changing the Al, the second period can be changed, which affects how frequently the TC changes (i.e., the shorter the second period, the more often the TC will change).

The more frequently the TC changes, the less reliable it may be because it becomes more likely that the authentication code will not correctly match due to clock-drift and/or time differences between generating the TC and generating the authentication code. However, because each TC will be valid for less time, they will be more secure. Thus, setting the second period is a compromise between security and reliability.

Likewise, changing the CLI will change the length of TC generated by the TC generation module 112. Longer TCs may be more secure, but more difficult for users to use. Thus, setting the TC length is a compromise between security and usability.

Over the life of a payment card 100, the requirements of users and/or card issuers and/or authorisation systems may change, for example requiring a greater level of security or requiring a greater level of reliability or a greater level of usability. By using a variable Al and CLI to generate the TC and authentication code, it is possible to change the second period and/or code length to meet the changing requirements of users and/or card issuers and/or authorisation systems, without having to recall all issued payment cards and issue new payment cards, which is time consuming and costly. Thus, the present disclosure provides increased flexibility in the way in which payment cards generate TCs.

Furthermore, by configuring payment cards and authorisation systems in accordance with the present disclosure, payment cards may be reconfigured on a card-by-card, ad-hoc basis. For example, some payment cards 100 may be configured to have a shorter second period -22 -and/or longer code length because they are typically being used for more security critical purposes, whilst other payment cards 100 may be configured to have a longer second period and/or shorter code length because reliability and/or usability is typically more important for the ways in which those cards are being used. Thus, there is no need for all distributed cards to have the second period and code length, which increases the flexibility of the payment cards and the authorisation system.

Furthermore, if a decision is made that the second period and/or code length of a large number of payment cards should be changed, by reconfiguring the payment cards and authorisation system(s) in accordance with the present disclosure, the payment cards may be reconfigured on a card-by-card, ad-hoc basis, as and when they connect to the payment network. This is because each payment card 100 may have a different Al and/or CLI to other payment cards, but the authentication process still work as the authorisation system 300 can obtain the Al and/or CLI corresponding to each payment card. Thus, there is no need for all payment cards and authentication system(s) to be reconfigured at exactly the same time. This simplifies the reconfiguration process and makes it more efficient and cost-effective.

Furthermore, by configuring the payment card 100 using the existing payment network, it is not necessary to install new hardware or specialised procedures. Instead, existing payment network hardware (such as POSs, ATMs and configuration systems) may be utilised alongside existing procedures, such as issuer script processing, in order to configure the payment cards. Thus, configuration of the payment card 100 is made even more straightforward and even lower cost.

Figure 6 shows an example representation of a payment card 100 in accordance with the present disclosure. The front face 605 of the payment card 100 comprises a card number 610, a valid from date 615, an expiry date 620, a card holder name 625, a payment chip contacts 630 and a name of the card provider 635. The rear face 650 of the payment card 100 comprises a magnetic strip 655, a signature strip 660, the keypad 140 and the display 150.

Various alternatives to the above aspects of the present disclosure may be readily 30 appreciated.

For example, the payment card 100 may alternatively be any type of electronic device configured to generate a TC in accordance with the present disclosure. By way of example, the electronic device could be a smart card, a TC generating fob, a security token, a card -23 -reader (for example, a home card reader suitable for interfacing with a payment card), etc. The electronic device 100 may be a normally unconnected device, meaning that the device is not normally connected to the payment network, or any other network. The electronic device 100 will therefore only be able to send and receive data in Steps 5110 and S150 at times when it is connected to the payment network via the payment network terminal 200.

In the configuration process described above with reference to Figures 1 and 2, rather than interfacing with the payment network terminal 200 via NFC or chip contacts on the payment card 100, the payment card 100 may interface with the payment network terminal 200 via any suitable means, for example via Bluetooth, Wi-Fi, mobile data networks, such as 2G, 3G, 4G, etc. Thus, it can be seen that the payment network terminal 200 may be any entity through which the configuration system 300 and communication module 114 may communicate. For example, the payment network terminal 200 may be a consumer device such as a mobile telephone, a smart phone, a wearable device, a tablet computer, a desktop or laptop computer, a card reader, etc, that is configured to interface with the payment card 100 (for example, by physical connection, or NFC, or Bluetooth, etc) and with the configuration system 300 (for example, over the internet using a wired or wireless connection, etc).

In Figures 1 and 3, the payment network terminal 200, configuration system 400 and authorisation system 300 are shown as separate entities. However, any two or more of these may form a single system. For example, the configuration system 400 and authorisation system 300 may be a single system (for example a card issuer system) and/or the payment network terminal 200 and configuration system 400 may be a single system, etc. The authorisation system 300 and/or configuration system 400 may be a module or component or discrete system within a larger system, for example a software program or script within a banking system or payment system, etc. Furthermore, the payment network terminal 200, configuration system 400 and authorisation system 300 are each represented as single entities. However, one or each of the payment network terminal 200, configuration system 400 and authorisation system 300 may comprise two or more entities, each of which may be co-located or located in different geographical locations. For example, the authorisation system 300 may comprise an authentication code generation entity (such as a server, or a module or component or discrete system within a larger system, such as a payment system or a banking system), configured to generate the authentication code as described above, and a separate database, for example a Hardware -24 -Security Module (HSM), for storing at least one of the Al, CLI, payment card identifier, TC key, etc. Thus, each of the payment network terminal 200, configuration system 400 and authorisation system 300 may comprise one or more electronic devices, such as servers, configured to perform the processes described above. Thus, it can be seen that the payment network terminal 200, configuration system 400 and authorisation system 300 may be implemented in any suitable way.

The authorisation system 300 may be configured to perform an authorisation process that includes only the TC authentication described above, such that if authentication is passed, the authorisation process is passed. Alternatively, it may be configured to perform one or more further processes as part of the authentication process.

The payment card 100 may optionally not comprise a keypad 140. For example, the payment card 100 may be configured to have a single TC generation function and always display the generated TC (in which case, the generated TC would periodically change as the second value changes). Alternatively, the payment card 100 may have a single key and be configured to generate and display a TC on actuation of the key by a user.

In the above example, the user may enter a user PIN via the keypad 140. However, additionally or alternatively, any other form of user authentication may be used. For example, the payment card 100 may comprise a biometric input module, such as a fingerprint reader or iris scanner, which may be used by the user to input biometric data.

The biometric data may then be used by the microcontroller 120 and/or TC module 110 to carry out user authentication, or the biometric data may be used in generating the TC so that on-line user authentication is carried out, as an alternative to, or in addition to, the above described uses of the user entered PIN.

The payment card 100 may optionally not comprise a display 150. The TC may be output from the payment card 100 by any other suitable means, in addition to or as an alternative to using the display 150. For example, it may be output aurally via a speaker built in to the payment card 100, or as data output to a further electronic device (for example, some form of card reader) which can then submit the TC to the authorisation system 300 and/or display the TC to the user, etc. In the above, the first value periodically increments. However, the first value may periodically change in any way, for example, it may periodically decrease. The first value may be any type of value that periodically changes. In the above example, the first value is a count of the number of units of time that have passed since a reference point in time.

-25 -However, the first value could alternatively be the time (for example hours:minutes:seconds day/month/year, such as 15:23:43 23/06/2008).

Likewise, the Al may be any form of indicator that instructs the TC generation module 112 how to obtain a second value with second period from the first value. For example, if the first value is the time, the Al might indicate that the second period is 10 minutes, such that the TC generation module will use the first value and Al to generate a second value that changes every ten minutes. In a further example, the Al might indicate that the second value should periodically change once for every 15, or 40, or 890, etc, etc, changes of the first value.

It can therefore be seen that the first value, second value and Al may take any suitable form that results in the TC generation module 120 generating a second value that changes periodically with a second period, wherein the second period is greater than or equal to the first period.

In the above description, the first value is obtained directly from the clock 130. However, in an alternative, the first value may be generated by the microcontroller 120 or TC module 110 (or any other suitable module on the payment card 100) using at least the output of the clock 130. For example, the clock may output a time (for example hours:minutes:seconds day/month/year, such as 15:23:43 23/06/2008) that changes with the first period (for example, the first period is one second) and the microcontroller 120 or TC module 110 may generate the first value using the time from the clock (for example, the first value may count the number of seconds from a predetermine point in time). Alternatively, the clock 130 may simply output a periodic signal or pulse (for example, the output of a periodic oscillator). The microcontroller 120 or TC module 110 (or any other suitable module on the payment card 100) may then generate the first value using the periodic signal or pulse (for example, counting the number of pulses from a reference point in time).

In a further alternative, the payment card 100 may not comprise a clock 130. Instead, the payment card 100 may obtain a first value by receiving the first value, or data from which it can generate a first value, from an external source, for example a GPS clock signal.

It will be appreciated that the authentication clock may have corresponding alternatives.

The microcontroller 120 and TC module 110 may be combined into a single module that is configured to perform the above described processes. Alternatively, the functionality of at least one of the microcontroller 120 and/or TC module may be performed by two or more different, coupled modules within the payment card 100.

-26 -Likewise, in the above description, the TC module 110 comprises a TC generation module 112 and a communication module 114. However, the functionality of the TC generation module 112 and a communication module 114 may be performed by a single module. Alternatively, the functionality of the TC generation module 112 and/or the communication module 114 may be performed by two or more different, coupled modules within the payment card 100.

The above described payment card processes and/or authentication system processes and/or configuration system processes may be performed by one or more processors on the payment card 100 and/or authorisation system 300 and/or configuration system 400 respectively, by virtue of a software program stored in memory on the payment card 100 and/or authorisation system 300 and/or configuration system 400 respectively being executed on the processor(s).

In the above description, the TC module 118 and the configuration system 400 comprise secure script keys for encrypting and decrypting the secure script data. However, it will be appreciated that the secure script data (i.e., the Al, CLI and Function ID) may not be encrypted/decrypted with secure script keys. For example, they may be sent in the clear. Thus, the TC module 110 and configuration system 400 may optionally not comprise secure script keys.

An example method of generating the TC is described above with reference to Figure 5.

However, it will be appreciated that the TC and authentication code may be generated in any suitable way using the first value, Al and CLI. For example, the second value may be generated using the first value and Al in any suitable way so that the second value changes periodically with a second period, wherein the second period is greater than or equal to the first period. The TC may then be directly generated from the second value, for example by combining (for example concatenating, XORing, hashing, etc) the second value with one or more other data and/or encrypting the second value with the TC key in such a way as to generate a TC of length n (where n is the length of code identified by the CLI), or setting the TC to be the first or last n places of the second value, or performing any other operation on the second value that results in a TC of length equal to the length indicated by the CLI. The same applies for the authentication code.

In a further alternative, the payment card 100 may be configured to receive only the Al and Function ID, or only the CLI and Function ID, from the configuration system 400. For example, the TC generation module 112 may be configured always to generate a TC of the same length, such that the TC length is not variable. Thus, the second period would be -27 -variable by virtue of the Al, but the code length would be fixed so there would be no need to communicate a CLI to the payment card 100. Alternatively, the TC generation module 112 may be configured to generate a TC that changes with the same, fixed period (for example, generating a TC based on the first value), such that the frequency with which the TC changes is not variable. Thus, the length of the TC would be variable by virtue of the CLI, but the frequency of change would be fixed so there would be no need to communicate an Al to the payment card 100. The same applies to the authorisation system 300 with respect to the authentication code.

In a further alternative, the payment card 100 may be configured to perform only one TC generation function, or have only one TC generation function for which the code length and/or frequency of change are variable. In this case, the payment card 100 may be configured to receive the Al and CLI, or Al only, or CLI only, without any Function ID, since those data will only ever apply to the one adjustable TC generation function that the payment card 100 is configured to perform.

The authorisation system 300 may be configured for use in only one type of authorisation process (for example, CNP transaction authorisation, or ID&V authorisation, etc), in which case it may not store a Function ID corresponding to the Al and CLI received in Step S140. Alternatively, it may be configured for use in two or more types of authorisation process, in which case it may store the Function ID received in Step S140 so that it may look up the Al and CLI corresponding to the type of TC it receives during an authorisation process.

The TC generated according to the present disclosure may be any sort of code that changes periodically, and may be suitable for use in any sort of authorisation process.

The payment card 100 may be configured to generate the TC corresponding to each different TC generation function in a different way. For example, for generating a DCSC, the second value and a TC key may be used with a hashing algorithm, but for generating an ID&V code, the second value and a customer number may be used with an encryption algorithm, etc. In the method described with reference to Figure 2, after the communication module 114 receives the secure script, it communicates the Al, CLI and Function ID to the TC generation module 112 in Step S210. However, in an alternative, it may store the Al, CLI and Function ID itself in memory and then communicate at least the Al and CLI in response to a request from the TC generation module 112 (for example, a request during the TC generation process, wherein the AL and CLI corresponding to a particular Function ID). Alternatively, -28 -the communication module 114 may share the AL, CLI and Function ID with the TC generation module 112 by storing the Al, CLI and Function ID in a memory location(s) accessible to the TC generation module 112 and optionally communicating the memory location(s) to the TC generation module 112 in Step S210 or in response to a request from the TC generation module 112.

In a further alternative, the payment card 110 may be configured to receive the Al, CLI and Function ID from an entity other than the payment network terminal 200. For example, the user may manually enter the Al, CLI and Function ID via the keypad 140 in response to an instruction communicated to them from the configuration system 400 (for example, communicated to them via SMS or email, etc).

In the authorisation process represented by Steps S340 to S360 in Figure 3, rather than the user 310 of the payment card 100 submitting the TC to the authorisation system 300 via the user device, a different entity may submit the TC to the authorisation system 300. For example, the user 310 may pass the TC to a merchant who may then submit the TC to the authorisation system 300 via a merchant terminal (for example, using a web portal, or a banking app, or an IVR system, etc). Alternatively, the user 310 may pass the TC to a call centre operator who may submit the TC to the authorisation system 300 via their terminal (for example, as part of a telephone banking authorisation process), etc. In the configuration process described above with reference to Figure 1, the Al and CLI (and optionally the Function ID) are communicated to the authorisation system 300 in Step S140.

However, alternatively, the authorisation system 300 may be preconfigured with different combinations of values for AL and CLI, and the configuration system 200 may communicate which combination has been applied to the payment card 100. For example, combination one may be Al=2 and CLI=4, combination two may be Al=2 and CLI=6, combination three may be Al=3, CLI=3, etc, etc. Thus, an identifier of the payment card 100 and the applied preconfigured combination may be communicated in Step S140.

Alternatively, Step S140 may not take place and instead the authorisation system 300 may obtain the Al and CLI during the authorisation process. For example, the authorisation system 300 may communicate with the configuration system 400 during the authorisation process and request the Al and CLI corresponding to a particular payment card 100.

Alternatively, the configuration system 400 may share the Al and CLI with the authorisation system 300 by storing the Al, CLI and an indicator of the payment card 100 in a memory location(s) accessible to the configuration system 400 (for example, in an HSM) and optionally communicate the memory location(s) to the authorisation system 300 in Step -29 -S140 or in response to a request from the authorisation system 300 for the Al and CLI corresponding to the payment card 100.

In Figures 1 and 3, communications between the different systems and entities are represented as direct communications. However, it will be appreciated that all communications may be routed in any suitable way, for example via any number of network routers and/or proxies, etc. It will be appreciated that aspects of the present disclosure may be implemented using a variety of different information processing systems. In particular, although the figures and the discussion thereof provide an exemplary computing system and methods, these are presented merely to provide a useful reference in discussing various aspects of the disclosure. It will be appreciated that the boundaries between logic blocks are merely illustrative and that alternative embodiments may merge logic blocks or elements, or may impose an alternate decomposition of functionality upon various logic blocks or elements.

It will be appreciated that the above-mentioned functionality may be implemented as one or more corresponding software modules or components. Method steps implemented in flowcharts contained herein, or as described above, may each be implemented by corresponding respective modules; multiple method steps implemented in flowcharts contained herein, or as described above, may together be implemented by a single module.

It will be appreciated that, insofar as embodiments of the invention are implemented by software (or a computer program), then a storage medium and a transmission medium carrying the computer program form aspects of the invention. The computer program may have one or more program instructions, or program code, which, when executed by a computer carries out an embodiment of the invention. The term "program" or "software" as used herein, may be a sequence of instructions designed for execution on a computer system, and may include a subroutine, a function, a procedure, a module, an object method, an object implementation, an executable application, an applet, a servlet, source code, object code, a shared library, a dynamic linked library, and/or other sequences of instructions designed for execution on a computer system. The storage medium may be a magnetic disc (such as a hard drive or a floppy disc), an optical disc (such as a CD-ROM, a DVD-ROM or a BluRay disc), or a memory (such as a ROM, a RAM, EEPROM, EPROM, Flash memory or a portable/removable memory device), etc. The transmission medium may be a communications signal, a data broadcast, a communications link between two or more electronic devices, etc.

Claims

-30 -Claims 1. A method for an electronic device to generate a temporary code, the method comprising: obtaining a first value that changes periodically with a first period; receiving an adjustment indicator for setting a second period; generating, using at least the adjustment indicator and the first value, a second value that changes periodically with the second period, wherein the second period is greater than or equal to the first period; and generating the temporary code based at least in part on the second value.
2. The method of claim 1, wherein the electronic device comprises a periodic oscillator, and wherein the first value is obtained at least in part from an output of the periodic oscillator.
3. The method of any preceding claim, wherein the adjustment indicator is set to a value n; and the second value is generated by truncating the n least significant places of the first value.
4. The method of any preceding claim, wherein the electronic device is configured to interface with a payment network terminal, the method further comprising: receiving the adjustment indicator via the payment network terminal.
5. The method of claim 4, wherein the payment network terminal is a Point-of-Sale (POS) terminal or an Automatic Teller Machine (ATM).
6. The method of any preceding claim, wherein the electronic device is configured to generate a plurality of types of temporary code, the method further comprising; receiving a Function ID indicating to which type of temporary code the adjustment indicator relates.
7. The method of any preceding claim, further comprising: receiving a code length indicator; and -31 -generating the temporary code to have a length indicated by the code length indicator.
8. An electronic device for generating a temporary code, the electronic device comprising: a processor; and a memory storing a software program, wherein the software program, when executed by the processor, causes the processor to perform the method of any preceding claim.
9. The electronic device of claim 8, wherein the electronic device is a payment card.
10. A software program configured to perform the method of any of claims 1 to 7, when executed on a processor of an electronic device.
11. A method for configuring an electronic device, wherein the electronic device is configured to generate a temporary code using at least a value that changes periodically, the method comprising: communicating an adjustment indicator to the electronic device, wherein the adjustment indicator sets the period with which the value changes.
12. The method of claim 11, wherein the adjustment indicator is communicated to the electronic device via a payment network terminal.
13. The method of claim 12, wherein the payment network terminal is a Point-of-Sale (POS) terminal or an Automatic Teller Machine (ATM).
14. The method of any of claims 11 to 13, wherein the electronic device is configured to generate a plurality of types of temporary code, the method further comprising: communicating a Function ID indicating to which type of temporary code the adjustment indicator relates.
15. The method of any of claims 11 to 14, further comprising: communicating a code length indicator to the electronic device, wherein the code length indicator sets the length of the temporary code generated by the electronic device.
16. A configuration system configured to perform the method of any of claims 11 to 15.

-32 -
17. A software program configured to perform the method of any of claims 11 to 15, when executed on a processor of a configuration system.
18. A method for an authorisation system to authenticate a temporary code generated by an electronic device, the method comprising: obtaining a first value that changes periodically with a first period; obtaining an adjustment indicator associated with the electronic device, wherein the adjustment indicator is for setting a second period; generating, using at least the adjustment indicator and the first value, a second value that changes periodically with the second period, wherein the second period is greater than or equal to the first period; generating an authentication code based at least in part on the second value; and performing an authentication process on the temporary code using the authentication code.
19. The method of claim 18, further comprising: obtaining a code length indicator associated with the electronic device; and generating the temporary code to have a length indicated by the code length indicator.
20. An authorisation system configured to perform the method of either claim 18 or claim 19.
21. A software program configured to perform the method of either claim 18 or claim 19.
22. A method for an electronic device to generate a temporary code, the method comprising: receiving a code length indicator; and generating the temporary code to have a length indicated by the code length indicator.
23. The method of claim 22, wherein the electronic device is configured to interface with a payment network terminal, the method further comprising: -33 -receiving the code length indicator via the payment network terminal.
24. The method of claim 23, wherein the payment network terminal is a Point-of-Sale (POS) terminal or an Automatic Teller Machine (ATM).
25. The method of any of claims 22 to 24, wherein the electronic device is configured to generate a plurality of types of temporary code, the method further comprising; receiving a Function ID indicating to which type of temporary code the code length indicator relates.
26. An electronic device comprising: a processor; and a memory storing a software program, wherein the software program, when executed by the processor, causes the processor to perform the method of any of claims 22 to 25.
27. The electronic device of claim 26, wherein the electronic device is a payment card.
28. A software program configured to perform the method of any of claims 22 to 25, when executed on a processor of an electronic device.
29. A method for configuring an electronic device, wherein the electronic device is configured to generate a temporary code, the method comprising: communicating a code length indicator to the electronic device, wherein the code length indicator sets the length of the temporary code generated by the electronic device.
30. The method of claim 29, wherein the code length indicator is communicated to the electronic device via a payment terminal.
31. The method of claim 30, wherein the payment network terminal is a Point-of-Sale (POS) terminal or an Automatic Teller Machine (ATM).
32. The method of any of claims 29 to 31, wherein the electronic device is configured to generate a plurality of types of temporary code, the method further comprising: communicating a Function ID indicating to which type of temporary code the code length indicator relates.
33. A configuration system configured to perform the method of any of claims 29 to 32.

-
34 - 34. A software program configured to perform the method of any of claims 29 to 32, when executed on a processor of a configuration system.
35. A method for an authorisation system to authenticate a temporary code generated by an electronic device, the method comprising: obtaining a code length indicator associated with the electronic device; generating an authentication code to have a length indicated by the code length indicator; and performing an authentication process on the temporary code using the authentication code.
36. An authorisation system configured to perform the method of claim 35.
37. A software program configured to perform the method of claim 35.Amendments to the claims have been filed as follows: Claims 1. A method for an electronic device to generate a temporary code, wherein the electronic device is configured to interface with a payment network terminal, the method comprising: obtaining a first value that changes periodically with a first period; receiving, via the payment network terminal, an adjustment indicator for setting a second period; generating, using at least the adjustment indicator and the first value, a second value that changes periodically with the second period, wherein the second period is greater than or equal to the first period, and wherein the first value continues to change periodically with the first period; and generating the temporary code based at least in part on the second value.2. The method of claim 1, wherein the electronic device comprises a periodic oscillator, and wherein the first value is obtained at least in part from an output of the periodic CO 15 oscillator.O3. The method of any preceding claim, wherein the adjustment indicator is set to a value.4. The method of any preceding claim, wherein the payment network terminal is a Point-of-Sale (POS) terminal or an Automatic Teller Machine (ATM).5. The method of any preceding claim, wherein the electronic device is configured to generate a plurality of types of temporary code, the method further comprising; receiving a Function ID indicating to which type of temporary code the adjustment indicator relates.6. The method of any preceding claim, further comprising: receiving a code length indicator; and Ovalue n; and the second value is generated by truncating the n least significant places of the first generating the temporary code to have a length indicated by the code length indicator.7. An electronic device for generating a temporary code, the electronic device comprising: a processor; and a memory storing a software program, wherein the software program, when executed by the processor, causes the processor to perform the method of any preceding claim.8. The electronic device of claim 7, wherein the electronic device is a payment card.9. A software program configured to perform the method of any of claims 1 to 6, when executed on a processor of an electronic device.10. A method for a configuration system to configure an electronic device, wherein the electronic device is configured to generate a temporary code by: obtaining a first value that (r) changes periodically; generating, using at least the adjustment indicator and the first value, a second value that changes periodically with a second period, wherein the second period is CO is greater than or equal to the first period, and wherein the first value continues to change periodically with the first period, and generate the temporary code based at least in part on C\I the second value, the method comprising: O the configuration system communicating to the electronic device, via a payment network terminal, an adjustment indicator, wherein the adjustment indicator sets the second 20 period.11. The method of claim 10, wherein the payment network terminal is a Point-of-Sale (POS) terminal or an Automatic Teller Machine (ATM).12. The method of either claim 10 or claim 11, wherein the electronic device is configured to generate a plurality of types of temporary code, the method further comprising: communicating a Function ID indicating to which type of temporary code the adjustment indicator relates.13. The method of any of claims 10 to 12, further comprising: communicating a code length indicator to the electronic device, wherein the code length indicator sets the length of the temporary code generated by the electronic device.14. A configuration system configured to perform the method of any of claims 10 to 13.15. A software program configured to perform the method of any of claims 10 to 13, when executed on a processor of a configuration system.16. A method for an authorisation system to authenticate a temporary code generated by an electronic device, the method comprising: obtaining a first value that changes periodically with a first period; obtaining an adjustment indicator associated with the electronic device, wherein the adjustment indicator is for setting a second period; generating, using at least the adjustment indicator and the first value, a second value that changes periodically with the second period, wherein the second period is greater than or equal to the first period and wherein the first value continues to change periodically with the first period; generating an authentication code based at least in pad on the second value; and performing an authentication process on the temporary code using the authenticationCO code.C\I 17. The method of claim 16, further comprising:Oobtaining a code length indicator associated with the electronic device; and generating the temporary code to have a length indicated by the code length indicator.18. An authorisation system configured to perform the method of either claim 16 or claim 17.19. A software program configured to perform the method of either claim 16 or claim 17.20. A method for an electronic device to generate a temporary code, the method comprising: receiving a code length indicator; and generating the temporary code to have a length indicated by the code length indicator.21. The method of claim 20, wherein the electronic device is configured to interface with a payment network terminal, the method further comprising: receiving the code length indicator via the payment network terminal.22. The method of claim 21, wherein the payment network terminal is a Point-of-Sale (POS) terminal or an Automatic Teller Machine (ATM).23. The method of any of claims 20 to 22, wherein the electronic device is configured to generate a plurality of types of temporary code, the method further comprising; receiving a Function ID indicating to which type of temporary code the code length indicator relates.24. An electronic device comprising: a processor; and a memory storing a software program, wherein the software program, when executed cr) by the processor, causes the processor to perform the method of any of claims 20 to 23.CO 25. The electronic device of claim 24, wherein the electronic device is a payment card.O26. A software program configured to perform the method of any of claims 20 to 23, O when executed on a processor of an electronic device.27. A method for configuring an electronic device, wherein the electronic device is configured to generate a temporary code, the method comprising: communicating a code length indicator to the electronic device, wherein the code length indicator sets the length of the temporary code generated by the electronic device.28. The method of claim 27, wherein the code length indicator is communicated to the electronic device via a payment terminal.29. The method of claim 28, wherein the payment network terminal is a Point-of-Sale (POS) terminal or an Automatic Teller Machine (ATM).30. The method of any of claims 27 to 29, wherein the electronic device is configured to generate a plurality of types of temporary code, the method further comprising: communicating a Function ID indicating to which type of temporary code the code length indicator relates.31. A configuration system configured to perform the method of any of claims 27 to 30.32. A software program configured to perform the method of any of claims 27 to 30, when executed on a processor of a configuration system.33. A method for an authorisation system to authenticate a temporary code generated by an electronic device, the method comprising: obtaining a code length indicator associated with the electronic device; generating an authentication code to have a length indicated by the code length indicator; and performing an authentication process on the temporary code using the authentication code.34. An authorisation system configured to perform the method of claim 33.35. A software program configured to perform the method of claim 33.36. A method for an electronic device to generate a temporary code substantially as co described herein with reference to the accompanying drawings.O37. An electronic device for generating a temporary code substantially as described O herein with reference to the accompanying drawings.
38. A software program for operation on an electronic device to generate a temporary code substantially as described herein with reference to the accompanying drawings.
39. A method for a configuration system to configure an electronic device substantially as described herein with reference to the accompanying drawings.
40. A software program for operation on a configuration system to configure an electronic device substantially as described herein with reference to the accompanying drawings.
41. A configuration system substantially as described herein with reference to the accompanying drawings.
42. A method for an authorisation system to authenticate a temporary code substantially as described herein with reference to the accompanying drawings.
43. A software program for operation on an authorisation system to authenticate a temporary code substantially as described herein with reference to the accompanying drawings.CDCO ('Si