Patent Description:
Secured access control systems are generally known, in which users are issued with a permanent or temporary identification (ID) pass specific to a system. The issued pass is typically presented by the owner wishing to cross a control point, and checked before the user is allowed entry to an associated secured area, building, facility, etc. One conventional form of access control relies on a static form of identification for example printed on the pass, such as the name of the individual and/or a photograph of the user's face. However, such a form of identification is susceptible to fraudulent production and reproduction. Another conventional form of access control relies on machine verification of encoded identifier data. For example, the identifier data may be encoded in a barcode printed on the pass, such as a 1D (one-dimensional) barcode or a 2D (two-dimensional) barcode, commonly referred to as a QR code. As another example, the identifier data may be embedded in an electronic tag, such as a near field communication (NFC) tag identifier or a Radio Frequency Identifier (RFID) tag. However, such machine verification systems do not verify the identity of the person presenting the pass for access.

Other examples of embedding verifiable information into 2D barcodes are discussed in "<NPL> et al. , <CIT>, and "<NPL> et al.

More generally, a secure fingerprint biometric system is discussed in "<NPL>et al.

Accordingly, there remains a need for technical improvements in the art.

Aspects of the present invention are set out in the accompanying claims.

For example, according to one aspect, the present invention provides a data verification method as set out in claim <NUM>.

In other aspects, there are provided apparatus and systems configured to perform the method as described above. In a further aspect, there is provided a computer program comprising machine readable instructions arranged to cause a programmable device to carry out the method as described above.

There now follows, by way of example only, a detailed description of embodiments of the present invention, with references to the figures identified below.

<FIG> shows the main components of an access control system <NUM> according to an embodiment, including a terminal <NUM> located for example at a control point to a security restricted area. An authentication module <NUM>, which in this exemplary embodiment is provided at the terminal <NUM>, is configured to verify the authenticity of identification data <NUM> received by the terminal <NUM> for example from a computing device <NUM> of the user. In other embodiments, the authentication module <NUM> may be provided at a remote server <NUM>. The terminal <NUM> and user device <NUM> may be configured for data communication with the server <NUM> via a data network <NUM>. The identification data <NUM>, which in this embodiment takes the form of an electronic pass, is stored in a memory <NUM> of the user's computing device <NUM> and includes data defining a two-dimensional (2D) barcode <NUM>. As is known in the art, the 2D code <NUM> is a machine-readable optical label that consists of graphical elements, typically pixels/patterns arranged in a square grid. The graphical elements encode source information, such as a user identifier <NUM> associated with the user to whom the electronic pass was originally issued, who may or may not be the same user presenting the associated identification data <NUM> to the terminal <NUM>.

As shown in <FIG>, the 2D code <NUM> in the present embodiments incorporates graphical elements representing a low-resolution image of the user's face. A code generator <NUM>, provided at the user device <NUM> and/or a remote server <NUM>, is configured to generate a 2D code <NUM> from the source data, the 2D code <NUM> incorporating pixel data representing a low-resolution image of the user's face that may be derived from a higher resolution version of the image data. The high-resolution image may be stored as verification data <NUM> in a secure user database <NUM> of the server <NUM>, for example as user data <NUM> associated with the user identifier <NUM>, for subsequent retrieval by the authentication module <NUM> to verify the authenticity of the identification data <NUM>, as will be described in greater detail below. In some embodiments, the high-resolution image data <NUM> is stored in an encrypted form, for example after encryption of the high-resolution image data by a verification data generator <NUM>, using a cryptographic key of the associated user. The verification data may additionally or alternatively include profile data such as biometric signature data associated with the user, e.g. fingerprint, voiceprint, retina/iris scan, etc., and/or visible feature data, e.g. facial characteristics, and/or any other identifying data, e.g. password, PIN, etc. As yet a further alternative, the verification data generator <NUM> may be configured to generate a modified or altered version of input data, such as the high-resolution image data <NUM> and/or profile data, etc. that encodes or embeds a defined correspondence relationship with the image data of the 2D code <NUM>, such as having common values, or a threshold number of matching values, at defined positions within the respective strings or arrays of data values.

The user device <NUM> may be configured to output the identification data <NUM> via an output interface <NUM> such as a display, whereby the 2D barcode <NUM> is presented by the user to a camera input interface <NUM> of the terminal <NUM>. Alternatively, the user device <NUM> may be configured to transmit the identification data <NUM> to the terminal <NUM> via an output interface <NUM> for data communication, for example using a wireless or contactless data communication protocol. It is appreciated that additionally or alternatively, the identification data <NUM> may be printed on a physical pass and issued to the user, for presentation to the camera <NUM> at the terminal <NUM>. As yet another alternative, the user device <NUM> may be an electronic key fob or security token storing the generated ID data <NUM>, configured to transmit the ID data <NUM> via a data communication output interface <NUM> to a corresponding data communication input interface <NUM> of the terminal <NUM>.

Responsive to positive verification, the authentication module <NUM> may subsequently output a control signal to an access controller <NUM> of the terminal <NUM> to allow the authorised user to pass through the control point. The authentication module <NUM> may also output the retrieved version of the user's image to a display <NUM>, facilitating additional manual verification of the user's identity. It should be appreciated that the system <NUM> may include other components, subcomponents, modules, and devices commonly found in a computing system/device, which are not illustrated in <FIG> for clarity of the description.

One example embodiment of a code generator <NUM>-<NUM> for generating a 2D code <NUM> is schematically illustrated in the block flow diagram of <FIG>. In this exemplary embodiment, the code generator <NUM>-<NUM> receives image data <NUM> of the user's face, for example as a high-resolution version of the image to be incorporated into the 2D code <NUM>. The high-resolution image data <NUM> of the user's face may be captured by a camera (not shown) of the user device <NUM>. In this example, an image data processor <NUM> processes the received high-resolution image data <NUM> to generate a lower-resolution version <NUM> of the received image data <NUM>.

