WO2018109014A1

WO2018109014A1 - Authentication systems and methods

Info

Publication number: WO2018109014A1
Application number: PCT/EP2017/082642
Authority: WO
Inventors: Klaas Zwart
Original assignee: HANSCAN IP BV
Current assignee: HANSCAN IP BV
Priority date: 2016-12-13
Filing date: 2017-12-13
Publication date: 2018-06-21
Anticipated expiration: 2019-06-13
Also published as: GB201621176D0

Abstract

An authentication system (100) is described. The system (100) comprises a plurality of user terminals (120), each being associated with a single user and comprising a transmitter (170) configured to communicate with a matching database (110) configured to store a plurality of authentication records. Each record comprises authentication data relating to a particular user. The system (100) comprises a secure network (400) comprising one or more servers (500) in communication with the matching database (110). Each terminal (120) is operable to communicate authentication data from the user terminal (120) to the matching database (110). The system (100) is configured to provide a positive authentication response in the event of a match between the data at the appropriate data record for a user terminal (120) and the received authentication data. In the event of a positive authentication, a user of the user terminal (120) is provided access to the secure network (400) via the matching database (110).

Description

Authentication Systems and Methods

Technical Field

Described examples relate to systems, methods and other apparatus for use with authentication, such as authentication of individuals. Some examples relates to systems and methods for providing authenticated access.

Background User authentication is now common throughout modern life, whether that authentication be for the purposes providing access to an e-mail account, initiating a transaction, travelling between countries, or even verifying a person's age.

In many cases, however, there is often a technical conflict between providing an authentication process that is straightforward and that does not cause undue burden to any party to the process, while at the same time providing a process that is sufficiently secure so that the veracity of the authentication process can be relied upon. At one extreme, a simple authentication process provided by a password is easy to use but is more susceptible to hacking or spoofing, while at the other extreme, complex multi- factorial layered processes of access and complex encryptions are more likely to validly authenticate a user, but are less easy to use.

Hacking and cybercrime often occur due to weakness in an authentication process. For example, for a system to identify a user, it is often the case that only a user ID and password are identified and so the actual user, e.g. an online visitor, never are. Therefore, provided that the user ID and password is correct, access will be granted by the system. Further, if an unscrupulous party were able to gain access to a system in this manner, then of course such access may essentially be anonymous. This can often be seen as a boon for cybercriminals. More recently, there has been a drive towards using more complex forms of user IDs, such a biometric ID. In such examples, it can often be the case that if a biometric ID is stolen or replicated, then they essentially function in same way as normal IDs, potentially giving rise to unauthorised access to any person. Where stolen IDs can be cancelled and replaced, biometric IDs on the other hand, when taken, are lost for life. One cannot keep on changing one's limbs. Many countries already store fingerprints for future backdoor access, for when the biometric access era comes on stream.

There is a continuing need to provide improved systems, methods and other apparatus for use with authentication, such as authentication of individuals, whether that be for the purposes of logical or physical access, authorising payment, age verification, or the like. There is also a need to provide a robust authentication process that can be used across many platforms, and for multiple different types of authentication.

This background serves only to set a scene to allow a skilled reader to better appreciate the following description. Therefore, none of the above discussion should necessarily be taken as an acknowledgement that that discussion is part of the state of the art or is common general knowledge. One or more aspects/embodiments of the invention may or may not address one or more of the background issues. Summary In some examples, there are described authentication systems and methods. Those systems and methods, and other apparatus for use with authentication, may assist in improved authentication of a user for the purposes of logical or physical access, authorising payment, age verification, or the like.

In some examples, there is described an authentication system.

The system may comprise a plurality of user terminals. Each terminal may be associated with a single user. Each terminal may comprise a transmitter configured to communicate with a matching database.

The system may comprise a dedicated matching database configured to store a plurality of authentication records. Each record may comprise authentication data relating to a particular user.

Each terminal may be operable to communicate authentication data from the user terminal to the matching database. In those examples, the matching database may comprise an authentication unit configured to compare the authentication data that is received from that user terminal together with a data record associated with that user. The matching database (e.g. a transmitter at the matching database) may be configured to provide an authentication response in the event of a match between the data at the appropriate data record for that user terminal and the received authentication data from that data terminal. Each terminal may be associated with a single user such that that terminal may be considered to be a "personal" device, i.e. personal to that user only. In other similar words, the system may comprise a plurality of user terminals and a plurality of users, with each terminal being identifiable and associated with a different user. In some cases, it may be said that each terminal is configured for exclusive use with a single user. Each authentication record associated with a user at the matching database may store, with that record, data identifying the user's terminal. In some examples, each terminal may have a particular unique identifier, such as a unique serial number, or the like.

Some or all terminals may comprise some form of user sensor, such as a biometric sensor. If a biometric sensor is used, then that biometric sensor may be configured to permit the system to obtain biometric data derived from a user. For example, each terminal may comprise a biometric sensor configured to obtain a representation of one or more biometric properties of a user (e.g. one or more fingerprints).

