The present invention relates to a validity check performed by a system which communicates using near field communicat ion with a user device having an appl icat ion stored thereon. The invent ion has particular, but not exclusive, relevance to a v alidity check of a payment appl icat ion on a user dev ice during use of the payment application to gain access to a mass transportation system. Background

It is known to use contactless smart cards to gain access to a mass transportation system. For example, Transport for London hav e enabled payment on the London public transport system using both a proprietary contactless smart card solut ion, in part administered by Transport for London, and contactless payment card solutions using EMV payment cards or other contactless payment dev ices conforming to the EMV specifications. Proximity coupling devices provided at access points to the London public transport system communicate with the contactless cards using near field communicat ion to authorise access to the London public transport system and to arrange payment of the required fare. The use of either the proprietary contactless smart card solut ion or the contactless payment dev ice solut ion has the adv antage of remov ing the need of a paper ticket being issued by a t icket ing machine.

The Transport for London proprietary smart card solut ion requires that the proprietary smart card be pre-loaded with funds to cov er payment of travel fares. Accordingly, it can be more conv enient to use the contactless payment device solution using an EMV payment device, such as a credit card or a debit card.

When using an EMV contactless payment dev ice, a number of validity checks are performed before a transaction is authorised. For the London public transport system, offl ine data authent icat ion (ODA ) is performed using a Dynamic Data Authent icat ion technique such as those defined in the EMV specifications, for example fast Dynamic Data Authenticat ion ( fDDA ) or Combined Data Authent ication (CD A ), to authenticate the contactless payment dev ice. Other mass transportation systems plan to implement similar schemes to that employed by the London public transport system in which EMV contact less payment devices can be used for gaining access to the mass transportation system. However, in many countries the capability for EMV contactless payment devices such as EMV payment cards to comply with Dynamic Data Authentication mechanisms is not universal. Accordingly, a need exists for alternative validity checks to impede attempts to gain access to the mass transportation system fraudulently.

Summary

According to a first aspect of the present invention, there is provided a system for performing a validity check of a user device having an application stored thereon, the apparatus comprising a coupling device operable to communicate with the user dev ice via near field communication, a processor, and memory storing program code for execution by the processor and validity check data. The program code comprises executable instructions to receive a determinate user device identifier from the user device via the coupling device, receive application data from the user device via the coupling device, the application data being characteristic of the application stored on the user device, process the user dev ice identifier and the application data to generate a test token, and determine whether the test token is valid using the validity check data. By linking the application data and the user device identifier in a token, checking the validity of the token provides a check that a particular combination of user dev ice identifier and application data is valid. In this way, attacks based on supplying multiple sets of application data in the aim of identifying a valid set of application is made ineffective as unless used with the correct user device identifier then the test token will not be a valid token.

The validity check data may comprise a list of valid tokens, wherein the program code comprises executable instructions to determine whether the test token is in the list of valid tokens.

The program code may comprise a first set of instructions for determining the presence of a coupling device within coupling range of the coupling device and a second set of instructions for interacting with an application stored by the user device, wherein the user device identifier is received during execution of the first set of instructions and the application data is received during execution of the second set of instructions. The first set of instructions may comprise an anti-collision process in case of the presence of mult iple user devices within coupling range of the coupling device.

In an example, the system further comprises a network interface and the program code comprises instructions for receiving the val idity check data via the network interface from an issuing bank or an associated party authorised by the issuing bank.

The program code may comprise executable instructions to, in response to determining that the test token is not a valid token, generate a validation request message comprising payment data, transmit the validation request message to a remote validat ion system via the network interface, receive a val idation reply message via the network interface, and if the v alidation reply message indicates that the payment data is v alid, modify the val idity check data accordingly.

In an example, the program code comprises instructions for processing payment data from a payment applicat ion stored by the user dev ice, and wherein the applicat ion data comprises a primary account number received from the user device. The appl icat ion data may further comprise an expiry date associated with the primary account number.

In an example, the coupling device is mounted to an entry barrier for a mass transportation system, and payment data is generated for travel on the mass transportation system.