It is appreciated that the lower resolution image enables the individual pixel sizes to be larger, reducing the possibility of image data capture error when subsequently capturing the image of the two-dimensional code using a scanner or camera. As an alternative, the lower resolution image may be protected by an error correcting code, where the associated parity/error-correcting symbols are included for example as encoded data in the two-dimensional code itself, and/or present as additional/supplemental image data, for example as one or more rows of pixel values following the lower-resolution image or the two-dimensional code itself. Auxiliary data such as image supporting data may also be present in one or more rows of pixel values following the image pixels. Any errors following the subsequent capture of the lower resolution image may be corrected by the error correcting code, using the decoded/captured parity/error-correcting symbols. The art of error correction using error correcting codes is well known per se, and need not be described further.

The code generator <NUM>-<NUM> includes an encoder <NUM> implementing any known algorithm for generating 2D code elements from input source data <NUM>. The 2D code <NUM> may be generated to include one or more types of source data, such as the user identifier <NUM>, data associated with a transaction, data representing a calculated cryptographic hash value, an authentication token, a cryptographic key, a digital signature, etc. As is known in the art, redundancy in the 2D code is typically provided, enabling recovery of the original data despite corrupted scanned/captured 2D code data. For example, using a Reed-Solomon code set at a level H defines a corresponding maximum amount data corruption/loss that can be recovered, such as <NUM>%. In this exemplary embodiment, the encoder <NUM> is configured to determine and insert a corrupted 2D code area that is subsequently occupied by the generated low resolution image <NUM>. Alternatively, other algorithms are known for generating 2D code elements directly from the input source data <NUM> and the original, e.g. high-resolution, image data of the user's face, whereby the source data is at least partially encoded into the graphical elements representing the image of the user's face in the resulting 2D code <NUM>.

The generated 2D code <NUM> is passed to an ID generator <NUM>-<NUM> of the user device <NUM>, to generate data defining the identification data <NUM>, including the generated 2D code <NUM> data. It is appreciated that part or all of the code generator <NUM>-<NUM> and/or ID generator <NUM>-<NUM> functionality may be provided at the remote server <NUM>. The identification data <NUM> may be stored in the memory <NUM> of the user device <NUM>, for subsequent retrieval and output, for example on a display <NUM> of the user device <NUM> for capture by the camera <NUM> of the terminal <NUM>.

<FIG>, which comprises <FIG>, shows one example of a 2D code <NUM> generated by the code generator <NUM>-<NUM>. Firstly, a blank rectangle, having an area corresponding to or less than the maximum amount of recoverable data loss, is inserted into the 2D code <NUM>-<NUM>, as shown in <FIG>. A low resolution version <NUM> of the high resolution user image <NUM> is obtained by the image data processor <NUM>, for example by scaling and grey level quantisation, as shown in <FIG>. The low resolution image <NUM> is inserted or placed into the blank rectangle of <FIG>, to produce the output result data shown in <FIG>. Preferably, a marker or demarcation such as a border of white pixels is also inserted to the 2D code <NUM>-<NUM>, for ease of subsequent image processing to extract the low-resolution image data <NUM> from captured 2D code data. The code generator <NUM>-<NUM> may perform a check that the generated 2D code <NUM> can be correctly read by a 2D code reader and that the original data decoded and recovered without error.

It is appreciated that there are a number of known alternative methods of inserting images into 2D codes, for example as described in "<NPL>. It is also appreciated that implementations of the present invention will typically be a closed, proprietary system in which the 2D code image is generated and read within the system. In such cases, it is advantageous to use a custom QR code format whereby QR code data is restricted in area or otherwise encoded so that there is no interference from the low resolution image data. The resulting QR code will not be able to be read by a standard QR code reader but that is of no consequence within the closed system and can be an advantage.

<FIG> is a block flow diagram showing the main data processing components and flows of an authentication module <NUM>-<NUM> according to an exemplary embodiment. The authentication module <NUM>-<NUM> includes a decoder <NUM> that receives data defining a 2D code <NUM>, for example 2D code image data as captured from the display <NUM> of the user device <NUM> by the camera <NUM> of the terminal <NUM>. In this embodiment, the 2D code <NUM> encodes source data including a user ID <NUM> and a cryptographic key <NUM> associated with the user. The decoder <NUM> processes the received 2D code <NUM> data to decode data identifying the cryptographic key <NUM> and the user identifier <NUM>. The decoded user identifier <NUM>' will correspond to registered user data <NUM> stored in a user database <NUM> if the identification data <NUM> is authentic. The stored user data <NUM> also includes an encrypted version of the high-resolution image data 23a of the user's face, encrypted using the user's cryptographic key <NUM>. The high-resolution image data may also be digitally signed, for example using an RSA or DSA key, to prove authenticity and to prevent any fakes or substitute images being deployed by adversaries. The user data <NUM> may also include profile data <NUM> for each registered user in the database <NUM>, including for example biometric profile data defining one or more recognisable visible characteristics of the user's face. The database <NUM> may be a relational database; however, any other type of data organizational structure may be used.

The decoded user identifier <NUM>' is passed to a database interface <NUM>, which retrieves the encrypted image data 23a of the corresponding user data <NUM> from the user database <NUM>. The database <NUM> may be provided in a local memory of the terminal <NUM>, or as a secured database on the remote server <NUM> that is accessible by the database interface <NUM> via the data network <NUM>. For example, a secure communications protocol such as TLS or SSL may be implemented by the database interface <NUM> to retrieve the image data in encrypted form from the secure database <NUM> to a data decrypter <NUM>. The data decrypter <NUM> processes the retrieved encrypted image data <NUM>' to decrypt the high-resolution image <NUM> of the user's face, using the decoded cryptographic key <NUM>. A data verifier <NUM>-<NUM> receives the captured image data of the 2D code <NUM> including the low-resolution image <NUM>' of the user's face, and also receives the decrypted high-resolution image data <NUM> of the user's face from the data decrypter <NUM>. The data verifier <NUM>-<NUM> processes the received captured image data to locate and extract the pixels corresponding to the low-resolution user image <NUM>', for example by determining the marker or demarcation inserted to the 2D code <NUM>. Any pixel errors may be corrected using an error correcting code, for example if parity symbols are present in the captured image data and/or decoded data.

