Patent Description:
Document <CIT> discloses a system and method for providing secure authorization to a device that includes the steps of combining two or more security factors for authentication operating at about the same time where at least one of the factors is a "tolerant" factor. By combining two factors analyzed at about the same time, the tolerance match required by the tolerant factor(s) can be reduced without reducing the overall security accuracy.

Document <CIT> relates to technologies for multi-factor authentication of a user which include a computing device with one or more sensors. The computing device may authenticate the user by analyzing biometric and/or environmental sensor data to determine whether to allow the user access to a computing device. To do so, the computing device may determine reliability scores based on the environment during authentication for each biometric authentication factor used to authenticate the user. Additionally, the computing device may determine a login pattern based on sensor data collected during historical authentication attempts by the user over a period of time. The computing device may apply a machine-learning classification algorithm to determine classification rules, based on the login pattern, applied by the computing device to determine whether to allow the user access to the computing device.

Artificial intelligence, and in particular, machine learning is being increasingly used for authentication of users to provide them with access to resources. One particular type of widely adopted machine learning-based authentication is facial recognition such as that provided on certain smartphones. Facial recognition, as an authentication solution, has some drawbacks in nature. For example, the face image of a person is not stable, there are always differences in different lighting condition and such that person's look changes slightly every day. Hence, a face recognition algorithm forming part of an authentication solution must, in practice, having variable false accept rates and false reject rates. An improper setup of a face recognition configuration can inadvertently increase the false accept rate, and lead to inaccurate user authentications.

Moreover, machine learning-based authentication techniques, when not properly trained, are more susceptible to various attack paths. For example, there may be implementation vulnerabilities in the application utilizing the machine learning-based authentication techniques. A person's identity might be able to be spoofed via images, videos, <NUM>-D printer representations, virtual reality, augmented reality and the like. The impact of such attacks on face recognition authentication solutions can be severe in that they might allow illegitimate access to the phones, building premises or any other application where it is being used. Illegitimate access to phones can allow theft of banking credentials and intimate photos and data on the phone while illegitimate access to building premises would allow poisoning of employees or illegitimate access to source code. In the meantime, an improperly trained machine learning-based authentication solution can have a high error rate which would block resource access to legitimate users, causing inconveniences and chaos in real life.

In a first aspect, authentication data for providing access to a resource to a user is received from a requester. The authentication data encapsulates data required by both a first authentication solution and a second authentication procedure both for providing access to a resource. The first and second authentication solutions can differ in authentication modality with the second authentication solution utilizing at least one machine learning model. Thereafter, using the received authentication data, both of the first and second authentication solutions are initiated. Authentication results are received from both of the first and second authentication solutions. The requester is provided with access to the resource if the both of the received authentication results indicate that authentication of the user was successful.

The requester can be prevented from accessing the resource if at least one of the authentication results indicate that the authentication of the user was not successful. In addition, with such variations, an indication can be provided (e.g., displayed, transmitted, stored, etc.) to the requester that the authentication of the user was not successful.

The requester can be prevented from accessing the resource if the first authentication solution indicates that the authentication of the user was not successful while the second authentication solution indicates that the authentication of the user was successful. In addition, with such variations, an indication can be provided (e.g., displayed, transmitted, stored, etc.) to the requester that the authentication of the user was not successful.

A reliability ratio can be checked for the user if the first authentication solution indicates that the authentication of the user was successful and the second authentication solution indicates that the authentication of the user was not successful, the reliability ratio characterizing a level of training of the machine learning model utilized by the second authentication solution. The requester can be provided with access to the resource if the reliability ratio is above a pre-defined threshold. Alternatively, the requester can be prevented from accessing the resource if the reliability ratio is below a pre-defined threshold.

The second authentication solution can utilize biometric data derived from the user. The biometric data can include, for example, one or more of: facial image, sound recording, voice recording, fingerprint, or a handprint.

