Patent Description:
With security becoming core to enterprise mobile use cases as well as providing a seamless user experience, there is a need to allow enterprise information technology (IT) administrators to continuously authenticate device users using multiple biometrics authentication factors and user behavior data captured on the device. Some authentication solutions, however, only offer initial moment authentication with methods such as password, pin, pattern or fingerprint, and there is a requirement for continuous authentication using multiple factors.

<CIT> discloses detecting, capturing and processing valid login credentials. Successful logins are distinguished from unsuccessful logins, and only when a login is successful are the user's login credentials stored and associated with the appropriate login page. Attempts by a user to login to a login page with a set of login credentials are identified. It is determined whether an attempt to login to a given login page with a set of login credentials is successful. If the attempt by the user to login to the login page with the set of login credentials is successful, the set of login credentials can be stored and associated with the login page. If the attempt fails, the credentials are not saved.

<CIT> discloses an identity management system that provides single sign-on (SSO) services to clients, logging the clients into a variety of third-party services for which the clients have accounts. An SSO integration is stored for each of the third-party services, the SSO integration including information that allows the identity management system to automate the login for the corresponding third-party service, such as locations of the login pages, and/or identities of username and password fields. The identity management system uses different techniques in different embodiments to detect that a given SSO integration is broken (i.e., no longer permits login for its corresponding third-party service) and/or to repair the SSO integration.

<CIT>discloses a technique that allows a client computing system with a browser to automatically transmit user credentials to a web account on a web site. The transmitted information may be entered into form fields in a standard browser or a headless browser. The client computing system may also determine whether automatic login of user credentials has succeeded in logging the user to the web account by determining, in some embodiment, "logout" buttons, or other information in web pages that may be received from the web site.

Most authentication solutions are cloud-based and do not have device level access, which provides insights to take proactive action.

One or more embodiments relate to user authentication. In some embodiments, a method for user authentication by an electronic device is provided. The method includes storing a user interface (UI) hierarchy of one or more screens associated with an application, identifying a first screen presented by the electronic device as an authentication screen of the application based on at least one of the stored UI hierarchy, and UI elements of the one or more screens, and determining an authentication result based on a deviation of the first screen or presentation of a second screen by the electronic device.

In some embodiments, a non-transitory processor-readable medium that includes a program that, when executed by a processor of an electronic device, causes the electronic device to perform operations for user authentication. The operation includes storing a user interface (UI) hierarchy of one or more screens associated with an application, identifying a first screen presented by the electronic device as an authentication screen of the application based on at least one of the stored UI hierarchy, and UI elements of the one or more screens, and determining an authentication result based on a deviation of the first screen or presentation of a second screen by the electronic device.

In some embodiments, an electronic device for user authentication is provided. The electronic device includes a memory, and at least one processor coupled to the memory, wherein the at least one processor is configured to, store a user interface (UI) hierarchy of one or more screens associated with an application, identify a first screen presented by the electronic device as an authentication screen of the application based on at least one of the stored UI hierarchy, and UI elements of the one or more screens, and determine an authentication result based on a deviation of the first screen or presentation of a second screen by the electronic device.

These and other features, aspects and advantages of the one or more embodiments will become understood with reference to the following description, appended claims and accompanying figures.

The following description is made for the purpose of illustrating the general principles of one or more embodiments and is not meant to limit the inventive concepts claimed herein. Further, particular features described herein can be used in combination with other described features in each of the various possible combinations and permutations. Unless otherwise specifically defined herein, all terms are to be given their broadest possible interpretation including meanings implied from the specification as well as meanings understood by those skilled in the art and/or as defined in dictionaries, treatises, etc..

Some embodiments provide user authentication. In one or more embodiments, a method includes storing a user interface (UI) hierarchy of one or more screens associated with an application. The one or more screens are presented by an electronic device. A first screen presented by the electronic device is identified as an authentication screen of the application based on the stored UI hierarchy, UI elements of the one or more screens, or a combination thereof. An authentication result is determined based on a deviation of the first screen or presentation of a second screen by the electronic device.

Some embodiments determine the successful and failed authentication attempts for different user applications as a new factor in a multi-factor determination of an authorized user. User applications include, but not limited to finance related applications (banking, stock trading,. ), social media applications, or any other application that uses a username and password. By knowing whether the user has successfully logged into these different user applications (allowing for tolerable failure rates) a user authentication pattern could be developed, which may be used to provide a score for the new authentication factor.