The data verifier <NUM>-<NUM> in this exemplary embodiment also performs data processing to verify that the received low-resolution image data <NUM>' corresponds to the retrieved and decrypted high-resolution image data <NUM> of the user's face. For example, the data verifier <NUM>-<NUM> may perform facial recognition processing on both images to verify that identified features/characteristics match the user's profile data <NUM> retrieved from the user database <NUM>. The low resolution image of the user's face present in the 2D code <NUM> also enables the user or other person to manually check that they have the correct pass before presenting it to the validation system <NUM>. The data verifier <NUM>-<NUM> may also receive image data of the face of the user presenting the identification data <NUM> to the terminal <NUM>, for example from another camera (not shown) of the terminal <NUM>, and perform image processing on the received image data to detect and verify recognisable visible features of the user's face in the low-resolution, high-resolution and/or captured image data. The data verifier <NUM>-<NUM> may also output the low-resolution and high-resolution image data on the display <NUM> of the terminal <NUM>, for further manual verification that the user presenting the identification pass <NUM> is the authorised owner. After positive verification of the received 2D code <NUM> by the data verifier <NUM>-<NUM>, an authentication token <NUM> may be generated and output, for example to the access controller <NUM> of the terminal <NUM>. In response, the access controller <NUM> may generate and output one or more control signals, thereby controlling access by the authenticated/verified user to an associated security restricted area.

<FIG> is a flow diagram of a computer-implemented process of authenticating a user at a terminal, according to an exemplary embodiment. As shown in <FIG>, the process begins at step S5-<NUM> where the camera <NUM> captures image data of the 2D code <NUM>, for example from the user's identification pass, presented to the terminal <NUM>. In this embodiment, the 2D code <NUM> includes graphical code elements encoding a cryptographic key <NUM> and a user ID <NUM> associated with the user. At least some of the graphical code elements represent a low-resolution image of the user's face. At step S5-<NUM>, the decoder <NUM> processes the captured image data of the 2D code <NUM> to decode the user's cryptographic key <NUM> and ID <NUM>'.

At step S5-<NUM>, the database interface <NUM> retrieves the corresponding user's encrypted image data 23a from the user data <NUM> stored in the user database <NUM>, for example based on the decoded user ID <NUM>'. At step S5-<NUM>, the data decrypter <NUM> processes the data retrieved from the user database <NUM> to decrypt the high-resolution image data <NUM> of the user's face. The data verifier <NUM>-<NUM> may then process the decrypted high-resolution image data <NUM> and the low-resolution image of the user's face extracted from the captured image data of the 2D code <NUM>, to verify visible characteristics of the user's face in the low- and high-resolution images against the user's profile data <NUM> stored in the user database <NUM>. For example, as shown at step S5-<NUM>, the data verifier <NUM>-<NUM> processes the captured image data of the 2D code <NUM> to determine and extract the graphical elements representing the low-resolution image of the user's face. The data verifier <NUM>-<NUM> may be configured to locate a marker or demarcation such as a border of white pixels as inserted to the 2D code <NUM>-<NUM> to determine the area of pixel data containing the low-resolution user image <NUM>'.

In this example, at step S5-<NUM>, the data verifier <NUM>-<NUM> performs facial recognition processing on the extracted low-resolution image data to identify one or more recognisable characteristics of the user's face. Similarly, at step S5-<NUM>, the data verifier <NUM>-<NUM> performs facial recognition processing on the decrypted high-resolution image data <NUM> to identify one or more recognisable characteristics of the user's face. Suitable feature recognition algorithms are known per se, and need not be described further. At step S5-<NUM>, the data verifier <NUM>-<NUM> verifies the identified characteristic(s) against the user's profile data <NUM> retrieved from the user database <NUM>. Alternatively or additionally, an operator at the terminal <NUM> can visually check that the individual in person corresponds to both the high resolution image <NUM> and the 2D code image <NUM> as output on the display <NUM> of the terminal <NUM>, since the correspondence between individual and the low-resolution 2D code image itself may not be irrefutable.

At step S5-<NUM>, the data verifier <NUM>-<NUM> may generate an output signal to authorise access to the verified user, for example to the access controller <NUM> of the terminal <NUM>. In this way, the system <NUM> advantageously provides an irrefutable binding between the low-resolution user image <NUM>' and the high-resolution decrypted user image <NUM>, and hence to the individual purporting to be the owner of the associated identification data <NUM> presented to the terminal <NUM>. It is further appreciated that as the stored high-resolution images are securely stored in the database <NUM> in encrypted form, the image data is not readily accessible by a fraudster. Even if a fraudster could learn the encryption keys or authentication process to fraudulently access the secure system <NUM>, reproducing the necessary corresponding hash values is a further obstacle in other embodiments, described below,.

<FIG> is a block flow diagram showing the main components of the user device <NUM> and the remote server <NUM> for generating a 2D code <NUM> according to another embodiment, using corresponding reference numerals to those of preceding figures where appropriate for corresponding elements. The code generator <NUM> is provided at the user's device <NUM> and generates 2D code data <NUM> including 2D code elements encoding received source data <NUM>, and the lower-resolution image <NUM> computed from corresponding higher-resolution image data <NUM> for example captured by the camera <NUM> of the user device <NUM>, as discussed above with reference to <FIG>.

As shown in <FIG>, in this exemplary embodiment, the higher-resolution version of the user image <NUM> and the 2D code data <NUM> are transmitted by the user device <NUM> to a verification data generator <NUM> of the remote server <NUM>, for example via the data network <NUM>. The verification data generator <NUM> is configured to perform iterative data processing to derive a manipulated version of the received higher-resolution image data 23b having an associated computed cryptographic hash value having corresponding values in common with a cryptographic hash value computed from at least a portion of the 2D code data <NUM>, such as the extracted pixel values of the 2D code <NUM> corresponding to the lower-resolution user image <NUM>. For example, the hash correspondence determiner <NUM> may repeatedly call a data manipulator <NUM> to change or alter the higher-resolution image data steganographically and subsequently call a cryptographic hash calculator <NUM> to calculate the corresponding hash value, until the hash values of both versions of data satisfy a defined correspondence relationship, such as having the desired common values, or a threshold number of matching values at defined positions within the respective strings of data values. The cryptographic hash calculator <NUM> may implement one or more known cryptographic hash functions, such as the SHA-<NUM> cryptographic hash function, a standard published by the National Institute of Standards and Technology (NIST). The derived manipulated version of the higher-resolution image data 23b is then stored as user data <NUM> in the user database <NUM>, for subsequent retrieval in a corresponding user verification process. It will be appreciated that an alternative embodiment may calculate the hash value of a portion of the 2D code data within the user device <NUM> and send said hash value to the server <NUM> instead of the 2D code data <NUM>.