According to a second aspect of the inv ention, there is provided a method of performing a v alidity check of a user dev ice hav ing an applicat ion stored thereon, the method comprising: receiving, via near field communicat ion, a determinate user dev ice ident ifier from the user device; receiving, v ia near field communication, applicat ion data from the user device, the appl ication data being characteristic of the appl icat ion stored on the user device; processing the user device ident ifier and the appl ication data to generate a test token; and determining whether the test token is valid using stored val idity check data.

According to a third aspect of the invention, there is provided program code which, when executed by a processor, performs a v al idity check of a user dev ice hav ing an application stored thereon by processing a received determinate user device identifier and received appl ication data to generate a test token, and then comparing the test token with validity check data to check if the test token is a valid token.

Further features and advantages of the invent ion will become apparent from the following descript ion of preferred embodiments of the invent ion, given by way of example only, which is made with reference to the accompanying draw ings.

Brief Description of the Drawings

Figure 1 shows a schematic block diagram illustrating the main components of an access system for a mass transportation system together with a payment card, and an acquiring bank system and an issuing bank system connected to the access system;

Figure 2 shows a flow chart showing the main operations performed by the access system of Figure 1.

Detailed Description

In an example, an access system for a mass transportation system has a plurality of access point devices 1 , only one of which is illustrated in Figure 1 for ease of illustration, connected to a mass transportation system back office system 2. A shown in Figure 1 , in an example an access point device 1 communicates with a payment card 3. In this example, the payment card 3 is an ISO I EC 14443 Type A contactless smart card hav ing a payment application conforming to the EMV protocol stored thereon. The access point dev ice 1 includes a proximity coupling dev ice 5 that can communicate with the payment card 3 using near field communication.

In this example, the access point device 1 is positioned at an entrance point to the mass transportation system. A lthough only one access point dev ice 5 is shown in Figure 1 , it will be appreciated that many access point dev ices 5 may be deployed distributed around ail the entrance points to the mass transportation system. In some examples, the access point devices 5 are mounted in associat ion w ith entrance/exit gates (not shown) which are controlled by the access system 1 in dependence on the interaction between the access point device 1 and the payment card 3. The use of entrance ex it gates is not, howev er, required in an implementation of the inv ent ion.

The proximity coupling dev ice 5 is interconnected within the access point device 1 with a processor 7, memory 9 and network interface 1 1 by a bus system. The memory 9 stores program code 13 and data 1 5. Although memory 9 is shown as a single component in Figure 1 with the program code 13 and data 1 5 being shown separately for ease of illustration, it will be appreciated that in practice the memory 9 may involve several memory dev ices hav ing different properties (e.g. volatility and latency ) and standard memory management techniques may be used to store the program code 1 3 and data 15 within the memory 9.

The program code 9 includes smart card protocol code 17 which, when executed by the processor 7, implements communicat ion with the payment card 3 in accordance with the I SO' I EC 14443 protocol . The program code 9 also includes payment code 19 which, when executed by the processor 7, implements communicat ion with the EMV payment application stored on the payment card 3 to generate payment data for use of the mass transportation system.

The data 15 includes a cache of recent payment data 21 generated by the payment code 19 and a list 23 of v alid tokens 25 1 , 25 2, . .. 25 N. As will be described in more detail hereafter, in accordance with the inv ent ion the payment code 1 9 calculates a test token for a payment card 3 and determines if the test token matches a valid token in the list 23 of valid tokens as a val idity check. If the test token is in the list 23 of valid tokens, then the payment card 3 passes the val idity check.

The network interface 1 1 permits communication, v ia a communicat ion network with the back office system 2. The back office system 2 collects payment data generated by all the access point dev ices 1 , and periodically (e.g. ev ery day) processes the collected payment data associated with the payment card 3 and generates payment requests that are sent, via one or more communication networks (e.g. the Internet 27), to the data processing system 29 of an acquiring bank associated with the mass transportation system, which in turn sends the payment request to the data processing system 3 1 of an issuing bank (or an entity authorised by the issuing bank ) for the payment card 3. In this way, the access system 1 can send data to the issuing bank system 31 requesting payment associated with travel on the mass transportation system.

As discussed abov e, the smart card protocol code 1 7 complies w ith the ISO Ί EC 14443 protocol, which makes various requirements on the way that a smart card communicates w ith a proximity coupling dev ice. These requirements underlie those of any applicat ion on the payment card 3 , and accordingly the smart card protocol 17 forms a lower layer protocol below an appl ication layer protocol, such as the EMV payment application, on the payment card 3.