Determining successful and failed authentication attempts for user applications is trivial for biometrics based authentication such as fingerprint, facial recognition, etc. since these are electronic device (e.g., laptops, smart phones, smart watches, smart pads, etc.) level features, which require hardware backing and hence provide a clear yes/no result for user authentication for all user applications on the electronic device. What is not trivial is to determine the authentication result for a password based authentication such as a username and password, since there is no common layer at which the authentication result is obtained (unlike the biometrics there is no single hardware module on a device that provides a yes/no result). Therefore, the username and password are generated and consumed completely within the application. Additionally, the authentication can be implemented using different security protocols by different applications, and hence looking for authentication results from the server by sniffing the network traffic might not always work.

<FIG> shows a block diagram of a high level authentication flow <NUM> for each application authentication user experience (UX), according to some embodiments. One or more embodiments use the user interface (UI) elements and UX flow of an application's authentication process to determine whether the authentication has succeeded or failed. Though the username and password UI elements in which the user enters the data in different applications are designed using different UI elements and follow different UX flows, a common criteria may be used that underlies most username and password based authentications. When a user is using an application, zero or multiple screens may be shown to the user before the user is asked to authenticate. For the purpose of clarification, a screen is defined as any UI screen displayed to the user and has multiple UI elements in it including but not limited to layouts, textbox, edit textbox, password box, buttons, radio buttons, etc..

In some embodiments, whenever an application attempts to authenticate a user using a username/password based approach, the UI screen <NUM> will have the username and password fields and a submit/login button on the same screen <NUM>, a username field pre-filled and password field and a submit/login button on the screen <NUM>, or username and password fields on different screens with a submit/login button on the password screen. Once the authentication is successful, the UI screen <NUM> with these fields is removed and a brand new screen is displayed, and more screens are displayed later. If the authentication failed, then either the authentication screen remains or a failed screen is displayed or any of the previous screens are displayed.

In one or more embodiments, most of the UI elements in a screen <NUM> are displayed as a hierarchy, with multiple or one UI element nested in others, based on the function of that UI element. Zero or multiple screens may be shown to a user before the user is asked to authenticate. Most of the UI elements that become the leaf usually have some value associated with them. One screen is different from another screen if they have different hierarchies and even if they have same hierarchies, the values in the leaf UI elements are different. A password box usually has some special display properties that allow it to hide the input from the user's view.

Some embodiments use the generic concepts of UI elements and the authentication flow <NUM>, to first capture the UI hierarchy of each screen <NUM> till the authentication screen <NUM> is displayed, and then later uses a new screen <NUM>, which follows the authentication screen <NUM> to determine if the authentication was successful or failed. One or more new screens <NUM> may be shown upon successful authentication, or a failed screen may be shown upon a failed authentication. This is done for each application UX flow. Since there is mostly one app (or application) in the foreground in mobile devices it implies detecting the UX flow for the foreground application. This process may be used for different applications on the electronic device, according to some embodiments. By knowing whether the user has successfully logged into different user applications, a user authentication pattern is developed that is used as a new authentication factor.

<FIG> shows a block diagram of a UX flow <NUM> for UX authentication and screen change detection, according to some embodiments. One or more embodiments provide a process to efficiently store the UI hierarchy for each screen in block <NUM>. The UI hierarchy is usually provided by many mobile operating system (OS) platforms and the UI hierarchy may be easily obtained. In block <NUM>, once the UI hierarchy for a screen is obtained, a unique identification (ID) is assigned for each UI element (in many cases such unique IDs are already provided by the relevant mobile OS, which may be used), and then a unique ID is assigned for each screen based on some standard hashing algorithms of all children UI elements. Each screen is stored with its hashcode along with an ordered list of its child elements. Each child element in turn is stored with its hashcode along with an ordered list of its child elements (similar to a tree structure). At the top level, all screens are displayed until the authentication screen is showed and are stored in an ordered list.

In some embodiments, block <NUM> provides an authentication screen and an action detector process, including processing to determine that a screen is an authentication screen. Many mobile OS platforms provide ways to indicate that a UI element is a password input type of UI element. This is used to determine the password field on the screen. The submit/login button may be determined using heuristics and searching for a UI element on the password screen that has the term "Submit" or "Login" or any equivalent word value as its text (this can be changed to use the corresponding words in different languages as well).