<FIG> is a block flow diagram of an authentication module <NUM>-<NUM> according to another exemplary embodiment, corresponding to the code generator <NUM> shown in <FIG> and using corresponding reference numerals to those of preceding figures where appropriate for corresponding elements. The authentication module <NUM>-<NUM> in this embodiment also includes a decoder <NUM> that receives data defining a 2D code <NUM>, the 2D code <NUM> encoding source data including the user ID <NUM> associated with the user. As discussed in the embodiments above, the 2D code image data may be captured, by the camera <NUM> of the terminal <NUM>, from the display <NUM> of the user device <NUM>, by wireless communication or from a physical pass having the 2D code printed thereon. The decoder <NUM> processes the received 2D code <NUM> data to decode data identifying the user identifier <NUM>, corresponding to registered user data <NUM> stored in a user database <NUM> including the manipulated version of the user's verification data 23c, such as the altered high-resolution image data 23b of the user's face output by the data manipulator <NUM> discussed above with reference to <FIG>.

The decoded user identifier <NUM>' is passed to the database interface <NUM>, which retrieves the manipulated verification data 23c of the corresponding user data <NUM> from the user database <NUM>. The 2D code data <NUM>, including the lower-resolution image data <NUM>' of the user's face, and the corresponding retrieved manipulated verification data 23c are passed to a cryptographic hash calculator <NUM> of the authentication module <NUM>, which corresponds to the cryptographic hash calculator <NUM> of the verification data generator <NUM> shown in <FIG>. The authentication module <NUM>-<NUM> uses the cryptographic hash calculator <NUM> to calculate a hash value <NUM> from the defined portion or whole of the 2D code data <NUM>, such as the extracted pixel values representing the lower-resolution user image <NUM>' as discussed above with reference to the corresponding code generator <NUM>. It is appreciated that the specific image resolution of the lower-resolution user image <NUM>' will determine the number of pixel values that are input to the cryptographic hash calculator <NUM>. Preferably, although not necessarily, the image resolution of the lower-resolution user image <NUM>' may be no greater than the capture resolution of a conventional QR code scanning device. The authentication module <NUM>-<NUM> also uses the cryptographic hash calculator <NUM> to calculate a hash value <NUM> from the retrieved manipulated verification data 23c. A data verifier <NUM>-<NUM> receives the calculated first and second hash values <NUM>, <NUM> and performs data processing to identify and verify that the respective hash values have the corresponding values in common, for example in the defined positions within each string of the calculated hash values as discussed above with reference to the corresponding verification data generator <NUM>. In this way, the data verifier <NUM>-<NUM> of this exemplary embodiment verifies that the received low-resolution image data <NUM>' corresponds to the retrieved high-resolution image data 23b of the user's face, when it is determined that the respective calculated hash values include the embedded correspondence.

<FIG> is a flow diagram of a computer-implemented process of authenticating a user at a terminal using the authentication module <NUM>-<NUM> shown in <FIG>, according to another exemplary embodiment. As shown in <FIG>, the process begins at step S8-<NUM> where the camera <NUM> captures image data of the 2D code <NUM>, for example from the user's identification pass, presented to the terminal <NUM>, the 2D code <NUM> including graphical code elements encoding a the user ID <NUM> associated with the user. As in the embodiments described above, at least some of the graphical code elements represent an image of the user's face, at a low image resolution. At step S8-<NUM>, the decoder <NUM> processes the captured image data of the 2D code <NUM> to decode the user's ID <NUM>'. At step S8-<NUM>, the database interface <NUM> retrieves the manipulated version of the user's image 23b, from the user data <NUM> stored in the user database <NUM>, for example based on the decoded user ID <NUM>'. As discussed above with reference to the corresponding verification data generator <NUM> shown in <FIG>, the manipulated image data 23b represents the user's image at a higher image resolution than low-resolution image <NUM>' in the 2D code <NUM>.

In this exemplary embodiment, the authentication module <NUM>-<NUM> is configured to verify correspondence between respective cryptographic hash values calculated from the received image data and the retrieved server data. Accordingly, at step S8-<NUM>, the cryptographic hash calculator <NUM> may process the captured image data of the 2D code <NUM> to determine and extract the graphical elements representing the low-resolution image of the user's face. Similar to the data verifier <NUM>-<NUM> discussed above, the cryptographic hash calculator <NUM> may be configured to locate a marker or demarcation such as a border of white pixels as inserted to the 2D code <NUM> to determine the area of pixel data containing the low-resolution user image <NUM>'. At step <NUM>-<NUM>, calculates a first cryptographic hash from the pixel values of the area of the 2D code data <NUM> determined to represent the user's face. Alternatively a hash may be calculated from the pixel values of the entire 2D code image data <NUM>, or a combination thereof. A worked example will now be given, where the hash function used is the SHA-<NUM> cryptographic hash function, having a <NUM> bit (<NUM> bytes) output. In the present worked example, a <NUM> bit hash of the lower-resolution image data may be represented in hexadecimal format as:
74a76ed7a52cb5a4b3 524c4fW5 ad5efa89a3 56e21 ec70e 16a3 7a75462496aa.

At step S8-<NUM>, the cryptographic hash calculator <NUM> computes a second cryptographic hash value <NUM> from the retrieved higher-resolution image data 23b. In this exemplary embodiment, the original high-resolution image <NUM> of the user's face was subjected to steganographic signal processing by the data manipulator <NUM> so that the consequently computed hash value <NUM> of the manipulated high-resolution image data 23b has characters in common with the hash value <NUM> computed from the 2D code data <NUM>, for example in a defined number of locations within the character string. The low-resolution image <NUM> in the 2D code <NUM> may be derived from the high-resolution image <NUM> by using image processing, but this is not essential. Following from the present worked example, the hash value of the steganographically altered high-resolution image 23b may be represented in hexadecimal format as:
75b6978d787ef28daea0610fld5856705340397aff571b52efc57a75462496aa where the last twelve digits of this second hash value <NUM> correspond to the last twelve digits of the first hash value <NUM> derived from the corresponding low-resolution image <NUM>' of the user's face. Suitable steganographic algorithms to change pixel values without degrading the image to an unrecognisable form are known per se, for example as discussed in the paper "On the steganography effects in digital images" by F. Marino and G. Mastronardi, and need not be described further. It will be appreciated that as the changes to the original image are steganographic changes, the image itself will appear to be the same high-resolution image of the individual's face and thus suitable for automatic and/or manual verification of recognisable visible characteristics.