The resource can take varying forms such as digital / computing resources including computer systems, software applications, or a computer data file. Alternatively, the resource can be a physical asset such as gate, lock, or other physical world item or obstacle.

Non-transitory computer program products (i.e., physically embodied computer program products) are also described that store instructions, which when executed by one or more data processors of one or more computing systems, cause at least one data processor to perform operations herein. Such computing systems can be connected and can exchange data and/or commands or other instructions or the like via one or more connections, including but not limited to a connection over a network (e.g., the Internet, a wireless wide area network, a local area network, a wide area network, a wired network, or the like), via a direct connection between one or more of the multiple computing systems, etc..

The subject matter described herein provides many technical advantages. For example, the current subject matter can be used to selectively onboard a machine learning-based authentication technique while the corresponding models are being trained. Such an arrangement is advantageous in that machine learning requires a lot of high quality training data to train models and the quality of data has direct impact on the accuracy of such models. In particular, for supervised learning, a tagged training data set covering different kinds of possible data is important to train a stable and reliable model.

<FIG> is a logical architecture diagram <NUM> in which a requester <NUM> (i.e., a computing node accessed by a user) is coupled to a progressive security adapter <NUM> (PASA) by way of an enforcement point <NUM>. The PASA <NUM> can selectively access first and second authentication solutions <NUM>, <NUM> which use different authentication modalities. For example, the first authentication solution <NUM> can be a password / passcode authentication solution which confirms the accuracy of the entered data based on data stored within a database <NUM> (accessible by such first authentication solution <NUM>). The second authentication solution <NUM> can be an authentication solution that utilizes machine learning. In some cases the second authentication solution <NUM> is self-contained (i.e., it is fully trained, etc.) while, in other cases, the second authentication solution <NUM> can access, update, or otherwise leverage training data stored in a training data database <NUM>. Example modalities include face recognition, voice recognition, biometric recognition (e.g., fingerprint, handprint, user movement as detected by a touchpad, keypad, camera, etc.). As will be described below, the PASA <NUM> based on feedback from one or more of the authentication solutions <NUM>, <NUM> can provide access to a resource <NUM>. The resource <NUM> can be, for example, data (e.g., text, audio, video, etc.), a computer system, or it can be a trigger to allow access to a physical asset. For example, the resource <NUM> can be an instruction to open a secured door or gate.

Referring again to <FIG>, the enforcement point <NUM> can represent one or more systems in charge of forwarding requests originating from the requested <NUM> to the authentication solution. In particular, the enforcement point <NUM> can intercept authentication requests from the requester <NUM> and then relay them (either wholly or after being parsed or otherwise modified) to the PASA <NUM>. The requester <NUM> can send authentication requests to the enforcement point <NUM>. These authentication requests can be encapsulate various types of data such as a username / password combination and/or data representing a biometric attribute (e.g., a vector characterizing a facial image obtained from a camera on a phone, doorbell, kiosk, etc.).

With the current computing framework incorporating the PASA <NUM>, the PASA <NUM> can coordinate between the first authentication solution <NUM> (which can, in some implementations, be characterized as a traditional authentication solution) and the second authentication solution <NUM> which uses machine learning. It will be appreciated that the first authentication solution <NUM> can also use machine learning. In such cases, the first authentication solution <NUM> can have a greater level of training as compared to the second authentication solution <NUM> making it potentially more reliable at such given moment. Moreover, in some cases, the output of the first authentication solution <NUM> can be used to train the second authentication solution <NUM> as described below with regard to normal and easy modes.

Further, the PASA <NUM> can selectively activate the second authentication solution <NUM> only when such solution has been properly trained or otherwise provides accuracy above a pre-defined or desired threshold or when other conditions are met. For example, the PASA <NUM> can take into account a sensitivity of the resource <NUM> being protected, a historical reliability of the second authentication solution <NUM> (both in average and for the specific requester), and a reliability threshold of the second authentication solution <NUM>. It will be appreciated that the PASA <NUM> can also be used to switch among more than two authentication solutions depending on the desired configuration. For example, more than two authentication solutions might be required when accessing a resource <NUM> for the first time and/or based on a role of the requesting user <NUM>.