In some cases, some or all terminals may comprise a fingerprint sensor configured to obtain a representation of one or more fingerprints of a user. Such terminals may comprise a convertor configured to convert the representation from the biometric sensor into unique biometric data. That biometric data may be considered to be an abstraction, such as a unique abstraction, of the biometric representation. The sensor may be configured to obtain a 3D representation of the biometric properties of a user (e.g. a 3D representation of a user's fingertip). That 3D representation may be used by the convertor in order to provide biometric data.

The convertor may be configured to implement a conversion algorithm in order to provide biometric data. That conversion algorithm may be selected from a number of potential algorithms for use at terminals (e.g. each time the biometric data is obtained). That conversion algorithm may be unique to that particular terminal. For example, the biometric data may correspond to the representation of one or more biometric properties of the user in manner that is unique or rare across all terminals within the authentication system. The terminal may be configured to convert the biometric representation obtained from the sensor into biometric data such that, while relating to the biometric representation, may not be readily reconstructable to derive again the biometric representation (e.g. without an understanding of algorithm and how the biometric data was obtained in the first instance).

Each terminal may be configured to obtain authentication data for subsequent communication with the matching database (e.g. at or around the time of an authentication request). An authentication request may be a request for authentication for the purposes of physical or digital access, for payment, age verification, etc. An authentication request may be initiated by the system (e.g. by the user terminal), and/or may be initiated by a third party. Such a third party may be in communication with the user terminal, and may be configured to initiate the authentication request. The terminals may be configured to require user activation in order to provide a response to an authorisation request (e.g. in order to generate/communicate authentication data in response to an authentication request).

Some or all of the terminals may be configured to generate biometric data in response to a user activation or other such action. In other similar words, the terminal may be configured to receive an activation input from the user. The terminal may be configured to generate the biometric data at the time of the activation input (e.g. simultaneously). Such user activation input may include a specified user action, such as a swipe and/or press at the terminal (e.g. at the sensor). In some examples, the terminal may comprise an auxiliary sensor. The auxiliary sensor may be configured to identify a proof of life of the user. For example, the sensor may measure one or more of temperature, haemoglobin, heart beats, neural sensor, etc. The auxiliary sensor may be incorporated together with the biometric sensor.

The terminal may comprise one or more tamper respondent sensors. Such tamper respondent sensors may be configured to modify (e.g. erase) data stored at the terminal in the event of a detected tampering event of the terminal (e.g. attempted unauthorised access).

The terminal may be configured to communicate authentication data comprising biometric data of a user of that particular terminal together with the particular unique identifier of the terminal. In some examples, the terminal may comprise a compiler configured to compile authentication data for transmission to the matching database, e.g. using the transmitter of user terminal.

The compiler may be configured to apply a time stamp to the authentication data (e.g. prior to transmission). The compiler may be configured to hash the authentication data to a particular data size for subsequent transmission. The compiler may be configured to encrypt authentication data for subsequent transmission.

Each authentication record stored at the matching database that relates to a particular user may comprise data associated a particular user's terminal (e.g. a terminal unique identifier) together with permitted biometric data for that user (e.g. for that known user of that known terminal). The authentication records may comprise additional user data, such as name, age, etc. The authentication unit may be configured to compare the authentication data received from that user terminal (e.g. after an authentication request) together with a data record associated with that user in order to provide an authentication response. For example, the authentication unit of the matching database may be configured locate a data record associated with the user terminal (e.g. using the unique identifier of the user terminal) and then compare the received biometric data with the biometric data of that record. In the event that the received biometric data is the same as biometric data for that data record, then the system (e.g. matching database) may be configured to provide an authentication response.

When a positive authentication response is provided, the system may be configured to provide access to a secure network (e.g. comprising hosting servers). In such a way, access to those servers may only be possible if an authentication is positively provided. In some examples, the system may be considered to provide a gateway to the secure network. In other similar words, the system may be configured such that access to the secure network is possible via the matching database.

In some examples, the system may be considered to comprise the secure network (i.e. the system itself not only comprises the matching database, etc., but also the secure network). Access to the secure network may only be provided via the system, e.g. via the matching database. In other words, in some examples, it may only be possible to communicate with the secure network via the matching database (or via authorisation from the matching database). The matching database may be configured to store (e.g. at a data record) access events, e.g. occurrences of user access. In some cases, the secure network of the system may comprise a plurality of servers. Some or all of the servers may be located at different geographical regions or locations. In such cases, the servers may nevertheless communicate with the matching database (e.g. via trusted connections). Access to those servers may only be possible via a positive authentication by the system (e.g. at the matching database).

The system may be configured such that each server at the secure network might be accessible after a positive authentication has been provided by the matching database. Such servers may comprise e-mail servers, banking servers, etc. In some examples, access to the servers may only be possible after a positive authentication response is provided.

In alternative/additional examples, that authentication response may be communicated back to the user terminal. From that terminal, the response may be communicated to a third party for authentication. Otherwise, that authentication response may be communicated directly to a third party.

In some cases, the authentication unit may be configured to use the time stamp of received authentication data in order to provide an authentication response. For example, where the time stamp suggest that the authentication data was transmitted beyond a defined time threshold (e.g. greater than 1 second, 3 seconds, 5 seconds, etc.) then the authentication unit may be configured not to provide authentication, even if biometric data were to match with data stored at the specified record. The matching database may be configured to provide an authentication response via one or more channels, for example, to a third party (e.g. a point of sale, a bank, etc.). The matching database may be configured such that access is limited such that only requests for authentication emanating from user terminals that have a corresponding data record have access to the database. The matching database may be configured to perform a database check from time to time, e.g. periodically. Such database check may be verify data, such as internal signatures, or other modification in the core system.

The matching database may be configured such that administrator access is permitted via a user terminal, as mentioned above. Operations performed by the system administrator may be monitored and/or saved, e.g. at the database.

The authentication system may be configured to permit user enrolment with the matching database (e.g. additional user enrolment). In some examples, subsequent to establishment of the matching database together with the plurality of user terminals, further user terminals and data records may be enrolled.

In some examples, the system may be configured to permit different levels of enrolment. Each enrolment level may provide a particular level of authentication veracity. An enrolment level of a particular user terminal may be stored together with a corresponding data record.

The matching database may be configured to communicate the enrolment level of a particular user terminal at the time of an authentication response. For example, the enrolment level may be communicated to the user terminal, or to a third party directly. In some examples, the user terminal may store and communicate the enrolment level (e.g. to a third party). The enrolment levels may include a low level enrolment. For such an enrolment, the end user of a terminal may validate/certify the data record stored at the matching database. The enrolment levels may include a high level enrolment. For such an enrolment, a trusted administrator (e.g. government official) may validate/certify the data record stored at the matching database. The enrolment levels may include a medium level enrolment. For such an enrolment, a trusted intermediator (e.g. a bank) may validate/certify the data record stored at the matching database. Each authentication record stored at the matching database that relates to a particular user may comprise data associated a particular enrolment level of that terminal/user.

The authentication system (e.g. the user terminals and matching database) may define an access protocol. In other words, authentication system may be used/accessible by third parties in order to authenticate users in a manner that has not be performed previously. The system may share common hardware, firmware and/or software.

In some examples, there is described an authentication system comprising:

a plurality of user terminals, each terminal being associated with a single user and comprising a transmitter configured to communicate with a matching database, a dedicated matching database configured to store a plurality of authentication records, each record comprising authentication data relating to a particular user,

a secure network comprising one or more servers in communication with the matching database; and

wherein each terminal is operable to communicate authentication data from the user terminal to the matching database, and wherein the matching database comprises an authentication unit configured to compare the authentication data that is received from that user terminal together with a data record associated with that user, and wherein the system is configured to provide a positive authentication response in the event of a match between the data at the appropriate data record for that user terminal and the received authentication data from that data terminal, and further wherein, in the event of a positive authentication, a user is provided access to the secure network via the matching database.

In some examples, access to the secure network is possible only in the event of a positive authentication response from the matching database.

In some examples, there is provided one or more user terminal for use with an authentication system described.

In some examples, there is described one or more matching databases configured for use with the system described above.

In some examples, there is a method for authenticating a user, the method comprising: responsive to an authentication request, communicating authentication data from a user terminal to a matching database, the user terminal being associated with a single user and the matching database storing a plurality of authentication records, each record comprising authentication data relating to particular users,

receiving the authentication data from the user terminal at the matching database and comparing the authentication data that is received from that user terminal together with a data record associated with that user, and

providing a positive authentication response in the event of a match between the data at the appropriate data record for that user terminal and the received authentication data from that data terminal so as to provide user access, via the matching database, to a secure network comprising one or more server.

The method may comprise receiving, at the user terminal, biometric data derived from a user. For example, the method may comprise obtaining a representation of one or more biometric properties of a user (e.g. one or more fingerprints). The method may comprise obtaining a representation of one or more fingerprints of a user. The method may comprise converting the representation from the biometric sensor into unique biometric data. That biometric data may be considered to be an abstraction, such as a unique abstraction, of the biometric representation.

The method may comprise obtaining a 3D representation of the biometric properties of a user (e.g. a 3D representation of a user's fingertip). The method may comprise converting that 3D representation in order to provide biometric data. The method may comprise implementing a conversion algorithm in order to provide biometric data. That conversion algorithm may be selected from a number of potential algorithms for use at terminals. That conversion algorithm may be unique to that particular terminal. For example, the biometric data may correspond to the representation of one or more biometric properties of the user in manner that is unique or rare across all terminals within the authentication system.

The method may comprise converting the biometric representation obtained from the terminal into biometric data such that, while relating to the biometric representation, may not be readily reconstructable to derive again the biometric representation (e.g. without an understanding of algorithm and how the biometric data was obtained in the first instance). The method may comprise obtaining authentication data for subsequent communication to the matching database (e.g. at or around the time of an authentication request). An authentication request may be a request for authentication for the purposes of for physical or digital access, for payment, age verification, etc.

The method may additionally comprise initiating an authentication request by the system (e.g. by the user terminal), and/or initiating by a third party. Such a third party may be in communication with the system (e.g. user terminal), and may be configured to initiate the authentication request. The method may comprise requiring user activation in order to provide a response to an authorisation request (e.g. in order to generate/communicate authentication data in response to an authentication request).

The method may comprise generating biometric data in response to a user activation or other such action. In other similar words, the method may comprise receiving an activation input from the user at the terminal. The method may comprise generating the biometric data at the time of the activation input (e.g. simultaneously). Such user activation input may include a specified user action, such as a swipe and/or press at the terminal (e.g. at the sensor). The method may comprise identifying a proof of life of the user. For example, the method may comprise measuring one or more of temperature, haemoglobin, heart beats, etc. at the terminal.

The method may comprise modifying (e.g. erasing) data stored at the terminal in the event of a detected tampering event at the terminal (e.g. attempted unauthorised access). The method may comprise communicating authentication data comprising biometric data of a user of that particular terminal together with the particular unique identifier of the terminal. In some examples, the method may comprise compiling authentication data for transmission to the matching database, e.g. using a transmitter of user terminal.

The method may comprise applying a time stamp to the authentication data, prior to transmission. The method may comprise hashing the authentication data to a particular data size for subsequent transmission. The method may comprise encrypting authentication data for subsequent transmission.

Each authentication record stored at the matching database that relates to a particular user may comprise data associated a particular terminal with a user (e.g. a terminal unique identifier) together with permitted biometric data for that user. The authentication records may comprise additional user data, such as name, age, etc.

The method may comprise comparing the authentication data received from that user terminal (e.g. after an authentication request) together with a data record associated with that user in order to provide an authentication response. For example, the method may comprise locating a data record associated with the user terminal (e.g. using the unique identifier of the user terminal) and then comparing the received biometric data with the biometric data of that record. In the event that the received biometric data is the same as biometric data for that data record, then the method may comprise providing, from the system (e.g. from the matching database), an authentication response. Responsive to a positive authentication response, the method may comprise providing access to the secure network (e.g. comprising one or more servers, such as hosting servers). In such a way, access to those servers may only be possible if an authentication is positively provided. In some examples, the method may be considered to be a process of provided gated-access to such a secure network. In other similar words, the method may provide an access protocol. That is to say that, in some examples, the only manner in which those secure servers can be accessed is via the matching database. The method may comprise accessing one or more servers provided at the secure network after a positive authentication has been provided. Such servers may comprise e-mail servers, banking servers, etc. In some examples, access to the servers may only be possible after a positive authentication response is provided. In alternative/additional examples, the method may comprise communicating an authentication response back to the user terminal. The method may comprise communicating, from that terminal, the response a third party for authentication. Otherwise, that authentication response may be communicated directly to a third party. The method may comprise using the time stamp of received authentication data in order to provide an authentication response. For example, where the time stamp suggests that the authentication data was transmitted beyond a defined time threshold (e.g. greater than 1 second, 3 seconds, 5 seconds, etc.) then the method may not to provide authentication, even if biometric data matches with the specified record.

The method may comprise providing an authentication response via one or more channels, for example, to a third party (e.g. a point of sale, a bank, etc.) The method may comprise performing a database check of the matching database from time to time, e.g. periodically. Such database check may verify data, such as internal signatures, or other modifications in the core system.

The method may comprise permitting additional user enrolment with the matching database. In such examples, subsequent to establishment of the matching database together with the plurality of user terminals, further user terminals and data records may be enrolled.

The method may comprise permitting different levels of enrolment. Each enrolment level may provide a particular level of authentication veracity. An enrolment level of a particular user terminal may be stored together with a corresponding data record. In some examples, the method may comprise communicating the enrolment level of a particular user terminal at the time of an authentication response. For example, the enrolment level may be communicated to the user terminal, or to a third party directly. In some examples, the user terminal may store and communicate the enrolment level (e.g. to a third party).

The enrolment levels may include a low level enrolment. For such an enrolment, the method may comprise permitting an end user of a terminal to validate/certify the data record stored at the matching database. The enrolment levels may include a high level enrolment. For such an enrolment, the method may comprise permitting a trusted administrator (e.g. government official) to validate/certify the data record stored at the matching database. The enrolment levels may include a medium level enrolment. For such an enrolment, the method may comprise permitting a trusted intermediator (e.g. a bank) to validate/certify the data record stored at the matching database.

Each authentication record stored at the matching database that relates to a particular user may comprise data associated a particular enrolment level of that terminal/user.

In some examples, there is described a computer program product that when programmed into a suitable controller configures the controller to perform any methods disclosed herein. There may be provided a carrier medium, such as a physical or tangible and/or non-transient carrier medium, comprising the computer program product. The carrier medium may be a computer readable carrier medium. In some examples, there is also provided processing apparatus when programmed with the computer program product described. Some of the above examples may implement certain functionality by means of software, but also that functionality could equally be implemented solely in hardware (for example by means of one or more ASICs (application specific integrated circuit) or Field Programmable Gate Arrays (FPGAs)), or indeed by a mix of hardware and software (e.g. firmware). Further, it will be appreciated that some examples may be implemented across a network, and so may comprise multiple hardware/software components that, when enabled, work operatively together. As such, the scope of the disclosure should not be interpreted as being limited only to being implemented in software or hardware. The invention includes one or more corresponding aspects, embodiments or features in isolation or in various combinations whether or not specifically stated (including claimed) in that combination or in isolation. As will be appreciated, features associated with particular recited embodiments relating to systems may be equally appropriate as features of embodiments relating specifically to methods of operation or use, and vice versa. It will be appreciated that one or more embodiments/aspects may be useful in effective and secure authentication of users.

The above summary is intended to be merely exemplary and non-limiting. Brief Description of the Figures

A description is now given, by way of example only, with reference to the accompanying drawings, in which:- Figure 1 shows an example of an authentication system according to an example;

Figure 2 shows in more detail the authentication system of Figure 1 and one particular user terminal;

Figure 3a shows an example of an authentication system in use; Figure 3b shows a secure network of the system; and Figure 3c shows an additional/alternative use of the authentication system; and

Figure 4 shows an example of representative diagram of the process of authentication; Description of Specific Embodiments As explained above, there is a need for improved ways in which to authenticate users to ensure that authentication can occur with ease, but that any authentication is robust and can be trusted. Such proper authentication can provide secure and robust access to a secure network, for example.

The following described examples relate to new systems and methods that provide exemplary ways of authenticating a user, which take an entirely different approach that would otherwise have been considered previously. Some examples specifically described a secure network together with a new access protocol for such a network. In some examples, the only manner in which the secure network can be accessed is by using the access protocol described below. The described examples provide a robust authentication process that can be used across many platforms, and for multiple different types of authentication. It will be appreciated that authentication may be used for a number of different reasons, such as physical access (e.g. access to a building, vehicle or the like), logical access (e.g. access to a website, e-mail server, etc.), authentication for payment or other financial transactional means, or indeed authentication for the purposes of confirming specific personal details such as age, etc. It is envisaged that the described examples may be used for authentication of users across such a range of circumstances, and a skilled reader will readily be able to implement the various embodiments accordingly. In that regard, the following described examples may be considered to provide a new access protocol that can be used to authenticate users across a number of platforms and in a number of different environments.

Figure 1 shows an example of an authentication system 100. As will be further explained, such an authentication system 100 may be consider to be provided as an end-to-end security environment, comprising a dedicated matching database 1 10 together with a plurality of user terminals 120. Here, the matching database 1 10 and user terminals 120 may support access control and user authentication, as will be described. It will be appreciated that aspects of the system's 100 hardware, firmware, software, communications, etc. may be shared between the matching database 1 10 and the user terminals 120. That is to say that dedicated communication protocols, implemented algorithms, encryptions, etc. may be commonly provided across the matching database 1 10 and user terminals 120. Each of the user terminals 120 may be in communication with the database 1 10 via a network 130. While the network may comprise the Internet, in other cases that network may be a dedicated network providing a link between the end user at the terminal 120 and specifically the matching database 1 10. Depending on application, each of the user terminals 120 may be implemented differently, for example a user terminal 120 may be connected or connectable to a personal computer, mobile device, etc. (e.g. by wired or wireless communication), which in turn can be in communication with a matching database 1 10 via the network 130.

In any event, each terminal 120 is associated with a single user (e.g. exclusively with that user). That is to say that each terminal 120 may be considered to be a personal device, i.e. personal to that user. Here, the system 100 is configured such that each terminal 120 is identifiable and associated with a different user (e.g. a different identifiable user). Here, each terminal 120 has a particular unique identifier, such as a unique serial number, or the like, stored at the terminal 120.

It will be appreciated that any number of terminals 120 may be provided. However, in each case, the system 100 can be configured such each terminal 120 associated with the system 100 is uniquely identifiable on the system 100. In order to associate each user terminal 120 with a particular user, the matching database 1 10 stores authentication records that include data identifying that user's terminal. Further, the dedicated matching database 1 10 is configured to store a plurality of authentication records, each record comprising authentication data relating to a particular user. Each terminal 120 is operable to communicate particular authentication data from the user terminal 120 to the matching database 1 10 (e.g. via the network), and the matching database is configured to compare the authentication data that is received from that user terminal 120 together with a data record associated with that user (e.g. user terminal) in order to provide an authentication response, as will be further described.

Figure 2 shows the matching database 1 10 together with one particular user terminal 120 in more detail. Again, it will be appreciated that the user terminal 120 may be in communication with user devices, such as a tablet, computer, mobile device, etc. Additionally, the terminal 120 may be in communication with other devices having networking capabilities, such as more recently household appliances or the like. In each case, the user terminal 120 may be in communication with such other devices via a wired and/or wireless communication link, as will be appreciated by a skilled reader. However, such user devices are not shown for ease. It will be appreciated also that data may be communicated between the matching database 1 10 and the user terminal using such devices, e.g. using the network 130 connectivity of such devices.

Here, the user terminal 120 comprises a biometric sensor 140 that is configured to receive biometric data derived from a user. In particular, the biometric sensor 140 is configured to obtain a representation of one or more biometric properties of a user, and in this example one or more fingerprints. It will be appreciated that, given the following discussion, alternative sensors 140 may be provided. Here, however, the sensor 140 is configured so as to capture a 3D representation of the biometric properties of a user (e.g. a 3D representation of a user's fingertip). In some examples, the sensor 140 may use a 3D radio frequency sensor in order to essentially capture a 3D image of the user's fingerprint. In such a way, additional information can be captured at the sensor 140, when compared to utilising only a 2D image or the like.

Here, the terminal 120 further comprises a converter 150, which is configured to convert the representation obtained from the biometric sensor 140 into biometric data associated with that user (e.g. unique biometric data). That biometric data may be considered to be an abstraction, such as a unique abstraction, of the biometric representation. Specifically, the convertor 150 is configured to implement a conversion algorithm in order to provide biometric data. In some cases, that conversion algorithm may be selected from a number of potential algorithms for use at the terminal 120. It other words, it may not be the same conversion that is provided each time. Further, any conversion algorithm may be unique to that particular terminal 1 10 (in a similar manner to the serial number). For example, the biometric data may correspond to the representation of one or more biometric properties of the user in manner that is unique or rare across all terminals 120 within the authentication system 100.

In any event, biometric data generated at the terminal 120 may be useable in order to respond to an authorisation request - as will be explained. In some examples, some or all of the terminals 120 may be specifically configured to require user activation in order to generate biometric data. In other similar words, the terminal 120 may be configured to receive an activation input from the user and, in response to that input (e.g. only in response to that input), the terminal 120 generates the biometric data at or around the time of the activation input. Such user activation input may include a specified user action, such as a swipe and/or press at the terminal 120 (e.g. at the sensor 140). In this particular example, a user is required to swipe their finger across the biometric sensor 140 is order for the sensor 140 to active and for the convertor 150 to generate biometric data. In such away, any data generated will have been done so with some indication of user intent.

Further, in some examples, the terminal 120 may comprise an auxiliary sensor 160. Such an auxiliary sensor 160 may be configured to identify a proof of life of the user. For example, the sensor 160 may measure one or more of temperature, haemoglobin, heart beats, neural signals, such as conscious or unconscious neural signals (e.g. using a neural sensor), etc. The auxiliary sensor 160 may be incorporated together with the biometric sensor 140. In such a way, again, the user terminal 120 maybe configured to generate biometric data on the event of confirmed proof of life from the auxiliary sensor 160.

Further, the terminal 120 as shown here comprises a transmitter 170 configured to communicate with a matching database 1 10. In particular, the terminal 1 10 is configured to communicate authentication data comprising biometric data of a user of that particular terminal 1 10 together with, in this example, the particular unique identifier of the terminal 1 10. In some examples, and as is the case here, the terminal 120 further comprises a compiler 180 configured to compile authentication data for transmission to the matching database 1 10, e.g. using the transmitter 170 of the user terminal 120. The compiler 180 in this case is specifically configured to apply a time stamp to the authentication data, prior to transmission. Additionally, the compiler 180 may hash the authentication data to a particular data size for subsequent transmission. Further, the compiler 180 may be configured to encrypt authentication data.

As mentioned, the dedicated matching database 1 10 of the system 100 is configured to store a plurality of authentication records, each record comprising authentication data relating to a particular user. Each authentication record stored at the matching database 1 10 that relates to a particular user may comprise data associated a particular terminal 120 for a user (e.g. a terminal unique identifier) together with permitted biometric data for that user. Of course, the authentication records may - but need not - comprise additional user data, such as name, age, etc.

Here, and as shown in Figure 2, the matching database 1 10 comprises an authentication unit 210 configured to compare the authentication data that is received from that user terminal 120 together with a data record associated with that user. In the event of a match between the data at the appropriate data record for that user terminal 120 and the received authentication data from that user terminal 120, then the system 100 - and in this example the matching database 1 10 - can be configured to provide an authentication response. A positive authentication response may be used at the system 100, e.g. at the matching database 1 10, to provide further user access - as will be described, and/or be communicated to a 3^rd party (e.g. via transmitter 220). An exemplary use of the system 100 will now be described with reference to Figure 3a. Here, by way of an example, the authentication process is performed in relation to providing access to a secure network 400. Here, that network 400 comprises one or more servers 500, such as hosting servers. The servers 500 may provide e-mail client access, or data storage, financial data, or any of the like. In this example, each of these servers 500 are only accessible via use of the system 100 (e.g via the matching database 1 10). Access to the servers 500 may be for user access and indeed administrative access. In other similar words, the system 100 may be configured such that where administrative changes or the like are performed at the servers, then the authentication process may nevertheless need to be followed, as below.

As such, in order to permit appropriate access to those servers 500 (whether it be user access of otherwise), it may be helpful to authenticate a user to ensure that they are rightfully permitted to gain access. An access authorisation request may be initiated, e.g. by the end user. That authentication request may also comprise an access request). In this example, the user terminal 120 may then request biometric data from its user (i.e. the user personally associated with and in possession of that particular terminal 120). By performing a user activation input at the terminal 120 (e.g. a finger swipe), the biometric sensor 140 can obtain a representation of the user's fingerprint. This in turn can be transformed into biometric data by the convertor 150. The auxiliary sensor 160 may be used to indicate that the biometric data has been obtained from a living person.

Subsequently, the compiler 180 may compile authentication data comprising the biometric data together with the identifier of the terminal 120 for subsequent transmission to the matching database 1 10. In this case, in addition the compiler 180 applies a time stamp, as well as optionally hashing/encrypting, etc. Using the transmitter 170 of the user terminal 120, authentication data is communicated for subsequent receipt by the matching database 1 10. It will be appreciated that authentication data may be communicated from a device associated (e.g. tethered) with the user terminal 120. Otherwise, the terminal 120 may communicate with the database itself via the network 130.

At the dedicated matching database 1 10, the authentication unit 210 can be configured to compare the authentication data received from that user terminal 120 (e.g. after the authentication request) together with a data record associated with that user in order to provide an authentication response. It will be readily appreciated that because the system 100 is configured such that each user terminal 120 can be identified in the authentication data, and that each user terminal 120 is associated with a particular user, then one-to-one matching can be performed. In other similar words, the data record associated with that user can be quickly identified and the associated biometric data compared (e.g. matching quicker than 0.5 second). This would not be possible were, for example, only biometric data to be searched in the data records. As such, the system 100 can be implemented to promptly response to an authentication request. After the authentication unit 210 of the matching database 1 10 locates the relevant data record associated with the user terminal 120 (e.g. using the unique identifier of the user terminal 120), it can then compare the received biometric data with the biometric data stored on that record. In the event that the received biometric data is the same as biometric data for that data record, then the matching database 1 10 can provide a positive authentication response. Otherwise, the request and data packet can be discarded. In this case however, the authentication unit 210 also uses the time stamp of received authentication data in order to provide an authentication response. Where the time stamp suggests that the authentication data was transmitted beyond a defined time threshold (e.g. 1 second, 3 seconds, 5 seconds, etc.), then the authentication unit 210 is configured not to provide authentication (or otherwise provide a negative authentication response), even if biometric data matches with the specified record. In such a way, man-in-the-middle attacks can be avoided. Again, this is assisted by the fact that the database 1 10 can quickly locate data. When a positive authentication response is provided, secure access the network 400 can be provided (e.g. an secure access to the servers 500) . In this example, a secure channel 530 can then be provided such that data communicated between the user and servers 500 passes via the matching database 1 10. In such a way, access to those servers 500 may only be possible if an authentication is positively provided.

In this way, the system 100 (e.g. matching database 1 10) may be considered to act as a gate keeper to provide access to one or more servers 500. Due to the required authentication, only those persons that have been properly identified may have access to the network 400 and servers 500. The system 100 may also be configured to store data relating to user access. In other words, the system 100 may store "access data" (e.g. dates, times, identities, etc.) relating to persons who access the secure network 400 (e.g. this may be stored at the matching database 1 10). In such a way, each user of the network may be identified, and not by a simply user ID or the like - which is susceptible to fraud. It will be appreciated that such a secure network may be used for any number of common actions, such as banking, e-mail, shopping, or the like. In some examples, the secure network 400 may provide a dedicated secure network (e.g. a secure financial network) at which institutes store and permit access to data.

While in the example shown in Figure 3a, a single matching database 1 10 is described, it will be appreciated that this, in some cases, may be considered to be by example only. In some cases, as is shown in Figure 3b, the system 100 may comprise multiple matching databases 1 10 providing access to the secure network 400. Each of those databases 1 10 may be contain their own authentication records (e.g. a database 1 10 for a particular region, or the like), or otherwise some or all of the databases 1 10 may share authentication records (e.g. using replication, or the like).

In any event, it will be appreciated by a skilled reader that this implementation and new access protocol is entirely different from that which may have been implemented previously. In such prior examples, access is often provided at a server using, for example, only an ID and password, or the like. In some cases, further layers of security may be provided. However, in the event that access is provided by the server, there is no possibility to accurately identify the actual user. In such a way, the actual user is essentially anonymous. It is only identified that a person has accessed that server with a valid user ID and password, etc. As such, when a hacker or other such cybercriminal maliciously gains access to a server or the like, they essentially pray on the fact that they can hopefully remain anonymous.

With this described system 100, this is not possible. Access to the servers 500 can only be provided after a positive authentication process has been performed. That authentication process is based on a suitably enrolled user in which their user terminal 120 is specifically linked to that person and - in the example described above - that person's biometric data. As such, all visitors are identified. It will be appreciated that in this example access to those servers 500 may only be possible after authorisation by the system (e.g. at the matching database 1 10). In other examples, of course, the matching database 1 10 may additionally or alternatively provide an authentication response for use by a third party. Such a third party may use existing (essentially unsecure) networks, such as the Internet.

Consider now Figure 3c, which also shows the authentication system 100 of Figure 3a. Here, however, the system 100 is configured additionally or alternatively to provide an authentication response to a third party. By way of an example only, the authentication process is performed in relation to a financial transaction at a point-of-sale device 300. It will readily be appreciated that such a point of sale may be physical, or indeed may be virtual, e.g. online. In any event, it may be helpful to authenticate the instructor of the financial transaction in order to ensure that they are the rightful holder of credit details, or the like.

At the time of completing the financial transaction at the point of sale 300 an authorisation request may be initiated by the point-of-sale device 300. The user terminal 1 10 may then request biometric data in a similar manner to that described above.

Using the transmitter of the user terminal 120, authentication data can be communicated for subsequent receipt by the matching database 1 10. In some examples, that authentication data is communicated to the point-of-sale device 300 for subsequent communication to the database 1 10. Otherwise, the terminal 1 10 may communicate with the database itself via the network 130. At the dedicated matching database 1 10, the authentication unit 210 is configured to compare the authentication data received from that user terminal (e.g. after the authentication request) together with a data record associated with that user in order to provide an authentication response, in a similar manner to that described above.

In some examples, an authentication response may be communicated back to the user terminal 120. From that terminal 120, the response may be communicated to the point- of-sale device 300 for authentication. Otherwise, that authentication response may be communicated directly to a third party, e.g. via the network 130 from a trusted address.

In any event (e.g. whether it be the process of Figure 3a, 3b or Figure 3c), Figure 4 shows a representative diagram 600 of the steps of authentication. At a first step 610, it is the user terminal 120 having a unique serial number obtains a user's biometric data in response to an authentication request. At a second step, this may be combined with the user terminal ID. Optionally, this may be performed together with various security features (encryption, time stamp, hash code and digital signature), and this may be compiled together to communicate as a "package". In a third step 430, the dedicated matching database 1 10 searches for the user terminal in the data records. Further, in the next step, the package (including the biometric data) is compared with only 1 specific data record on the database: i.e. the one that corresponds to the assigned serial number. Matching and approval (or not) can then take place. After the (un) successful match, the "package" is deleted.

It will be appreciated that in order to improve the system 100, then it can be helpful to safeguard that the biometric data stored at the database 1 10 corresponds to the user of the user terminal 120. As such, the enrolment of each user terminal 120 may influence the extent to which that can be confirmed. Here, the system 100 is configured to permit additional user enrolment with the matching database 1 10. In such examples, subsequent to establishment of the matching database 1 10 together with the plurality of user terminals 120, further user terminals 1 10 and data records may be enrolled. In some examples, the system 100 can be configured to permit different levels of enrolment. Each enrolment level may provide a particular level of authentication veracity. An enrolment level of a particular user terminal may be stored together with a corresponding data record and, where desired/required, the matching database may be configured to communicate the enrolment level of a particular user terminal at the time of an authentication response.

For example, the enrolment level may be communicated to the user terminal 120, or to a third party directly. In some examples, the user terminal may store and communicate the enrolment level (e.g. to a third party).

The enrolment levels may include a low level enrolment. For such an enrolment, the end user of a terminal may validate/certify the data record stored at the matching database. This may be achieved by the user purchasing the user terminal and then performing an initialisation process (e.g. via the network 130). It will be appreciated that in such an arrangement, the veracity of the user's actual may be low.

Otherwise, the system 100 may operate a high level enrolment. For such an enrolment, a trusted administrator (e.g. government official) may validate/certify the data record stored at the matching database 1 10. In further examples, the enrolment levels may include a medium level enrolment. For such an enrolment, a trusted intermediator (e.g. a bank) may validate/certify the data record stored at the matching database. Each authentication record stored at the matching database that relate to a particular user may comprise data associated a particular enrolment level of that terminal/user. In such a way, different levels of user authorisation may be required in different circumstances. It will readily be appreciated by the skilled reader that the authentication system 100 (e.g. the user terminals 120 and matching database 1 10) may define an access protocol for use across many platforms. In other words, authentication system 1 10 may be used/accessible by third parties in order to authenticate users in a manner that has not been performed previously. While in some of the above examples, a point-of-sale device was used, this is example only, and the same system and methods can be used to access e-mails, buildings, confirm transactions, etc. In other words, a user need only retain a single user terminal, which can securely provide access and authenticate that user at each event. Third parties can use and trust the authentication system accordingly, without the need to rely on passwords, etc. Further, the system 100 can be used to provide gated access to secure networks, servers, etc. In such examples, the system 100 can be considered to properly identify and authenticate a user, prior to permitting access.

In the example, described, each component of the system 100 may share common hardware, firmware and/or software. Further, the system 100 can be manufactured, and implemented by a single entity, thus again improving security. While in the above examples, only a single authentication step has been described, e.g. obtaining a biometric data once, it will readily be appreciated that in other example, multiple authentication steps may be performed in other to suitably authenticate a user. For example, a user may be requested to swipe additional fingers. A skilled reader will readily be able to implement the various embodiments accordingly.

The applicant discloses in isolation each individual feature described herein and any combination of two or more such features, to the extent that such features or combinations are capable of being carried out based on the specification as a whole in the light of the common general knowledge of a person skilled in the art, irrespective of whether such features or combinations of features solve any problems disclosed herein, and without limitation to the scope of the claims. The applicant indicates that aspects of the invention may consist of any such individual feature or combination of features. In view of the foregoing description it will be evident to a person skilled in the art that various modifications may be made within the scope of the invention.

Claims

CLAIMS:

1 . An authentication system comprising:

wherein each terminal is operable to communicate authentication data from the user terminal to the matching database, and wherein the matching database comprises an authentication unit configured to compare the authentication data that is received from that user terminal together with a data record associated with that user, and further wherein;

the system is configured to provide a positive authentication response in the event of a match between the data at the appropriate data record for that user terminal and the received authentication data from that data terminal, and, in the event of a positive authentication, a user of the user terminal is provided access to the secure network via the matching database.

2. The system according to claim 1 , wherein the matching database is configured as a gateway such that access to the secure network is possible only in the event of a positive authentication response from the matching database.

3. The system according to claim 1 or 2, wherein access to the secure network is only possible in the event of a positive authentication for both users and administrators of the secure network, or servers on that network.

4. The system according to any of the claims 1 to 3 in which the matching database is configured to store access data corresponding to permitted access to the secure network, and wherein the access data comprises the identity of a user having been provided secure access.

5. The system according to claim 4, wherein the matching database is further configured to store time and date of access.

6. The system according to any of the claims 1 to 5, wherein the secure network comprises a plurality of servers, some or all of the servers being located at different geographical locations, and wherein each of the servers communicate with the matching database via trusted connections.

7. The system according to any of the claims 1 to 6, wherein the secure network comprises at least financial servers, storing financial data.

8. The system according to any of the claims 1 to 7, wherein the system is additionally configured to communicate an authentication response to a third party, not part of the secure network.

9. The system according to any of the preceding claims, wherein the plurality of user terminals are configured for use by a plurality of users, with each terminal being identifiable and configured for exclusive use with a different user.

10. The system according to any preceding claim, wherein each user terminal comprises a particular unique identifier for that user terminal, and wherein each data record at the database comprises data relating to an associated unique identifier.

1 1 . The system according to any preceding claim, wherein the user terminal comprises a biometric sensor configured to obtain a representation of one or more biometric properties of a user.

12. The system according to claim 1 1 , wherein the biometric sensor is configured to obtain a representation of one or more fingerprints of a user.

13. The system according to claim 1 1 or 12, wherein the terminals comprise a convertor configured to convert the representation from the biometric sensor into unique biometric data, that biometric data being a unique abstraction of a biometric representation.

14. The system according to claim 13, wherein the convertor is configured to implement a conversion algorithm in order to provide biometric data, that conversion algorithm being unique to that particular terminal.

15. The system according to claim 13 or 14, wherein the terminals are configured to communicate authentication data comprising biometric data of a user of that particular terminal together with a particular unique identifier of the terminal.

16. The system according to claim 15, wherein the terminals comprise a compiler configured to compile authentication data for transmission to the matching database, and wherein the compiler is configured to apply a time stamp to the authentication data, prior to transmission.

17. The system according to any of the claims 1 to 16, wherein the terminals are configured to obtain authentication data for subsequent communication to the matching database at or around the time of an authentication request.

18. The system according to claim 17, wherein the terminals are configured to require user activation in order to provide a response to an authorisation request.

19. The system according to claim 18, wherein the user activation comprises a user swipe at the terminal.

20. The system according to any of the preceding claims, wherein each terminal comprises an auxiliary sensor configured to identify a proof of life of the user.

21 . The system according to any of the claims 1 to 20, wherein the system is configured to permit different levels of enrolment, and wherein the enrolment level of a particular user terminal is stored together with a corresponding data record.

22. A method for authenticating a user, the method comprising:

responsive to an authentication request, communicating authentication data from a user terminal to a matching database, the user terminal being associated with a single user and the matching database storing a plurality of authentication records, each record comprising authentication data relating to particular users, receiving the authentication data from the user terminal at the matching database and comparing the authentication data that is received from that user terminal together with a data record associated with that user, and

providing a positive authentication response in the event of a match between the data at the appropriate data record for that user terminal and the received authentication data from that data terminal, so as to provide user access, via the matching database, to a secure network comprising one or more server.