At step S8-<NUM>, the data verifier <NUM>-<NUM> receives and compares the first and second cryptographic hash values <NUM>, <NUM> to verify digits in common. Referring to the present worked example, the data verifier <NUM>-<NUM> may compare the two hash values to determine that the characters in the corresponding defined locations are the same. At step S8-<NUM>, the data verifier <NUM>-<NUM> may generate and output an authentication token, for example to the access controller <NUM>, to authorise access to the verified user.

Numerous alternative implementations to verify correspondence between the two derived hash values are envisaged. For example, the hash values may be configured to agree in different positions, not just at the end of the character string as in the example provided above. The correspondence locations may be in variable positions within the character strings, for example in positions defined by a code look up table and/or may be determined from at least part of the hash value derived from the 2D code <NUM>.

As yet another alternative, the high-resolution image need not be modified steganographically to achieve the defined correspondence. Instead, a pseudorandom value may be appended to the high-resolution image data so that the computed hash value of the whole data (i.e. the high-resolution image data and the appended value) has the required digits in common.

As another alternative, the hash values may be determined by a keyed hash function such as a HMAC (keyed-hash message authentication code) or SHA-<NUM>, by key/data input concatenation, using a secret key or a key derived from the 2D code, for example as obtained by AES encryption of the 2D code image data <NUM> using a fixed or secret AES key.

As another alternative, the hash digits in question need not have an exact correspondence or agreement, and instead may be defined to have a mathematical relationship with each other, purely for example a modulo <NUM> sum, or a modular sum with a predefined information element, such as the user's name, phone number, URL and/or user biometric data such as a fingerprint, iris scan, etc..

In yet another alternative embodiment, aspects of the code generator <NUM>-<NUM> described with reference to <FIG> and the verification data generator <NUM> described with reference to <FIG> may be combined, whereby the hash value derived from the 2D code image data <NUM> may be used directly or used as input to a keyed preudo-random function to produce a cryptographic key <NUM> to decrypt the encrypted high-resolution image 23a of the individual as stored in and retrieved from the database <NUM>. It is appreciated in such an alternative, the system is advantageously configured to provide heightened security policies by avoiding direct exposure of the encryption key, since decoded key information is used to compute or otherwise retrieve an associated cryptographic key from a secure memory or database, and the hash value is not utilised as the authentication instrument to enable access to the encrypted high-resolution image stored by the secure system <NUM>. Alternatively, the system <NUM> may include further security functionality, such as multi-factor authentication requiring the individual to additionally input a PIN, fingerprint or other biometric input.

Another embodiment of the invention will now be described with reference to <FIG>, using corresponding reference numerals to those of preceding figures where appropriate for corresponding elements, for a system <NUM> having an authentication server <NUM> configured to verify the identity of a user initiating, generating or otherwise involved in a transaction via a user application 95a on a user device 9a. In this embodiment, the user application 95a is configured to process data relating to a transaction between the user application 95a at the user device 9a and a corresponding user application 95b at a recipient device 9b, for example via an application module <NUM> of an application server <NUM>. It is appreciated that in other implementation contexts, the transaction may be between the user application 95a and the application server <NUM> itself. Purely by way of example, the user applications <NUM> may provide functionality to perform data transfer transactions between respective users, electronic data messaging, peer-to-peer (P2P) payment transactions (which may not require an intermediary application server), or payment transactions from a customer device to a merchant and/or bank computing entity.

In this exemplary embodiment, the user application 95a includes a transaction data generator <NUM> configured to generate transaction data depending on the particular user application implementation context. The generated transaction data is provided as source data <NUM> to a code generator <NUM> of the user application 95a, which also receives image data of the user's face <NUM> captured by a camera <NUM> of the user device 9a, for example in response to a prompt from the user application 95a while or after the transaction data is generated. As discussed above with reference to <FIG>, the code generator <NUM> generates 2D code data <NUM> including 2D code elements encoding the generated transaction data, and the lower-resolution image <NUM> computed from corresponding higher-resolution image data <NUM>. The higher-resolution version of the user image <NUM> and the 2D code data <NUM> are also transmitted by the user application 95a to a verification data generator <NUM> of the remote server <NUM>, for example via the application server <NUM>. The user application 95a may also transmit some or all of the generated transaction data to the verification data generator <NUM>. As also discussed above with reference to <FIG>, the verification data generator <NUM> performs iterative data processing to derive a manipulated version of the higher-resolution image data 23b and any transaction data received from the user application 95a, the manipulated verification data <NUM> having an associated computed cryptographic hash value with corresponding values in common with a cryptographic hash value computed from at least a portion of the 2D code data <NUM>.

In this embodiment, the generated 2D code <NUM> is passed to a transaction token generator <NUM>-<NUM> of the user application 95a, which generates a transaction token <NUM>' including the 2D code data <NUM>, thereby establishing an electronic receipt of the transaction that provides an irrefutable binding of the user who initiated or is associated with the transaction, to the encoded details of the transaction itself. The authentication server <NUM> is also used to subsequently authenticate the transaction by verifying the identity of the user purporting to be associated with the transaction, for example based on processing of the 2D code <NUM> from the transaction token <NUM>' by the authentication module <NUM> at the authentication server <NUM>, as discussed above with reference to <FIG>.

As shown, the user application <NUM> is in communication with the corresponding application module <NUM> of the application server <NUM> via respective application server and client interfaces 103a,b, for example over the data network <NUM>. The application module <NUM> is also in communication with the authentication server <NUM> over the data network <NUM>, via respective interfaces 105a,b. It will be appreciated that the interfaces <NUM>,<NUM> may include computer executable instructions for the respective applications to establish and transmit data over a transmission path therebetween.