In one or more embodiments, block <NUM> provides for the screen UI hierarchy comparator processing. After the authentication screen action detector processing in block <NUM> completes its operation, the screen UI hierarchy comparator processing on block <NUM> captures the UI hierarchy of the screen and compares it with information of each screen stored in the ordered list of screen information previously stored by the screen UI hierarchy processor and storage processing of block <NUM>. If either the authentication screen remains or any of the previous screens are displayed, in both cases these will be part of the ordered list of screen information and results in the authentication failure. If the screen is a new screen and is determined to be a failure screen by the authentication failure screen determiner processing of block <NUM>, then the authentication is considered as failed. Otherwise, the authentication is considered as successful.

In some embodiments, the authentication failure screen determiner processing of block <NUM> determines authentication failure using heuristics and searching for a UI element on the screen that appears after the authentication screen, which is not any previously stored screens, and has the term "Failed" or "Retry" or any equivalent word value as its text (this can be changed to use the corresponding words in different languages as well).

In one or more embodiments, the screen change detector processing in block <NUM> determines a change in screen. The UI frameworks of many mobile OS platforms provide ways to notify software processes of changes in the screen UI. Even if such notifications are not provided, it is trivial to add such functionality to the UI framework. In one example embodiment, this functionality may be performed by detecting changes in a frame buffer of the screen of an electronic device, or other similar functionalities.

<FIG> shows a flow diagram <NUM> for screen change detection and UX authentication processing, according to some embodiments. The processing starts either by running a process in the background or upon triggering the start based on block <NUM> detecting a screen change as described regarding block <NUM> (<FIG>), such as detecting changes in a frame buffer of the screen of an electronic device, or other similar functionalities. In block <NUM> the screen UI hierarchy is stored in memory. The UI hierarchy is usually provided by many mobile OS platforms and the UI hierarchy can be easily obtained from the UI framework of such platforms. Once the UI hierarchy for a screen is obtained, a unique ID is assigned for each UI element and then assign a unique ID for each screen based on a standard hashing algorithm of all children UI elements. Each Screen is stored with its hashcode and an ordered list of its child elements. Each child element in turn is stored with its hashcode along with an ordered list of its child elements (similar to a tree structure). At the top level all screens displayed until the authentication screen is showed are stored in an ordered list. In block <NUM> it is determined whether an authentication screen action is detected. Many mobile OS platforms provide ways to indicate that a UI element is of a password input type. This can be used to determine the password field on the screen. The submit/login button can be determined using heuristics and searching for a UI element on the password screen that has a "Submit" or "Login" or any equivalent word value as its text (this can be changed to use the corresponding words in different languages as well). The detection of the authentication screen and the pressing/selection of the submit/login button and the completion of the authentication operation are part of the functions of this processing block. If block <NUM> detects an authentication screen action, the processing proceeds to block <NUM>, otherwise processing returns to block <NUM> awaiting detection of a screen change.

In one or more embodiments, in block <NUM> the screen UI hierarchy is compared by comparator processing that captures the UI hierarchy of the screen and compares it with information of each screen stored in the ordered list of screen information previously stored in block <NUM>. In block <NUM>, if the authentication screen remains or any of the previous screens are displayed, in both cases these are part of the ordered list of screen information and results in the authentication failure in block <NUM>. If the screen is a new screen and is determined to be a failure screen by the authentication failure screen detector processing of block <NUM>, then the authentication is considered as failed in block <NUM>. Otherwise, the authentication is considered as successful in block <NUM>. In some embodiments, the authentication failure screen detection processing of block <NUM> determines authentication failure using heuristics and searching for a UI element on the screen that appears after the authentication screen, which is not any previously stored screens, and has the term "Failed" or "Retry" or any equivalent word value as its text (this can be changed to use the corresponding words in different languages as well).

<FIG> shows a block diagram of a flow <NUM> for UX authentication and screen change detection where screens are maintained in an ordered list(s), according to some embodiments. In some embodiments, flow <NUM> is similar to flow <NUM> (<FIG>) and makes use of the fact that in some mobile UI frameworks the screens are already maintained in an ordered list. Therefore, instead of storing the screen UI hierarchy on every screen change, the flow <NUM> obtains this ordered list when the authentication screen is detected in block <NUM>. In one or more embodiments, flow <NUM> makes use of the length of the password field to determine that in some cases that the authentication has failed.