The ISO TEC 14443 protocol includes an anti-collision protocol which performs an anti-collision process to identify, and prevent collisions between, smart cards within coupling range of the coupling device. For the purpose of the anti-collision process, a smart card transmits a smart card ident ifier by which the smart card can be identified by the proximity coupling dev ice. The ISO I EC 14443 specifies two possible configurations. Type A and Type B. For I SO/I EC 14443 Type A, the smart card ident ifier is called a unique ident ifier (UID), which in pract ice need not be strict ly unique to a particular smart card. The UID can be either static or dynamic. A smart card with a static UID uses the same UID for every interact ion with a proximity coupling dev ice, whereas a smart card with a dynamic UID may vary the value of the UI D used for different interactions with proximity coupl ing devices.

In the example of Figure 1 , the payment card 3 is an ISO T EC 14443 Type A smart card hav ing a static UI D. As specified by the ISO I EC 14443 protocol, this static U ID has either four bytes, seven bytes or ten bytes of data. The access system 1 implements the smart card protocol code 17 to detect the presence of the payment card 3 within the coupling range of the proximity coupling device 5. Fol lowing detection of the payment card 3, the smart card protocol code 17 implements the anti-collision process of ISO I EC 14443 during which the proximity coupling dev ice 5 receives the U ID of the payment card 3.

Following the ident ification of the payment card 3 using the ISO IEC 14443 protocol, the access system 1 implements the payment code 1 9 which results in application layer messages being transmitted between the access system 1 and a payment applicat ion provided on the payment card 3. The payment applicat ion stored by the payment card 3 has an associated Primary Account Number (PAN) that uniquely identifies a payment account of the issuing bank. The payment application stored by the payment card 3 also has an associated expiry data.

The payment code 19 performs a number of validit y checks before in association with the generat ion of payment data for accessing the mass transportation system. One reason for performing these validity checks is to frustrate fraudulent attempts to gain access to the mass transportation system using devices that attempt to mimic the behaviour of the payment card 3. Where IT) DA is not successfully executed between the payment card 3 and the access point device 1 , an alternat ive validity check may be required. In this example, the validity checks performed by the payment code comprise a novel val idity check that confirms that the combinat ion of the UID, PAN and expiry data is valid, as described hereafter.

For the purpose of this novel validity check, the issuing bank (or an associated third-party on its behalf) calculates a token value for each payment card 3 issued that can be used to gain access to the mass transportation system. In this example, the UI D of a payment card 3, the PAN of the payment applicat ion and the expiry data of the payment application arc concatenated and then token ised, for example using a one-way hash funct ion, to generate the token for the payment card 3. In this way, the issuing bank generates a list of v alid tokens corresponding to all the payment cards 3 that can be used to gain access to the mass transportation system.

The issuing bank then suppl ies the list of valid tokens to the access system 1 of the mass transportation system, for example v ia the Internet 27 and the network interface 1 1 using a secure communication protocol. In th is way, the list 23 of valid tokens 25 within the memory 9 is populated. It will be appreciated that by using tokenisation, sensit ive financial data such as the PAN of a payment appl ication is not derivable from the data stored by the access system 1.

Subsequently, following receipt of the UID of the payment card 3, and the PAN and expiry data associated with the payment application stored on the payment card 3 as describes above, the payment code 19 concatenates the UI D, the PAN and expiry data and token ises the resultant concatenation to generate a test token, the concatenat ion and tokenisat ion processes performed by the payment code 19 mirroring those performed by the issuing bank. The payment code 1 9 then determines whether the test token for the payment card 3 matches any of the list 23 of valid tokens 25. It the test token does match a valid token 25, and any other required validity checks are satisfied, then the payment applicat ion generates payment data that is temporarily stored in the payment data section 2 1 of the memory 9 before being sent to the back office system 2. This payment data includes the PAN for the payment applicat ion and also includes details of the ident it y of the access point dev ice 1 and the time at which t he payment data is generated. The present system can apply to mass transportation systems which employ any fare structure. In some examples, the interaction between the payment card 3 and the payment application can be performed on entry to the mass transportation system, while in other examples the interaction is performed- on both entry to and exit from the mass transportation system. The use of gates or turnstiles in association with access point devices is optional.