The second authentication solution <NUM> (and in some variations, the first authentication solution <NUM>) can use various types of machine learning models. Example machine learning models include, without limitation, logistic regression, support vector machines, neural networks (e.g., concurrent neural networks, recurrent neural networks, deep learning, etc.), random forests, and the like. These models can be trained, in some cases, using user authentication data unique to a particular user while, in other cases, it can be trained using authentication data obtained from a group of users while, in still other cases, such models can be trained using a combination of user unique authentication data and authentication data from a group of users.

In some variations, the PASA <NUM> can selectively switch between the first and second authentication solutions <NUM>, <NUM> when various modes are met. These modes, for illustrative purposes herein, can include a strict mode, a normal mode, and an easy mode. The mode can be triggered, for example, when the request is received by the PASA <NUM>. For example, the request might be for a resource <NUM> requiring a higher level of authentication and/or the request might be from a user that requires a higher level of authentication level or the converse.

The strict mode can be used for highly sensitive resources <NUM> in which the output of both the first authentication solution <NUM> and the second authentication solution <NUM> in determining whether to provide access to the resource <NUM>.

The normal mode can be used for medium sensitive resources <NUM> such that the output of first authentication solution <NUM> is weighted greater than the output of the second authentication solution <NUM> while the second authentication solution <NUM> is being trained. If a conflict occurs between the output of the first authentication solution <NUM> and the second authentication solution <NUM>, in some variations, a warning (i.e., message, e-mail, etc.) can be given (e.g., displayed to a security guard, e-mailed to a system administrator, etc.) to confirm the identity of the requester <NUM>. In some cases, the conflicting outputs of the first authentication solution <NUM> and the second authentication solution <NUM> can form part of the training data <NUM> (which in turn is used to train the model(s) used as part of the second authentication solution <NUM>).

In the easy mode, the second authentication solution <NUM> takes priority after it is sufficiently trained. The first authentication solution <NUM> can, in such cases, be used to provide labeled training data (to enable supervised / semi-supervised learning) which forms part of the training data <NUM>. In addition or in the alternate, in the easy mode, the first authentication solution <NUM> can be used to provide double verification for individuals whose recognition reliability (via the second authentication solution <NUM>) does not meet minimal reliability threshold after enough training.

<FIG> is a signaling diagram <NUM> illustrating various data exchange amongst the components of <FIG> while in the strict mode. Initially, at <NUM>, the requester <NUM> sends an authentication request with traditional authentication data (e.g., security card token) together with machine learning-based data (e.g., facial image, etc.) to the enforcement point <NUM>. The enforcement point <NUM>, at <NUM>, aggregates such data (if they derive from different sources) and then forwards the requests to the PASA <NUM>. The PASA <NUM> later, at <NUM>, requests authentication (using the machine learning-based data) from the second authentication solution <NUM> which, at <NUM>, returns a result therefrom to the PASA <NUM>. In addition, the PASA <NUM>, at <NUM>, requests authentication (using the traditional authentication data) from the first authentication solution <NUM> which, at <NUM>, returns a result therefrom to the PASA <NUM>. Based on both results, the PASA <NUM> then either (i) requests, at <NUM>, the resource <NUM> and returns, at <NUM>, the resource <NUM> to the requester <NUM> if both results indicate authentication or, alternatively, (ii) returns an error or other message, at <NUM>, to the requester <NUM> indicating that the authentication failed.