The user device 9a is associated with a registered user of the system <NUM>, the authentication server <NUM> storing user data <NUM> identifying each registered user, for example in one or more databases <NUM>. The user and recipient devices <NUM> may each be of a type that is known per se, such as a desktop computer, laptop computer, a tablet computer, a smartphone such as an iOS®, Blackberry® or Android® based smartphone, a 'feature' phone, a personal digital assistant (PDA), or any processor-powered device with suitable input and display means. It will be appreciated that a plurality of user devices <NUM> are operable concurrently within the system <NUM>.

<FIG> is a block diagram of a system <NUM> according to another embodiment. , using corresponding reference numerals to those of preceding figures where appropriate for corresponding elements. In this exemplary embodiment, the authentication server <NUM> is also configured to verify the identity of a user initiating, generating or otherwise involved in a transaction via a user application 95a' on a user device 9a. However, instead of generating a transaction token as discussed above with reference to <FIG>, the user application 95a' in this embodiment includes a data wrapper generator <NUM> that is configured to generate a 2D code wrapper data entity <NUM> based on the captured image data of the 2D code <NUM> and the transaction data output by the transaction data generator <NUM>. <FIG> is a block diagram schematically illustrating an example wrapper data structure <NUM> generated by the data wrapper generator <NUM>. As shown, the data wrapper generator <NUM> inserts the received 2D code image data <NUM>, including the embedded user's low-resolution photo, into a core layer <NUM>-<NUM> of the QR wrapper data structure <NUM>. Optionally, additional user data (not shown), such as a password or PIN and/or user biometric data such as a fingerprint or iris scan, may be included with the 2D code <NUM>.

The data wrapper generator <NUM> computes a first hash value <NUM>-<NUM> from the data in the core layer <NUM>-<NUM>, including the image data of the 2D code <NUM> and any accompanying additional user data. The core layer <NUM>-<NUM>, the core hash value <NUM>-<NUM>, and the transaction data <NUM> received from the transaction data generator <NUM>, together form a second layer of the wrapper data structure <NUM>, referred to as the first wrapper layer <NUM>-<NUM> or `Wrapper <NUM>'. The data wrapper generator <NUM> computes a second hash value <NUM>-<NUM> from the data of the first wrapper layer <NUM>-<NUM>. The computed Wrapper <NUM> hash value <NUM>-<NUM> and the data of the first wrapper layer <NUM>-<NUM> itself together form a third layer of the wrapper data structure <NUM>, referred to as the second wrapper layer <NUM>-<NUM> or `Wrapper <NUM>'. The data wrapper generator <NUM> may then digitally sign the second wrapper layer <NUM>-<NUM>, for example using an RSA or DSA key.

In this exemplary embodiment, the wrapper data entity <NUM> is transmitted to the application module <NUM> of the application server <NUM>, where a corresponding data wrapper verifier <NUM> of the application module <NUM> carries out data processing on the received wrapper data entity <NUM> to first check that the Wrapper <NUM> data layer <NUM>-<NUM> is intact, by checking the received Wrapper <NUM> hash value <NUM>-<NUM> against a computed hash of the received wrapper <NUM> data itself. The data wrapper verifier <NUM> then carries out data processing to check that the Wrapper <NUM> data layer <NUM>-<NUM> is intact by checking the received core layer hash value <NUM>-<NUM> against a computed hash of the received 2D code image data <NUM> itself, along with any accompanying additional user data if present in the core layer <NUM>-<NUM>. The data wrapper verifier <NUM> also extracts the transaction data <NUM> for subsequent processing depending on the particular implementation context. The data wrapper verifier <NUM> may transmit the core data layer <NUM>-<NUM> to a user application 95b of a recipient device 9b, for output on a display <NUM>' whereby an additional visual check of the embedded low-resolution image can be performed by the recipient user.

In this embodiment, the data wrapper verifier <NUM> also transmits the 2D code image data <NUM> of the received core data layer <NUM>-<NUM> to the authentication server <NUM>, for processing by an authentication module <NUM>. The 2D code and user identity verification processing by the authentication module <NUM> is similar to the processing described with reference to <FIG> or <FIG> in the embodiments above. After positive verification by the authentication module <NUM>, an output authentication token <NUM> may be returned to the application module <NUM> of the application server <NUM>. Alternatively or additionally, the authentication server <NUM> may also return a retrieved/decrypted high-resolution image 23b to the application server <NUM>, for example to be forwarded to the recipient device 9b for output on the display <NUM>' as yet a further manual visual verification.

In this way, the identity verification process involves checks on the Wrapper <NUM> and Wrapper <NUM> data layers <NUM>-<NUM>,<NUM>-<NUM> as initiated by the application server <NUM>, and involving subsequent check of the core data layer <NUM>-<NUM> by the authentication server <NUM>, to verify that the low-resolution image incorporated into the 2D code <NUM> could not have been tampered with or fraudulently produced. In response to receiving the authentication token <NUM> from the authentication server <NUM>, the application module <NUM> may execute further processing steps to complete the verified transaction, depending on the user application implementation context.

Another embodiment of the invention will now be described with reference to <FIG>, using corresponding reference numerals to those of preceding figures where appropriate for corresponding elements, for a system <NUM> configured to generate and verify the authenticated 2D image code in the form of an electronic tag, representing for example an admission ticket or invitation to a forthcoming event such as a concert, hotel reservation, VIP meeting, etc. In this embodiment, the procedure is typically initiated by using an application <NUM> on a user's mobile computing device 9a, such as a smartphone. A code generator <NUM> of the user application <NUM> receives image data of the user's face, captured for example as a high resolution digital photograph by a camera <NUM> of the user device 9a. The code generator <NUM> also receives source data <NUM> generated by a source data generator 41a of the user application <NUM>, such as transaction data of the event associated with the electronic tag, e.g. user ID and other credentials, event date, place and venue, etc. depending on the implementation context.