<FIG> shows a flow diagram <NUM> of UX authentication and screen change detection processing where screens are maintained in an ordered list(s), according to some embodiments. In one or more embodiments, in block <NUM>, the processing starts either by running a process in the background or upon triggering the start based on block <NUM> detecting a screen change as described regarding block <NUM> (<FIG>), such as detecting changes in a frame buffer of the screen of an electronic device, or other similar functionalities. In block <NUM> it is determined whether an authentication screen action is detected. Many mobile OS platforms provide ways to indicate that a UI element is of a password input type. This can be used to determine the password field on the screen. The submit/login button can be determined using heuristics and searching for a UI element on the password screen that has a "Submit" or "Login" or any equivalent word value as its text (this can be changed to use the corresponding words in different languages as well). The detection of the authentication screen and the pressing/selection of the submit/login button and the completion of the authentication operation are part of the functions of this processing block. If block <NUM> detects an authentication screen action, the processing proceeds to block <NUM>, otherwise processing returns to block <NUM> awaiting detection of a screen change. In block <NUM> the screen UI hierarchy is stored in memory. The UI hierarchy is usually provided by many mobile OS platforms and the UI hierarchy can be easily obtained from the UI framework of such platforms. Once the UI hierarchy for a screen is obtained, a unique ID is assigned for each UI element and then assign a unique ID for each screen based on a standard hashing algorithm of all children UI elements. Each Screen is stored with its hashcode and an ordered list of its child elements. Each child element in turn is stored with its hashcode along with an ordered list of its child elements (similar to a tree structure). At the top level all screens displayed until the authentication screen is showed are stored in an ordered list.

In some embodiments, in block <NUM> the screen UI hierarchy is stored in memory. The UI hierarchy is usually provided by many mobile OS platforms and the UI hierarchy can be easily obtained from the UI framework of such platforms. Once the UI hierarchy for a screen is obtained, a unique ID is assigned for each UI element and then assign a unique ID for each screen based on a standard hashing algorithm of all children UI elements. Each Screen is stored with its hashcode and an ordered list of its child elements. Each child element in turn is stored with its hashcode along with an ordered list of its child elements (similar to a tree structure). At the top level all screens displayed until the authentication screen is showed are stored in an ordered list. The ordered list of screens and its UI hierarchy are only stored when the authentication screen is detected.

In one or more embodiments, in block <NUM> detection of an authentication action is performed. By checking if the password field value has changed in length except zero value after the pressing of the submit/login button, a determination that the authentication has failed can be made (this usually corresponds to a user trying a new password, any addition or subtraction or character will cause the result of authentication to fail). This failure detection optimization will not require UI hierarchy comparison (which saves time). After the authentication action detection processing in block <NUM> completes its operation, in block <NUM> it is determined whether the password length is changed to a non-zero value or not. If it is determined that the password length is changed to a non-zero value, processing continues to block <NUM> where the authentication is considered as failed. Otherwise, processing proceeds to block <NUM> where a screen UI hierarchy comparator captures the UI hierarchy of the screen and compares it with each screen information stored in the ordered list of screen information previously stored in block <NUM>. In block <NUM>, if the authentication screen remains or any of the previous screens are displayed, in both cases these are part of the ordered list of screen information and results in the authentication failure in block <NUM>. If the screen is a new screen and is determined to be a failure screen by the authentication failure screen detector processing of block <NUM>, then the authentication is considered as failed in block <NUM>. Otherwise, the authentication is considered as successful in block <NUM>. In some embodiments, the authentication failure screen detection processing of block <NUM> determines authentication failure using heuristics and searching for a UI element on the screen that appears after the authentication screen, which is not any previously stored screens, and has the term "Failed" or "Retry" or any equivalent word value as its text (this can be changed to use the corresponding words in different languages as well).

<FIG> shows a block diagram of a flow <NUM> for UX authentication and screen change detection where a UI hierarchy structure is derived, according to some embodiments. In some embodiments, flow <NUM> is similar to flow <NUM> (<FIG>), but instead of using the UI frameworks UI hierarchy structure, in block <NUM> a screen image processor and UI hierarchy creator provides that every screen change determined in block <NUM> is followed by a screenshot of the screen and image processing is done on the screen to derive the UI hierarchy structure. This has the following advantages. The password based authentication result may be performed both from inside the electronic device as well as by outside the electronic device, by capturing a sequence of unique images and processing them to obtain the authentication result. It works on even those mobile UI frameworks, which do not rely on a UI hierarchy based approach.