The novel validity check described above has a number of advantages. The novel validity check provides some protection against 'number tumbler' type attacks when various combinations of payment appl icat ion data are communicated fraudulently to the payment applicat ion 1 9 in the aim of eventually providing a val id set of application data. This is a particular advantage when payment cards 3 do not support offline data authentication (ODA) using dynamic methods such as those described in the EMV specifications. For example, the novel val idity check does not require onl ine communication with the issuing bank system 27 during the interaction between the payment card 3 and the payment application 19. Such online communicat ion may take from two to eight seconds (perhaps longer at peak times), which is undesirable when a large number of people need to use the proximity coupling dev ice 5 in a short amount of time.

Although the novel validity check frustrates some fraudulent attacks, the use of ODA is preferred to gain access to a mass transportation system. It is often not feasible to issue contactless payment cards that al l have ODA funct ionality, but in an example the access system 1 keeps track of payment cards 3 that have been used to gain access and do not have ODA functionality, and passes that list to the issuing bank on the basis that the issuing bank can prioritise issuing contactless payment cards with ODA funct ionality to the financial account holders associated with those payment cards.

In the above examples, the list 23 of valid tokens 25 is pre-populated with valid tokens by the issuing bank. In an alternat ive example, if a test token is not present in the list of val id tokens, then the payment code 1 9 generates a validat ion request message containing payment data that is sent to the issuing bank system 27 as part of an on line data authentication process. If the payment data is validated by the issuing bank system 27, then the issuing bank system 27 sends a val idat ion reply message indicating that the payment data is valid, then the payment code 19 adds the test token for the payment card 3 to the list 23 of val id tokens 25 (via the back office system which distributes the valid test token across al l access point devices). In this way, the list 23 of valid tokens 25 is populated over time as different payment cards are used to gain access to the mass transportation system. Although the onl ine interaction with the issuing bank system 27 may take from two to eight seconds (or longer), this delay only occurs the first time that a payment card is used.

The examples discussed above envisage the use of a static UID, rather than a dynamic UID. In this way, the generated test token can simply be compared with a list of valid test tokens. Alternat ively, the UID can be dynamic in a determinat ive manner, for example being determined by processing a seed val ue in a manner that varies over time in a known way. In such an arrangement, the test token would also vary over time, but a validity check could still be performed as the test token varies ov er time in a known way.

Figure 2 il lustrates a flow chart outl ining a method of implementation of the inv ent ion within an access system. As shown, fol lowing the start, at S 1 , of the method, w hich may correspond to the detection of the presence of a payment card, the access system receiv es, at S2, the UI D from the payment card. The access system then receives, at S3, the applicat ion data from the payment card and processes, at S4, the received UID and appl ication data to generate a test token. The access system then checks, at S5 if the test token is v alid using stored v alidity check data. If the test token is v alid, then the access system accepts the card, at S6. On the contrary, if the test token is not v al id then the access system denies, at S7, the payment card.

In the abov e examples, a contactless payment card 3 conforming to the ISO I EC 14443 is used to access a mass transportation system. It will be appreciated that it is know n that contactless payment cards can be validly emulated by other user dev ices capable of near field communication, for example mobile phones, and the present invent ion is equally applicable to the use of such user devices.

Although the invent ion has been described above in the context of a mass transportation system, the inv ent ion can be utilised for other applicat ion. For example, the inv ent ion can be used in other purchasing systems, or for systems for permitting access to a building, such as a cinema, or an attraction, such as a theme park. It could also be used in parking and tol l environments. The present invention also has application outside of EMV payment devices that communication with proximity coupling devices as defined in the ISO I EC 14443 standard, and is generally appl icable in which user devices have determinate user device identifiers and applications stored thereon which communicate v ia near field communication with a coupl ing device. Preferably, the user dev ice identifier is associated with a lower protocol layer than the stored appl ication so that the test token cannot be determined from data from the stored application alone.

The above embodiments are to be understood as illustrative examples of the invent ion. Further embodiments of the invent ion are envisaged. Equivalents and modifications not described above may also be employed without departing from the scope of the invent ion, which is defined in the accompanying claims.