<FIG> is a signaling diagram <NUM> illustrating various data exchange amongst the components of <FIG> while in the normal mode. Initially, at <NUM>, the requester <NUM> sends an authentication request with traditional authentication data (e.g., security card token) together with machine learning-based data (e.g., facial image, etc.) to the enforcement point <NUM>. The enforcement point <NUM>, at <NUM>, aggregates such data (if they derive from different sources) and then forwards the requests to the PASA <NUM>. The PASA <NUM> later, at <NUM>, requests authentication (using the machine learning-based data) from the second authentication solution <NUM> which, at <NUM>, returns a result therefrom to the PASA <NUM>. In addition, the PASA <NUM>, at <NUM>, requests authentication (using the traditional authentication data) from the first authentication solution <NUM> which, at <NUM>, returns a result therefrom to the PASA <NUM>. Based on both results, the PASA <NUM> then (i) requests, at <NUM>, the resource <NUM> and returns, at <NUM>, the resource <NUM> to the requester <NUM> if both returned results indicate authentication, (ii) returns, if both authentication solutions <NUM>, <NUM> indicate failure, an error or other message, at <NUM>, to the requester <NUM> indicating that the authentication failed, or (iii) returns, if only the first authentication solution <NUM> indicated failure, an error or other message, at <NUM>, to the requester <NUM> indicating that the authentication failed. If only the second authentication solution <NUM> indicates that authentication failed, then, at <NUM>, a reliability ratio for the requester <NUM> is checked. The reliability ratio can be calculated by the percentage of count of consistent authentication results between the two authentication solutions dividing the count of total authentication requests. If the reliability ratio is below a pre-defined threshold then, at <NUM>, an error or other message is sent to the requester <NUM> indicating that the authentication failed. If the reliability ratio is above a pre-defined threshold, then, at <NUM>, the resource <NUM> is provided to the requester <NUM>. Other messages / indications can be provided in such a situation such as a notification to a security guard requesting him or her to confirm the physical identification of a person attempting to gain access to the resource <NUM>.

<FIG> is a signaling diagram <NUM> illustrating various data exchange amongst the components of <FIG> while in the easy mode. Initially, at <NUM>, the requester <NUM> sends an authentication request with machine learning-based data (e.g., facial image, etc.) to the enforcement point <NUM>. The enforcement point <NUM>, at <NUM>, forwards the request to the PASA <NUM>. The PASA <NUM> later, at <NUM>, requests authentication (using the machine learning-based data) from the second authentication solution <NUM> which, at <NUM>, returns a result therefrom to the PASA <NUM>. If the authentication by the second authentication solution <NUM> is successful, at <NUM>, the PASA <NUM> requests the resource <NUM> and, at <NUM>, the resource <NUM> is provided to the requester <NUM>.

If the authentication by the second authentication solution <NUM> is not successful, the PASA, at <NUM>, requests the enforcement point <NUM> to request, at <NUM>, the requester <NUM> to obtain authentication data suitable for the first authentication solution <NUM> (e.g., traditional authentication data, etc.). The requester <NUM> ultimately obtains such authentication data and, at <NUM>, forwards it to the enforcement point <NUM> for relay, at <NUM>, to the PASA <NUM>. The PASA <NUM> then, at <NUM>, sends the most recently received authentication data to the first authentication solution <NUM> which, in turn, at <NUM>, checks whether the authentication data is sufficient to authenticate the requester <NUM> using the techniques of the first authentication solution <NUM>. If such authentication is successful, the PASA <NUM>, at <NUM> sends a request for the resource <NUM> to be sent, at <NUM>, directly to the requester <NUM>. If such authentication is not successful, then, at <NUM>, a message or other indication can be sent back to the requester <NUM> indicating same. The reliability ration of the user can then be updated (please explain this further).

<FIG> is a process flow diagram <NUM> illustrating an arrangement in which, at <NUM>, authentication data is received from a requester. The authentication data is for providing access to a resource to a user and it can encapsulate data required by both a first authentication solution and a second authentication procedure both for providing access to a resource. The first authentication solution and the second authentication solution use or are otherwise based on different authentication modalities with the second authentication solution utilizing at least one machine learning model. The first authentication solution and the second authentication solution are then initiated, at <NUM>, using the received authentication data. Authentication results are later received, at <NUM>, from both of the first authentication solution and the second authentication solution. The requester is, at <NUM>, provided access to the resource if the both of the received authentication results indicate that authentication of the user was successful.