<FIG> shows a block diagram <NUM> for UX authentication and screen change detection processing where a UI hierarchy structure is derived, according to some embodiments. In block <NUM>, the processing starts either by running a process in the background or upon triggering the start based on block <NUM> detecting a screen change as described regarding block <NUM> (<FIG>), such as detecting changes in a frame buffer of the screen of an electronic device, or other similar functionalities. In block <NUM> the screen image processor and UI hierarchy creator processes the screen image and creates a UI hierarchy based on the screen image. This does not need to follow the actual hierarchy created by the mobile UI framework, just a repeatable hierarchy based on the given screen image. The UI hierarchy created in this way has the UI element and its value as part of the hierarchy. In block <NUM> the screen UI hierarchy is stored in memory. The UI hierarchy is usually provided by many mobile OS platforms and the UI hierarchy can be easily obtained from the UI framework of such platforms. Once the UI hierarchy for a screen is obtained, a unique ID is assigned for each UI element and then assign a unique ID for each screen based on a standard hashing algorithm of all children UI elements. Each Screen is stored with its hashcode and an ordered list of its child elements. Each child element in turn is stored with its hashcode along with an ordered list of its child elements (similar to a tree structure). At the top level all screens displayed until the authentication screen is showed are stored in an ordered list. In block <NUM> it is determined whether an authentication screen action is detected. Many mobile OS platforms provide ways to indicate that a UI element is of a password input type. This can be used to determine the password field on the screen. The submit/login button can be determined using heuristics and searching for a UI element on the password screen that has a "Submit" or "Login" or any equivalent word value as its text (this can be changed to use the corresponding words in different languages as well). The detection of the authentication screen and the pressing/selection of the submit/login button and the completion of the authentication operation are part of the functions of this processing block. If block <NUM> detects an authentication screen action, the processing proceeds to block <NUM>, otherwise processing returns to block <NUM> awaiting detection of a screen change.

In one or more embodiments, in block <NUM> a screen UI hierarchy comparator captures the UI hierarchy of the screen and compares it with each screen information stored in the ordered list of screen information previously stored in block <NUM>. In block <NUM>, if the authentication screen remains or any of the previous screens are displayed, in both cases these are part of the ordered list of screen information and results in the authentication failure in block <NUM>. If the screen is a new screen and is determined to be a failure screen by the authentication failure screen detector processing of block <NUM>, then the authentication is considered as failed in block <NUM>. Otherwise, the authentication is considered as successful in block <NUM>. In some embodiments, the authentication failure screen detection processing of block <NUM> determines authentication failure using heuristics and searching for a UI element on the screen that appears after the authentication screen, which is not any previously stored screens, and has the term "Failed" or "Retry" or any equivalent word value as its text (this can be changed to use the corresponding words in different languages as well).

<FIG> shows a process <NUM> for identifying a first screen presented by an electronic device as an authentication screen of an application based on a stored UI hierarchy, UI elements of one or more screens, or a combination thereof, according to some embodiments. In block <NUM>, process <NUM> provides for storing a UI hierarchy of one or more screens associated with an application. The one or more screens are presented by an electronic device (e.g., a smart phone, computing pad device, computing device, etc.). In block <NUM>, process <NUM> provides for identifying a first screen presented by the electronic device as an authentication screen of the application based on one of the stored UI hierarchy, UI elements on the one or more screens, or a combination thereof. In block <NUM>, process <NUM> provides for determining an authentication result based on a deviation of the first screen or presentation of a second screen by the electronic device.

In some embodiments, process <NUM> provides that the deviation of the first screen includes a length change to an input field of the first screen. In one or more embodiments, process <NUM> provides that the second screen is presented by the electronic device upon inputs to the first screen.

In one or more embodiments, process <NUM> provides that the storing of the UI hierarchy of the one or more screens associated with the application further includes assigning a respective screen identification (ID) to each screen of the one or more screens. Additionally, for each screen of the one or more screens, process <NUM> assigns a respective UI element ID to each individual UI element of each screen, and for storing the UI hierarchy as an ordered list. In some embodiments, the ordered list includes one or more screen IDs, with each screen ID being associated with its UI element IDs.

In some embodiments, in process <NUM> the identifying of the first screen presented by the electronic device as the authentication screen of the application based on the stored UI hierarchy, the UI elements on the one or more screens, or a combination thereof, further includes determining one or more UI elements of the first screen that includes at least one of: a first UI element for inputting a password, or a second UI element for submitting the input password.

In one or more embodiments, process <NUM> additionally provides for determining the authentication result based on the second screen presented by the electronic device further includes: determining that the second screen is not one of the one or more screens based on analysis by the electronic device of the stored UI hierarchy, and for determining authentication failure upon identifying a third UI element indicating a failure operation.

In some embodiments, process <NUM> further provides for determining the authentication result based on the second screen presented by the electronic device further includes determining authentication failure upon determining that the second screen is one of the one or more screens based on analysis by the electronic device of the stored UI hierarchy.