As described above with reference to <FIG>, the code generator <NUM> generates a 2D code <NUM> from the received source data <NUM> and captured image data <NUM>, the generated 2D code <NUM> incorporating pixel data representing a low-resolution image <NUM> of the user's face that is derived from the received higher resolution image data <NUM>. The original high-resolution image <NUM> is stored as verification data <NUM> in a secure user database <NUM> of the remote authentication server <NUM>, for example as user data <NUM> associated with the user identifier <NUM>, for subsequent retrieval by the authentication module <NUM> to verify the authenticity of the electronic tag <NUM>. In some embodiments, the high-resolution image data <NUM> is stored in an encrypted form, using a cryptographic key of the associated user. In other embodiments, the verification data may additionally or alternatively include profile data such as biometric signature data associated with the user, e.g. fingerprint, voiceprint, retina/iris scan, etc., and/or visible feature data, e.g. facial characteristics, and/or any other identifying data, e.g. password, PIN, etc., which may be received from the user via suitable input interfaces (not shown) of the user device 9a.

The generated 2D code <NUM> is passed to a tag generator <NUM>-<NUM> of the user application <NUM>, to generate data defining the electronic tag <NUM>, including the generated 2D code <NUM> data. Thus, the 2D code <NUM> embeds data that binds the user to the event associated with the electronic tag <NUM>. It is appreciated that part or all of the code generator <NUM> and/or tag generator <NUM>-<NUM> functionality may be provided at the corresponding application server <NUM> and/or the authentication server <NUM>.

In this exemplary embodiment, the authentication server <NUM> also includes a verification data generator <NUM>, as discussed above with reference to <FIG>, that is configured to iteratively alter the user's original verification data until the calculated cryptographic hash value from the altered verification data and the calculated cryptographic hash value from the 2D code data <NUM> satisfy a defined correspondence relationship. For example, as discussed in embodiments above, iterative image processing may be carried out by a verification data generator <NUM> provided at the authentication server <NUM> to derive a manipulated version of the received image data <NUM> that embodies the verifiable trait of a corresponding calculated hash value having a defined number, or threshold number, of digits in common with the hash value calculated from the image data of the generated 2D code <NUM> or electronic tag <NUM>. Alternatively or additionally, the verification data generator <NUM> may be configured to derive a manipulated version of other forms of original verification data associated with the originating user or entity.

For increased security, the 2D code <NUM> may include a user issued PIN or information input by the user. The 2D code <NUM> may also include user biometric input such as a fingerprint. In such alternatives, the hash of the 2D code <NUM> may be arranged to have digits in common with the hash of the high resolution image plus any user data/biometric data stored in the user database <NUM>. This provides a further advantage of preventing fraud for example if the user's device is stolen and the 2D code image <NUM> being presented by a similar looking person at the admission event. Additionally, the captured high resolution image <NUM> as communicated to the authentication server <NUM> may be processed by the authentication server <NUM> to compare the received image data <NUM> to other high resolution images of the user stored in the database <NUM> for additional user verification.

The electronic tag <NUM> data may be stored in a memory <NUM> of the user device 9a, for subsequent retrieval and output, for example on a display (not shown) of the user device 9a for capture by the camera <NUM> of the terminal <NUM> as discussed in the embodiments above. As shown in <FIG>, in this embodiment, the electronic tag <NUM> is retrieved from the memory <NUM> by the user application <NUM>, and transmitted by a tag transmitter 1205a to a corresponding receiver interface 1205b of a terminal <NUM>' and/or the application server <NUM>, for example. The tag transmitter 1205a and receiver 1205b may be configured to communicate data over the data network <NUM> and/or over a data communication link, for example using radio such as Mobile, Bluetooth® or WiFi® or by near field communications (NFC). The electronic tag <NUM> with 2D code image <NUM> is processed by the terminal <NUM>', which in this embodiment, communicates the 2D code <NUM> data to the authentication server <NUM> for verification by the authentication module <NUM>, as discussed in the embodiments above.

Once the electronic tag <NUM> is validated by the terminal <NUM>', for example including verification by the authentication module <NUM> of hash values in common between the 2D code <NUM> from the electronic tag <NUM> and the corresponding verification data <NUM>, such as the high resolution user image, stored in the user database <NUM>, the terminal <NUM>' may output a validation message along with the high resolution user image on the display <NUM>, for additional manual verification for example by an agent of the admission event. Yet further steps of user validation may include the agent requesting a PIN or biometric data input from the user, which may be hashed and combined with the hash of the 2D code <NUM> for comparison with the hash of the verification data <NUM> stored in the user database <NUM>.

Various aspects of the present invention can be implemented by software, firmware, hardware, or a combination thereof. <FIG> illustrates an example computer system <NUM> in which the present invention, or portions thereof, can be implemented as computer-readable code. For example, the methods illustrated by the flowcharts of <FIG> and <FIG> can be implemented in system <NUM>. The component architectures of the systems and system components shown in <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, <FIG> and <FIG> can also each be implemented in system <NUM>. Various embodiments of the invention are described in terms of this example computer system <NUM>. After reading this description, it will become apparent to a person skilled in the relevant art how to implement the invention using other computer systems and/or computer architectures.

Computer system <NUM> includes one or more processors, such as processor <NUM>. Processor <NUM> can be a special purpose or a general-purpose processor. Processor <NUM> is connected to a communication infrastructure <NUM> (for example, a bus, or network).

Computer system <NUM> also includes a main memory <NUM>, preferably random access memory (RAM), and may also include a secondary memory <NUM>. Secondary memory <NUM> may include, for example, a hard disk drive <NUM>, a removable storage drive <NUM>, flash memory, a memory stick, and/or any similar non-volatile storage mechanism. Removable storage drive <NUM> may comprise a floppy disk drive, a magnetic tape drive, an optical disk drive, a flash memory, or the like. The removable storage drive <NUM> reads from and/or writes to a removable storage unit <NUM> in a well-known manner. Removable storage unit <NUM> may comprise a floppy disk, magnetic tape, optical disk, etc. which is read by and written to by removable storage drive <NUM>. As will be appreciated by persons skilled in the relevant art(s), removable storage unit <NUM> includes a non-transitory computer usable storage medium having stored therein computer software and/or data.