<FIG> is a diagram <NUM> illustrating a sample computing device architecture for implementing various aspects described herein. A bus <NUM> can serve as the information highway interconnecting the other illustrated components of the hardware. A processing system <NUM> labeled CPU (central processing unit) (e.g., one or more computer processors / data processors at a given computer or at multiple computers), can perform calculations and logic operations required to execute a program. A non-transitory processor-readable storage medium, such as read only memory (ROM) <NUM> and random access memory (RAM) <NUM>, can be in communication with the processing system <NUM> and can include one or more programming instructions for the operations specified here. Optionally, program instructions can be stored on a non-transitory computer-readable storage medium such as a magnetic disk, optical disk, recordable memory device, flash memory, or other physical storage medium.

In one example, a disk controller <NUM> can interface one or more optional disk drives to the system bus <NUM>. These disk drives can be external or internal floppy disk drives such as <NUM>, external or internal CD-ROM, CD-R, CD-RW or DVD, or solid state drives such as <NUM>, or external or internal hard drives <NUM>. As indicated previously, these various disk drives <NUM>, <NUM>, <NUM> and disk controllers are optional devices. The system bus <NUM> can also include at least one communication port <NUM> to allow for communication with external devices either physically connected to the computing system or available externally through a wired or wireless network. In some cases, the communication port <NUM> includes or otherwise comprises a network interface.

To provide for interaction with a user, the subject matter described herein can be implemented on a computing device having a display device <NUM> (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information obtained from the bus <NUM> to the user and an input device <NUM> such as keyboard and/or a pointing device (e.g., a mouse or a trackball) and/or a touchscreen by which the user can provide input to the computer. Other kinds of input devices <NUM> can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback by way of a microphone <NUM>, or tactile feedback); and input from the user can be received in any form, including acoustic, speech, or tactile input. The input device <NUM> and the microphone <NUM> can be coupled to and convey information via the bus <NUM> by way of an input device interface <NUM>. Other computing devices, such as dedicated servers, can omit one or more of the display <NUM> and display interface <NUM>, the input device <NUM>, the microphone <NUM>, and input device interface <NUM>.

To provide for interaction with a user, the subject matter described herein may be implemented on a computer having a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user and a keyboard and a pointing device (e.g., a mouse or a trackball) and/or a touch screen by which the user may provide input to the computer. Other kinds of devices may be used to provide for interaction with a user as well; for example, feedback provided to the user may be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form, including acoustic, speech, or tactile input.

In the descriptions above and in the claims, phrases such as "at least one of' or "one or more of' may occur followed by a conjunctive list of elements or features.

Claim 1:
A computer-implemented method comprising:
receiving, from a requester (<NUM>), authentication data for providing access to a resource (<NUM>) to a user, the authentication data encapsulating data required by both a first authentication solution (<NUM>) and a second authentication solution (<NUM>) both for providing access to a resource (<NUM>), the first authentication solution (<NUM>) and the second authentication solution (<NUM>) differing in authentication modality with the second authentication solution (<NUM>) utilizing at least one machine learning model;
initiating, using the received authentication data, both of the first authentication solution (<NUM>) and the second authentication solution (<NUM>);
receiving authentication results from both of the first authentication solution (<NUM>) and the second authentication solution (<NUM>);
providing the requester (<NUM>) with access to the resource (<NUM>) if the both of the received authentication results indicate that authentication of the user was successful; and
using output of the first authentication solution (<NUM>) to train the second authentication solution (<NUM>);
preventing the requester (<NUM>) from accessing the resource (<NUM>) if at least one of the authentication results indicate that the authentication of the user was not successful: and
providing an indication to the requester (<NUM>) that the authentication of the user was not successful.