<FIG> is a high-level block diagram showing an information processing system comprising a computer system <NUM> useful for implementing the disclosed embodiments. Computer system <NUM> may be incorporated in a display device, such as display device <NUM> (<FIG>), end device <NUM> (<FIG>), etc. The computer system <NUM> includes one or more processors <NUM>, and can further include an electronic display device <NUM> (for displaying video, graphics, text, and other data), a main memory <NUM> (e.g., random access memory (RAM)), storage device <NUM> (e.g., hard disk drive), removable storage device <NUM> (e.g., removable storage drive, removable memory module, a magnetic tape drive, optical disk drive, computer readable medium having stored therein computer software and/or data), user interface device <NUM> (e.g., keyboard, touch screen, keypad, pointing device), and a communication interface <NUM> (e.g., modem, a network interface (such as an Ethernet card), a communications port, or a PCMCIA slot and card). The communication interface <NUM> allows software and data to be transferred between the computer system and external devices. The system <NUM> further includes a communications infrastructure <NUM> (e.g., a communications bus, cross-over bar, or network) to which the aforementioned devices/modules <NUM> through <NUM> are connected.

Information transferred via communications interface <NUM> may be in the form of signals such as electronic, electromagnetic, optical, or other signals capable of being received by communications interface <NUM>, via a communication link that carries signals and may be implemented using wire or cable, fiber optics, a phone line, a cellular phone link, a radio frequency (RF) link, and/or other communication channels. Computer program instructions representing the block diagram and/or flowcharts herein may be loaded onto a computer, programmable data processing apparatus, or processing devices to cause a series of operations performed thereon to produce a computer implemented process.

In some embodiments, processing instructions for process <NUM> (<FIG>) may be stored as program instructions on the memory <NUM>, storage device <NUM> and the removable storage device <NUM> for execution by the processor <NUM>.

Some embodiments may be applied to the following implementations (but are not limited thereto):.

Embodiments have been described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products. Each block of such illustrations/diagrams, or combinations thereof, can be implemented by computer program instructions. The computer program instructions when provided to a processor produce a machine, such that the instructions, which execute via the processor create means for implementing the functions/operations specified in the flowchart and/or block diagram. Each block in the flowchart /block diagrams may represent a hardware and/or software module or logic. In alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures, concurrently, etc..

The terms "computer program medium," "computer usable medium," "computer readable medium", and "computer program product," are used to generally refer to media such as main memory, secondary memory, removable storage drive, a hard disk installed in hard disk drive, and signals. These computer program products are means for providing software to the computer system. The computer readable medium allows the computer system to read data, instructions, messages or message packets, and other computer readable information from the computer readable medium. The computer readable medium, for example, may include non-volatile memory, such as a floppy disk, ROM, flash memory, disk drive memory, a CD-ROM, and other permanent storage. It is useful, for example, for transporting information, such as data and computer instructions, between computer systems. Computer program instructions may be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.

As will be appreciated by one skilled in the art, aspects of the embodiments may be embodied as a system, method or computer program product. Accordingly, aspects of the embodiments may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit," "module" or "system. " Furthermore, aspects of the embodiments may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.

Computer program code for carrying out operations for aspects of one or more embodiments may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages.

Aspects of one or more embodiments are described above with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products. These computer program instructions may be provided to a special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

References in the claims to an element in the singular is not intended to mean "one and only" unless explicitly so stated, but rather "one or more. " All structural and functional equivalents to the elements of the above-described exemplary embodiment that are currently known or later come to be known to those of ordinary skill in the art are intended to be encompassed by the present claims.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosed technology.

The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of the embodiments has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the embodiments in the form disclosed.

Claim 1:
A method for user authentication by an electronic device (<NUM>), the method comprising:
storing a user interface, UI, hierarchy of one or more screens (<NUM>), associated with an application;
identifying a first screen (<NUM>) presented by the electronic device (<NUM>) as an authentication screen of the application based on at least one of the stored UI hierarchy, and UI elements of the one or more screens (<NUM>);
determining whether a second screen (<NUM>) following the first screen (<NUM>) is one of the previous one or more screens based on the stored UI hierarchy;
determining whether a failure screen is detected in case of determining that the second screen is not one of the previous one or more screens;
determining that the authentication result is authentication success in case of determining that a failure screen is not detected; and
determining that the authentication result is authentication failure based on determining that the second screen (<NUM>) is one of the previous one or more screens or determining that a failure screen is detected.