In alternative implementations, secondary memory <NUM> may include other similar means for allowing computer programs or other instructions to be loaded into computer system <NUM>. Such means may include, for example, a removable storage unit <NUM> and an interface <NUM>. Examples of such means may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM, or PROM) and associated socket, and other removable storage units <NUM> and interfaces <NUM> which allow software and data to be transferred from the removable storage unit <NUM> to computer system <NUM>.

Computer system <NUM> may also include a communications interface <NUM>. Communications interface <NUM> allows software and data to be transferred between computer system <NUM> and external devices. Communications interface <NUM> may include a modem, a network interface (such as an Ethernet card), a communications port, a PCMCIA slot and card, or wireless communications.

Computer system <NUM> may additionally include computer display <NUM>. According to an embodiment, computer display <NUM>, in conjunction with display interface <NUM>, can be used to display interfaces of the terminals, user devices and/or user applications depicted for example in <FIG>, <FIG>, <FIG>, <FIG>, <FIG> and <FIG>.

In this document, the terms "computer program medium," "non-transitory computer readable medium," and "computer usable medium" are used to generally refer to media such as removable storage unit <NUM>, removable storage unit <NUM>, and a hard disk installed in hard disk drive <NUM>. Computer program medium, computer readable storage medium, and computer usable medium can also refer to memories, such as main memory <NUM> and secondary memory <NUM>, which can be memory semiconductors (e.g. DRAMs, etc.). These computer program products are means for providing software to computer system <NUM>.

Computer programs (also called computer control logic) are stored in main memory <NUM> and/or secondary memory <NUM>. Computer programs may also be received via communications interface <NUM>. Such computer programs, when executed, enable computer system <NUM> to implement the present invention as discussed herein. In particular, the computer programs, when executed, enable processor <NUM> to implement the processes of the present invention, such as the steps in the methods illustrated by flowcharts of <FIG> and <FIG> and system component architectures of <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, <FIG> and <FIG> discussed above. Accordingly, such computer programs represent controllers of the computer system <NUM>. Where the invention is implemented using software, the software may be stored in a computer program product and loaded into computer system <NUM> using removable storage drive <NUM>, interface <NUM>, hard drive <NUM>, or communications interface <NUM>.

The invention is also directed to computer program products comprising software stored on any computer useable medium. Such software, when executed in one or more data processing device, causes a data processing device(s) to operate as described herein. Embodiments of the invention employ any computer useable or readable medium, known now or in the future. Examples of computer useable mediums include, but are not limited to, primary storage devices (e.g., any type of random access memory), secondary storage devices (e.g., hard drives, USB memory sticks, floppy disks, CD ROMS, ZIP disks, tapes, magnetic storage devices, optical storage devices, MEMS, nano-technological storage device, etc.), and communication mediums (e.g., wired and wireless communications networks, local area networks, wide area networks, intranets, cloud based services, etc.).

It will be understood that embodiments of the present invention are described herein by way of example only, and that various changes and modifications may be made without departing from the scope of the invention.

For example, in embodiments described above, in embodiments described above, the two-dimensional code comprises graphical elements representing a lower-resolution image of the user's face, and the two-dimensional code is associated with a corresponding higher-resolution image of the user's face stored for example in a secure database of a remote server. As those skilled in the art will appreciate, the two-dimensional code may include graphical elements representing an image of the user's face and/or any other form of data that can be used to identify the user, such as other visible, distinctive and measurable features of the user, data representing a distinctive characteristic associated with the user, etc..

As another alternative, the code generator may instead or additionally be configured to generate a two-dimensional code comprising graphical elements representing a second 2D barcode, the second 2D barcode encoding information that can be used for identification verification by a corresponding authentication module. For example, the hash value calculated based on pixel values representing the lower-resolution user image may be encoded into the second 2D barcode, for subsequent verification by the data verifier against the computed hash of retrieved data. Furthermore, the second 2D barcode could include further encoded information for additional user identity verification, such as user profile data, details of an associated transaction, meeting, appointment, etc..

As another example, in embodiments described above, the 2D code encodes key information including a user identifier and a cryptographic key associated with the authorised owner of the identification pass. As those skilled in the art will appreciate, the encoded key information may not include the cryptographic key itself. Instead, the decoded key information may be used to identify and retrieve the associated user's cryptographic from a secure database, for example based on the decoded user identifier.

As another example, in embodiments described above, the terminal includes a camera that captures image data of a 2D barcode from an identification pass presented to the terminal, and the captured image data is processed by a decoder to decode the key information encoded therein. As those skilled in the art will appreciate, the terminal may instead include a 2D barcode scanner module that captures and decodes the encoded data. As yet another alternative, data defining the 2D barcode may be stored in a memory of an electronic pass and communicated to the terminal via a communication interface, such as wireless or an RFID or NFC interface.

It will be appreciated that although the respective processes and associated processing modules are described as separate embodiments, aspects of the described embodiments can be combined to form further embodiments. For example, alternative embodiments may comprise one or more of the authentication module and QR wrapper data structure aspects described in the above embodiments.

As yet another alternative, the authentication module or authentication server modules, may be provided as one or more distributed computing modules or processing services on a remote server that is in communication with the other system components via a data network. Additionally, as those skilled in the art will appreciate, the authentication module functionality may be provided as one or more application programming interface (API) accessible by an application program executing on a user device or terminal, or as a plug-in module, extension, embedded code, etc., configured to communicate with an application program.

Claim 1:
A data verification method comprising steps performed by one or more computing devices of
receiving code data defining a two-dimensional code (<NUM>) encoding a user ID associated with verification data of the user in a remote database (<NUM>), the two-dimensional code including a low-resolution version of an image of the user's face;
processing the received code data to decode the user ID;
retrieving, from the remote database, the verification data associated with the decoded user ID, wherein the verification data includes a high-resolution version of the image of the user face that is computationally manipulated to have a calculated cryptographic hash value which satisfies a defined correspondence relationship with a cryptographic hash value calculated from the low-resolution version of the image;
calculating a first cryptographic hash value from at least the low-resolution version of the image of the received code data;
calculating a second cryptographic hash value from the manipulated high-resolution version of the image of the user face of the retrieved verification data,; and
verifying the authenticity of the received code data based on a comparison of the first cryptographic hash value with the second cryptographic hash value.