CROSS-REFERENCE

[0001] This application claims all benefit, including priority to US Patent Application No. 62/524846, filed 26-Jun-2017, entitled "SYSTEMS AND METHODS FOR BIOMETRIC DATA VERIFICATION", herein incorporated by reference.

FIELD

[0002] The present disclosure generally relates to the field of identity management, and more particularly, coordinating identity management across a diversity of biometric modalities and verification mechanisms and improved graphical user interfaces thereof. INTRODUCTION

[0003] Existing identity management systems are often provided in silos and lack cohesion between different providers and vendors. Accordingly, the existing approach to identity management is disjointed, leading to poor customer experiences and technical outcomes. [0004] Identity management system graphical user interfaces, in particular, are not helpful in the presentment of information for various types of users and administrators. Static data is often shown in raw formats, without consideration for the types of information that is particularly valuable. Organizations typically engage a patchwork set of vendors, leading to inconsistent information stored on a backend data storage. This is complicated through the rise of a diversity of potential device types with differing software, hardware, and security standards in the context of "bring your own device" policies.

[0005] Furthermore, users and administrators of such identity management systems may often need to quickly synthesize such information to take corrective actions, for example, in the context of addressing data breaches and remedying security incidents. The users and administrators may, for example, wish to control the identity management system to modify access privileges, increase a security level required for access, further investigate flagged ambiguous access attempts, among others. SUMMARY

[0006] An improved graphical user interface system and mechanism is described in various embodiments that are configured in the context of the challenges and opportunities faced for identity management where biometric computing mechanisms are utilized, at least in part, in managing access (virtual or physical).

[0007] Applicant has developed a backend computing infrastructure that receives data sets for the purposes of identity verification from a diversity of sources and vendors, including at least a plurality of different biometric data sources. The backend computing infrastructure is designed for enterprise level deployment in a flexible range of environments. The backend computing infrastructure is operable to capture a plurality of biometric modalities which are used in flexibly weighted combinations with one another. In some embodiments, an overall distributed architecture is provided that receives biometric information from a distributed set of sensors, the biometric information being normalized for processing. [0008] Flexible weightings allow for an ease of modifications of security level, security emphasis, and also provides an increased level of security as malicious users are likely not aware of the exact weightings and/or underlying triggers that underpin the backend computing infrastructure.

[0009] The graphical user interface system is a specially configured administrator console. The specially configured administrator console includes improved visual interface elements that are rendered on a display responsive to one or more failed, suspicious, or borderline authentications. In some embodiments, a random selection of authentications that are successful are also provided for review. A human administrator is able to then quickly review the displayed authentications, and take one or more actions responsive to the outcome of the administrator's review.

[0010] In a preferred embodiment, the system is a "driverless" system that is configured so that administrators are able to modify downstream behavior of the system only (e.g., modifying a strictness level), and is not able to actually modify current access provisioning decisions (e.g., the administrator is unable to override the system for a currently pending flagged rejection / approval). In this example, there is improved security as the administrator cannot directly influence current classifications (e.g., can't turn a rejection into an approval).

[0011] In an alternate embodiment, the system is driven by the administrators who receive and review authentication requests in real-time or near-real time and provides feedback in relation to current access provisioning decisions to allow them to proceed from a flagged, pending / inconclusive state to a rejected / allowed state.

[0012] Identity may be managed in relation to customer access provisioning (e.g., online banking), employee access provisioning (door access), and virtual access provisioning (e.g., access permissions, administrator rights), among others. Differing levels and requirements for security are necessary as there is a balance between overly cumbersome security requirements (e.g., unacceptably high false rejection rate) and the need to prevent high- impact security breaches (e.g., unacceptably high false positive rate leading to material losses).

[0013] An individual's "rightful identity", in relation to the backend computing infrastructure, is a holistic, data-centric consideration of a portion or all information tracked in relation to an individual, including characteristics specific to the individual (e.g., height, weight, gait, angle a mobile device is held at). Systems and methods are provided that relate to dynamic identity management. The systems and methods utilize a diversity of biometric modalities and other verification mechanisms to provide improved outcomes relative to existing verification technologies. The diversity of biometric modalities and other verification mechanisms are coordinated in their use such that differing layers and combinations of protection are flexibly deployed.

[0014] The backend computing infrastructure is configured to provide a consolidated identity management platform that enhances primary biometric data sets to add additional secondary verification information (biometric or non-biometric). The secondary verification information is utilized to add a contextual level of security that is utilized to modify weightings on a computational estimation of how trustworthy the information provided by the user is. [0015] Identity verification can be on an event-driven basis, or in some embodiments, ongoing (e.g., periodically or continuously tracked). In some embodiments, a combination of both event-driven verification and on-going verification is utilized to maintain both an ongoing verification metric for an individual and to update it as new information is provided at each access-requesting event trigger.

[0016] The differences in ease of use, availability, flexibility in configuration, and trust characteristics of each biometric modality and verification mechanism are synchronized to increase the overall effectiveness of a solution. Improved outcomes are not limited solely to improved accuracy or security levels, rather, improved outcomes are directed to enhancing an overall administrator or user experience across a variety of factors, such as ease of use, availability across a user base, sensitivity, specificity, etc. Risk can be dynamically managed across an organization at various levels of granularity. Access, based on identity management, can be based tiered and/or grouped such that appropriate security features can be dynamically implemented, tuned for a potential for risk, an impact of breach, availability of computing resources, and a need for ease of access. An improved graphical user interface is useful in this regard. The platform is typically utilized in the context of a large organization, and it is important to automatically emphasize information that requires actions to be taken by an administrator. The users may be geographically spread out across a diverse number of countries, locations, computing devices, and there may be variations in policies (e.g., at each facility).

[0017] Accordingly, a flexible, dynamic interface generation and maintenance system is described that responsively modifies identity management practices over time as data sets are processed, the data sets relating to feedback regarding actual use of the modalities and verification mechanisms (e.g., failed attempts, abandoned attempts), or external factors (e.g., a zero-day vulnerability found in a device, leading to compromised verification pathways), among others. Embodiments described herein are directed to graphical user interfaces specifically tuning visual interface elements for rendering on a display configured for presentment to a user or an administrator of the backend computing infrastructure.

[0018] In various embodiments, graphical visual interface elements are adaptively re- arranged and additional overlays are dynamically rendered using the underlying biometric information, including both primary biometric verification mechanisms and associated secondary verification mechanisms that aid a user or administrator in quickly administering access decisions or reviewing prior access events for suspicious activity. For example, where an access request of ambiguous confidence level is encountered and the system is unable to automatically determine whether access should be provisioned or not, improved renderings are shown so that the administrator is able to make a decision, for example, using secondary information.

[0019] In accordance with one aspect, there is provided a computer-implemented system for identity management, the system including receivers in communication with a plurality of biometric verification mechanisms and access control mechanisms operating in conjunction to provision virtual or physical access to authorized users; a policy engine configured to coordinate and control characteristics of the operation of the plurality of biometric verification mechanisms and access control mechanisms; and a front-end interface configured to communicate with the policy engine. [0020] In accordance with another aspect, the system is configured to automatically tune the biometric verification mechanisms and access control mechanisms to optimize one or more outcomes, or a balanced plurality of outcomes, the outcomes including, for example, ease of use, acceptable levels of unauthorized access, risk, impact of unauthorized access, among others. The tuning may be conducted by modifying individual characteristics of the biometric verification mechanisms and access control mechanisms (e.g., making some mechanisms more or less onerous), and/or selecting different subsets of mechanisms.

[0021] In accordance with another aspect, the system is configured to generate predictions and recommendations for optimizing the one or more outcomes, and to generate interactive interface elements that can be interacted with to effect the recommendations. In accordance with another aspect, the system is configured to modify a configuration of the policy engine and the front-end interface based on identity management feedback, tracked usage patterns, administrator roles / key performance indicators, among others.

[0022] In some embodiments, the front end interface includes dynamically resized, reordered, and otherwise modified interactive elements, rendered in accordance with policy engine and/or data sets of tracked biometric, identity, or other information. The dynamic rendering of elements is directed to automatic, without user input, presentment of information to administrators adapted to prioritize relevant information and interactive elements. [0023] Geographic elements are overlaid onto a map rendering to establish locality of access requests, or suspicious access requests.

[0024] Interface elements associated with different types of access requests can be modified differently, e.g., fundamental flaws in biometric validation (two individuals with same match) can be flagged as serious violations, while access requests to modify / depreciation administrator roles, etc. may be rendered differently.

[0025] In accordance with another aspect, the system includes interface engines configured to dynamically generate computer-implemented graphical user interfaces that adapt to prior usage behavior and automatically emphasize data sets or visualizations that have a greater impact on the balanced plurality of outcomes. [0026] An interface engine that is provided in some embodiments is an improved dashboard. The dashboard is configured to render a grid or a list layout of interactive visual elements, each interactive visual element representing a specific instance of an ambiguous or suspicious access request. Each interactive visual element, for example, could be a graphical rendering of the type of device utilized for the biometric verification (e.g., smart phone, finger print reader, retinal scanner).

[0027] When the graphical rendering is interfaced with, e.g., via a mouse-over or a hover over or other type of selection, a two-dimensional or three-dimensional rendering is overlaid proximate to the interactive visual element indicating one or more secondary verification aspects tracked associated with the type of device. In a specific embodiment, the secondary verification aspects are gyroscopic and/or accelerometer readings form a smartphone that are utilized to indicate a corresponding tilt, rotation, or approach path / vector that was utilized during the biometric verification. [0028] In a more specific embodiment, the secondary verification aspects are tracked over a period of time for earlier access requests, and a mean value is continuously maintained. Where there is significant deviation from the mean (or where there are not enough samples), one or more visual characteristics of the rendering is modified. For example, within 0.25 standard deviations may control for a green color for the rendering, within 0.5 standard deviations may control for a yellow color for the rendering, and anything beyond 0.5 standard deviations may control for a red color for the rendering. Other numbers are possible as well., each corresponding to a different tier of modification. Accordingly, an administrator is able to quickly and easily validate differences in secondary verification aspects for a particular ambiguous or suspicious attempt.

[0029] In a further embodiment, a tertiary biometric is rendered responsive to a selection (e.g., mouse hover over and/or click or otherwise selecting the rendering). For example, if secondary biometric is a rotation, tertiary biometric can be a path taken by the device towards a reader (or a map showing geolocations). Similarly, a level of deviancy can be shown by a visual indicator (e.g., right handed user always pulls from right pocket, very odd left handed use and path is flagged).

[0030] In some embodiments, an important functionality of the console is the ability to quickly sift through a stack of suspicious of attempts for training a backend model or system. In another embodiment, an important functionality of the console is the ability to quickly sift through a stack of suspicious of attempts in real time as a final approve / reject step. In either embodiment, the system is designed for speed using an improved interface that can selectively render multiple aspects for administrator consideration visually on a graphical interface, the graphical interface showing multiple modality considerations simultaneously (the first is the match score, the second is the rotation, and the third, upon mouseover, hover, or selection, is the path that the device took through the air). The visualizations can be looped and other visual "shortcuts" are utilized, including re-sizing, color modifications, opacity, etc. that allow a very quick visual identification of deviance indicative of potential malicious access attempts based on human pattern recognition, as opposed to flagged non- malicious access attempts. [0031] Rotation is useful to determine whether a device is being used upside down, sideways, or rotated in accordance with a left hand usage or a right handed usage. A visualized path, similarly, can show how the device approached the reader or received the authentication (e.g., taken from the right pocket, the left pocket), etc. When malicious users are attempting to obtain access, they might be using various tools, and other hardware that may modify how the device is being held or moved during authentication.

[0032] This is especially useful where malicious users do not know that such a system is in place. For example, a malicious hacker is using the device upside down, with a wire plugged into the data port to feed a fraudulent signal. The device is not taken out of a pocket and is simply stationary. The attempt is flagged as suspicious. When the administrator views the primary, secondary, and tertiary modalities, including visual cues of a level of deviance from successful accesses, the administrator can easily notice this attempt (either to reject the attempt or to provide a training data set to the system).

[0033] In an even more specific embodiment, the platform is configured to receive data sets indicative of external data feeds that may affect the secondary verification aspects. For example, fingerprints may not work particularly well in the cold, and there may be an increased permissible variance where adverse weather, etc. is detected. The ranges for modifying the rendering may thus be changed.

[0034] Generating dynamic renderings is computationally intensive and increases required bandwidth for data transmission to the data backend. Accordingly, in some embodiments, pagination and selective pre-loading is utilized to reduce a computational impact of generating the renderings. Rather than pre-loading and generating renderings for all suspicious or ambiguous processed access requests, only those renderings generated and information retrieved are those listed or shown on an interface page, and additional renderings and information are drawn or rendered accordingly as a user or an administrator provides inputs to scroll down or otherwise traverse the interface page.

[0035] Dynamic dashboards are provided in some embodiments that identify compliance inspections, verify real-time authentication events, and generate visualizations in the form of charts, graphs or on a map in real time, the visualizations having interactive interface elements. The dynamic dashboards aid in supporting decision making based on information available, and in some embodiments, the system is configured to provide or generate recommendations for policy modifications, selections of modified subsets of modalities or verification mechanisms to provision, among others. [0036] The dynamic dashboards may interact with a backend policy engine, the backend policy engine generating predictions (e.g., extrapolated based on tracked historical usage data), indicative of potential effects of modifying characteristics of the various biometric modality and verification mechanisms. The generated predictions are used in generating scenarios, or overlaid on interactive elements so that an administrator is able to estimate a downstream effect of the administrator's proposed modification.

[0037] In some embodiments, the system automatically provisions predictive improvement changes over a period of time or responsive to detected events.

[0038] In various further aspects, the disclosure provides corresponding systems and devices, and logic structures such as machine-executable coded instruction sets for implementing such systems, devices, and methods.

[0039] In this respect, before explaining at least one embodiment in detail, it is to be understood that the embodiments are not limited in application to the details of construction and to the arrangements of the components set forth in the following description or illustrated in the drawings. Also, it is to be understood that the phraseology and terminology employed herein are for the purpose of description and should not be regarded as limiting.

[0040] Many further features and combinations thereof concerning embodiments described herein will appear to those skilled in the art following a reading of the instant disclosure.

DESCRIPTION OF THE FIGURES

[0041] In the figures, embodiments are illustrated by way of example. It is to be expressly understood that the description and figures are only for the purpose of illustration and as an aid to understanding. [0042] Embodiments will now be described, by way of example only, with reference to the attached figures, wherein in the figures:

[0043] FIG. 1A is an example schematic of a system stack for a system configured for the processing of a plurality of biometric information data sets, according to some embodiments. [0044] FIG. 1 B is an example facility whose access can be controlled, according to some embodiments.

[0045] FIG. 1C is an example of identity management applications that are unable to coordinate with one another.

[0046] FIG. 1 D is an illustration of a user, and various modalities / verification mechanisms that are possible, according to some embodiments.

[0047] FIG. 1 E is an illustration of a user in different contextual environments, according to some embodiments.

[0048] FIG. 1 F is an illustration of a user using a smart device having a plurality of potential modalities, according to some embodiments. [0049] FIG. 1 G is a non-limiting illustration of some of the various biometric and verification mechanisms that are available.

[0050] FIG. 1 H is an example screenshot of a summary of biometric and verification mechanisms currently available, according to some embodiments.

[0051] FIG. 11 is an example screenshot of an indication of enrollment quality, according to some embodiments.

[0052] FIG. 1J is an example screenshot of an interface screen for adding a new application and indicating the contextual usage of the application, according to some embodiments.

[0053] FIG. 1 K is an example screenshot of an interface screen for showing historical authentication requests, according to some embodiments. [0054] FIG. 2 is illustrative of an example workflow for a request for authentication, according to some embodiments.

[0055] FIG. 3 is an illustration of a workflow illustrating a process for dynamic modification of security threshold, according to some embodiments. [0056] FIG. 4A is an example administrator console dashboard screenshot, in accordance with some embodiments.

[0057] FIG. 4B is similar to FIG. 4A, showing an alert / event widget bar, according to some embodiments.

[0058] FIG. 5A is another administrator dashboard view, according to some embodiments, where an administrator is able to view the individual access activity of various users. In FIG. 5B, an alternate view is shown, wherein a summary list of authentications and events for various users is shown in a table.

[0059] FIG. 6A is an administrator dashboard where the administrator is provided a view 602 of a specific user, according to some embodiments. [0060] FIG. 6B is another administrator dashboard view, according to some embodiments, where an administrator is able to view the individual access activity of various facilities.

[0061] FIGS. 7A, and 7B are further administrator dashboard views according to some embodiments, where an administrator is able to view the individual access activity of various facilities. FIG. 7A is a user-by-user view, FIG. 7B is an activity summary view.

[0062] FIG. 8 is a risk management administrator dashboard view, according to some embodiments.

[0063] FIG. 9 is an administrator dashboard view directed to specific modalities and verification mechanisms, according to some embodiments.

[0064] FIG. 10 is a schematic diagram of computing device, exemplary of an embodiment. [0065] FIG. 11A is an example block schematic of a computer-implemented platform architecture, according to some embodiments.

[0066] FIG. 11 B is an example block schematic of the graphical user interface generation engine, according to some embodiments. [0067] FIG. 12 is a graphical rendering of the administrative interface, according to some embodiments.

[0068] FIG. 13 is a graphical rendering of the administrative interface, according to some embodiments, where a rendering is shown following a rotation indicative of an example tracked secondary biometric mechanism. [0069] FIG. 14 is a graphical rendering of the administrative interface, according to some embodiments, where a rendering is shown following a path indicative of an example tracked secondary biometric mechanism.

[0070] FIG. 15 is a graphical rendering of the administrative interface, according to some embodiments, where a rendering is shown following rotation indicative of an example tracked secondary and a path indicative of an example tracked tertiary biometric mechanism.

DETAILED DESCRIPTION

[0071] Embodiments of methods, systems, and apparatus are described through reference to the drawings. [0072] The following discussion provides many example embodiments of the inventive subject matter. Although each embodiment represents a single combination of inventive elements, the inventive subject matter is considered to include all possible combinations of the disclosed elements. Thus if one embodiment comprises elements A, B, and C, and a second embodiment comprises elements B and D, then the inventive subject matter is also considered to include other remaining combinations of A, B, C, or D, even if not explicitly disclosed. [0073] The embodiments of the devices, systems and methods described herein may be implemented in a combination of both hardware and software. These embodiments may be implemented on programmable computers, each computer including at least one processor, a data storage system (including volatile memory or non-volatile memory or other data storage elements or a combination thereof), and at least one communication interface.

[0074] Identity management is a difficult technical endeavour wherein competing priorities require balance in establishing and provisioning of access to users requesting access to one or more facilities, the facilities including virtual facilities, physical facilities, etc. Identity management is an important feature of modern systems, and is used across industries and technologies to establish trust that a particular user is a trusted entity. Physical access is described in a preferred embodiment. In another preferred embodiment, facilities explicitly includes virtual access control, including file permissions (e.g., read, write, modify), administrator rights, network security, whitelisting, blacklisting, among others.

[0075] Identity management has widespread applicability, ranging from the securing of highly sensitive personal, corporate, governmental, or financial information (e.g., voting information, access to banking information, corporate documents) to less sensitive access provisioning in relation to low risk and/or low impact (e.g., access to a movie theatre). "Access" is not limited to physical access (e.g., unlocking doors), but in some embodiments, may include virtual access (e.g., file permissions, administrator access), among others. Access may also have various features that may be modified based on identity, for example, some users may have their access monitored (e.g., users on probationary access, visitors to a secure facility), or various workflows or downstream processes may be initiated in response to the validation of a particular entity (e.g., upon validating that a user is an identity that has a loyalty rewards status, a room upgrade may be provided at a hotel). [0076] Identity management, in particular, is important in relation to the provisioning of financial services and other associated services and products. The ability to obtain loans, conduct transactions, etc. are identity-based, and rightful identity management is a prevalent issue. Poor identity management, for example, may lead to significant losses from fraud or other malicious / unauthorized use. Financial institutions are so trusted that, for example, financial services identity management is used for the verification for non-financial services based services as well. For example, to check the status of an application for a hunting license or the checking of a driver's record, a governmental website may request that a user log in through a trusted validation partner, such as a bank. Banking atmospheres are built on trust, and identity established only through traditional identification documents and easy- to-lose/forget passwords has been fraught with problems.

[0077] Competing priorities include desired levels of security, ease of use, required infrastructure, available computing resources, among others. For example, if an identity management mechanism is too onerous or difficult to use, users, even authorized users, may simply abandon their attempts to obtain access, but an identity management mechanism that is overly simplistic may be prone to fraud and may be easily compromised. Various individual biometric modalities and verification mechanisms are available, but these biometric modalities and verification mechanisms are often silo-ed and uncoordinated. There is an opportunity to vary challenge difficulty based on contextual factors, such as age, health conditions, savviness with technology, devices owned / actually used by a user, for example.

[0078] The lack of coordination has a negative impact on customer experience, as cumbersome identity management impacts transaction times (e.g., EMV chips that require more time and equipment to process due to the added PIN). Although an average processing time is about 15 seconds, these times, together, will account for hours of lost time, especially with the long line-ups seen on major purchasing holidays, such as Black Friday. Despite technological protection measures in place, the EMV and PIN systems are static systems vulnerable to fraud and have very limited abilities for dynamic adjustment even when a large pattern of fraud is detected (which may be indicative that either of the technologies has been seriously compromised). For example, a retailer, to prevent unacceptable increases of fraud may simply choose not to accept credit card payments if EMV / PIN appear to be problematic, but this decision may lead to frustrated customers and long line-ups at cashiers. Furthermore, the static nature of identity verification implies that long-term susceptibility to threats remain in place. For example, if someone copies a mag stripe or even a chip, they can easily replicate that data over and over again as the underlying technology is unable to change. [0079] Identity management systems are deeply integrated and connected with other systems. For example, identity management systems can be utilized in conjunction with directory services to build and track user profiles, identifying levels of access provisioned to each user and their associated permissions, at varying levels of granularity. Identity management can be used, in some embodiments, in generating identity challenges (that may be passive, or active; periodic, on request, or continuous) that invoke one or more biometric modalities or verification mechanisms to collect challenge response data sets. The challenge response data sets are then processed to determine whether access should be granted (or continued) for the user. [0080] There are a diversity of biometric verification and verification mechanisms that are available. Each biometric verification and verification mechanism has different characteristics, including strengths and weaknesses. Some mechanisms are designed to be tunable such that differing levels of security are possible, but such tuning approaches are often rudimentary and fundamental technical weaknesses persist despite differing levels of protection available for a given biometric verification and verification mechanism.

[0081] As the information or permissions being protected are often valuable, there is an "arms race" with malicious counterparties seeking to subvert or otherwise gain unauthorized access into virtual or physical facilities. Static platforms are more vulnerable as "zero-day" vulnerabilities spread and are propagated following identification of a potential attack vector. Entire sectors of the population become vulnerable, and systems are often slow to adapt to newly developing attacks.

[0082] The biometric verification and verification mechanisms, in some cases, can also have different availability characteristics. For example, in the age of smartphones, smart watches, and tablet devices, a single device may be the host to a plurality of different biometric verification and verification mechanisms, and some of which can be actively invoked (e.g., facial recognition via a camera), and others which may have passive monitoring aspects (e.g., gait, the order in which pages are traversed).

[0083] In various embodiments, an improved identity management platform is described that uses computer-implemented systems and methods to provide coordinated identity management across a plurality of biometric modalities and verification mechanisms, dynamically modifying implementation and tuning characteristics to provide a synchronized approach that takes advantage of the diversity of characteristics of each of (or a subset thereof) the differently tuned biometric modalities and verification mechanisms to obtain improved user, administrative, and backend outcomes.

[0084] The differences in ease of use, availability, flexibility in configuration, and trust characteristics of each biometric modality and verification mechanism are synchronized to increase an overall effectiveness of a solution. Coordination and synchronization is important in taking advantage of the differences in strengths and weaknesses of different biometric modalities and verification mechanisms in providing layered protection that is adaptive to stimuli, external obtained and/or internally generated. There may be some technologies that, by themselves, have significant weaknesses, but may provide an additional level of protection if combined with other technologies. For example, near field communication (NFC) verification mechanisms are prone to eavesdropping, data corruption, modification, interception attacks, and physical theft, among others. However, these NFC is a convenient and easy to use technology, and in combination with other identity verification mechanisms, may provide an effective layer of protection.

[0085] In some embodiments, a password-less identity can be established using a suitable combination of identity factors (i.e., removing the need to memorize multiple passwords).

[0086] In some embodiments, specific elements of protection are selected for different applications, and even for a same authentication challenge, different elements can be selected such that the system is less vulnerable to compromise (e.g., a malicious individual may have a hard time predicting which modalities / mechanisms may be requested). [0087] The dynamic aspects are directed to a flexible system that is able to responsively modify identity management practices over time as data sets are processed, the data sets relating to feedback regarding actual use of the modalities and verification mechanisms (e.g., failed attempts, abandoned attempts), or external factors (e.g., a zero-day vulnerability found in a device, leading to compromised verification pathways), among others. Contextual data may be consumed to pre-emptively modify weights associated with various biometric modalities and weightings. For example, if a user does not lock his/her device often, or has low security settings (e.g., screen locks, time-out, poorly coded applications), the device may be indicated as having lower trust, and any verification that is obtained from it may need to be combined with other mechanisms. Other context may include IP addresses, MAC addresses, location, network connection type, time of use, network transmission pathways, VPN usage, application update status, application version, operating system version, IMEI, device serial number, among others.

[0088] Including passive contextual features further increases a security level without encumbering the customer experience with another step.

[0089] Risk can be dynamically managed across an organization at various levels of granularity. Access, based on identity management, can be tiered and/or grouped such that appropriate security features can be dynamically implemented, tuned for a potential for risk, an impact of breach, availability of computing resources, and a need for ease of access. [0090] Improved outcomes are not limited solely to improved accuracy or security levels, rather, improved outcomes are directed to enhancing an overall experience across a variety of factors, such as ease of use, availability across a user base, sensitivity, specificity, etc. An objective of some embodiments is to provide identity management that is relatively transparent and as seamless as possible relative to the user experience, and in some scenarios, it may be unacceptable to cause undue delays or difficulties in establishing identity.

[0091] An adaptive system is provided that can adapt identity challenge processes to become "fit for purpose" in relation to specific measured performance indicators or outcomes. These performance indicators or outcomes are not limited to technical-oriented outcomes (e.g., number of breaches, success rate or failure rate), but instead, may be tied to other performance indicators, such as an acceptable business loss rate due to unauthorized transactions, etc. For example, the adaptive system may be provided in the context of a bank, whose managers have deemed that there will always be an acceptable level of loss due to fraud. The bank is an operating business, and overall profitability is important. Protective measures need to be right sized to balance ease of use and protection, as each intervening step, depending on difficulty, could lead to business losses as customers become frustrated with the system.

[0092] Accordingly, an identity management office may choose to enact identity management policies that provide a sufficient level of protection that, while not providing absolute identity identification, is suitable given the risk / impact parameters set out by the bank.

[0093] The system may adaptively monitor and modify difficulties of identity challenges such that the fraud level (e.g., measured by losses due to unauthorized access) is maintained within an acceptable range, and in some cases, lower overall challenge difficulty, with a goal of increasing uptake / adoption of a product / service by reducing identity challenge-based barriers.

[0094] Dynamic dashboards are provided in some embodiments that identify compliance inspections, verify real-time authentication events, and generate visualizations in the form of charts, graphs or on a map in real time, the visualizations having interactive interface elements. The dynamic dashboards aid in supporting decision making based on information available, and in some embodiments, the system is configured to provide or generate recommendations for policy modifications, selections of modified subsets of modalities or verification mechanisms to provision, among others. In some embodiments, the system automatically provisions predictive improvement changes over a period of time or responsive to detected events.

[0095] The dynamic dashboards are rendered or otherwise generated or instantiated by interface engines configured to dynamically generate computer-implemented graphical user interfaces and interactive elements. [0096] These interfaces and interactive elements adapt to prior usage behavior and automatically emphasize data sets or visualizations that have a greater impact on the balanced plurality of outcomes. The emphasis may be conducted free of human intervention, and may be generated instead based on a role or identify key performance indicators associated with the role.

[0097] FIG. 1A is an example schematic of a system stack for a system configured for the processing of a plurality of biometric information data sets, according to some embodiments. Corresponding methods, and non-transitory computer readable media are also provided. FIG. 1A illustrates a platform 100 where a number of different applications 102 (e.g., access control 104, time and attendance systems 106, financial services platforms 108, Identity-as- a-Service (IDaaS) platforms 110, Internet of Things devices 112 are configured to electronically communicate with a biometric information processing platform 100 through a universal API 114.

[0098] FIG. 1 B is an example facility whose access can be controlled, according to some embodiments. While a physical access is shown, it should be understood that virtual access may also be controlled in a similar fashion in accordance with embodiments described herein. [0099] In FIG. 1 B, differing levels of secured access may be provided - for example, exterior (doors, access to premises), interior (cabinets, internal doors leading to various facility sections), and areas of high security (e.g., a data center room with sensitive electronics). Access may be provisioned based on identity (for example, only those with IT training, credentials, and a reason for entering should be allowed to access the data center room). Even within areas of high security, there may be even more granular access that is also managed by the platform 100 (login to various terminals, access to cabinets).

[00100] Access control 104 may refer to, for example, facility access systems that are configured for receiving biometric inputs and using the outcome of an identity match or verification to provision or de-provision access to a facility (e.g., warehouse, office, parking lot), area (e.g., secured section), object (e.g., cabinets).

[00101] Such systems include electronic contacts and triggers that are operable to control locks, doors, barriers, among others. The level of security may vary depending on the type of access - highly secured facilities may include areas with servers housing sensitive data, and less secured facilities may include storage units in a storage complex. There may be a mixture of different security levels for access in a single facility. Access control may also extend to virtual systems, including virtual private networks, file systems, etc. For example, access control may apply differently to administrative actions, or even more granularly, may be determined at the level of an operation and/or the number of files being impacted by a particular operation.

[00102] In conventional access control systems, access is typically provisioned through the use of a specially configured pass card (e.g., a card having RFID technology).

[00103] An example is shown in FIG. 1 C. In FIG. 1C, dedicated identity management / authentication applications are provided in silos and are unable to communicate with one another. A weakness of such access control systems is that the access control modality is prone to compromise and the consequences of compromise are difficult to control relative to the access granted. For example, an employee who is on his/her first day at the job may be given a pass card, which the employee then uses to enter the facility overnight and steal sensitive information. Further, where a RFID verification method is compromised, a malicious user may easily clone or otherwise create falsified passes that provide for unauthorized access.

[00104] Such access systems typically do not have a strong indication of the identity of the individual aside from an account number associated with the card, and even where unauthorized access is indicated, it often cannot be easily traced to a true identity of an individual. For example, another user may steal an employee's card, and use it for access. The conventional access system merely tracks the ID of the stolen card, which is a compromised suspect identity. There is simply not enough information to identify the identity of the user that stole the card and used it for access. [00105] In contrast, some embodiments of platform 100 are adapted to intelligently combine and utilize the diversity of characteristics of a plurality of modalities and biometric data information such that increased access security may be provisioned for a facility. As shown in FIG. 1 D, the identity of a user can be made up of various identifying features related to the user, and many of these identifying features can be integrated into use with platform 100. In FIG. 1 E, an illustration is provided to indicate that the context of the user's use may also be a factor that is taken into consideration by platform 100 in deciding whether access should be provisioned (e.g., a challenge response provided in a secured office may be more trustworthy than a challenge response provided while in public). [00106] Some or all of the biometric verification and verification mechanisms may be provided on multi-purpose smart devices, such as smartphones, as shown in the illustration of FIG. 1 F. The device may conveniently include a plurality of different biometric verification and verification mechanisms, and some of which can be actively invoked (e.g., facial recognition via a camera), and others which may have passive monitoring aspects (e.g., gait, the order in which pages are traversed). FIG. 1G is a non-limiting illustration of some of the various biometric and verification mechanisms that are available. As shown in FIG. 1 H, these biometric and verification mechanisms may be conveniently enrolled onto the user's device, and differing levels of trust may be assigned, for example, based on enrollment quality of the stored data, according to FIG. 11, and differing trust requirements may be appended based on a usage (e.g., for work or personal), as shown in FIG. 1 J. Accordingly, the platform 100 may be configured to permit a user to use different modalities or verification mechanisms for obtaining access different applications, as long as the user is able to meet a trust requirement, in aggregate.

[00107] Time and attendance systems 106 may include resource tracking systems adapted to determine if resources (e.g., workers) are present at a facility, for example, during work hours or in relation to a particular task. The systems may require a fairly high level of accuracy as the determination of the real identity of a resource may be important in relation to compensation being paid to the resource, etc. For example, factory workers may utilize a facial recognition system that identifies them when starting and ending a shift, tracking the total hours worked to ensure that fair compensation is paid and that workplace regulations regarding maximum number of hours worked are complied with. A challenge with conventional time and attendance systems is in relation to the falsification of identities or inaccurate identification of identities. In the event of such a scenario, remuneration may not be accurately tracked. [00108] Financial services platforms 108 may include financial institutions (e.g., banks, insurance companies, credit unions), trading platforms, and any service being provided in relation to the financial interests of a user (e.g., store credit, rewards). These platforms may be configured to receive various elements of authentication information, such as passwords, PINs, biometric information (e.g., fingerprints), etc. In some embodiments, financial services platforms 108 further include computing devices and systems that are adapted to be used by a user in relation to obtaining financial services, such as applications being available on mobile computing devices, etc. These mobile computing devices may be able to receive various elements of information, including passwords, PIN information, biometric information (e.g., photos taken on a camera, voice information taken from a microphone, location information from tracked coordinates, behavioral information such as steps taken or accelerometer data).

[00109] Identity-as-a-Service (IDaaS) platforms 110 include, for example, platforms that are designed specifically to track access across a number of platforms, for example, single sign-on systems, authentication and access. These systems may be in electronic communication with directory services (e.g., LDAP or OLAP), which allow for authentication cross-platform in secured environments. An important consideration for such systems is that access needs a high level of identity verification as multiple services and access provisioning may be based off of a single validation. [00110] Internet of Things devices 112 include various devices that are configured for communication with one another or with various back ends. These devices are increasingly widespread, and may include intelligent appliances, home automation solutions, security, etc. As more features become automated, trusted authentication and/or verification may be increasingly important as there may be significant security and privacy concerns that may be raised in relation to information being provided and control being provisioned.

[0011 1] Universal API 114 is configured to allow for multiple different APIs to be used, and to ensure compatibility with different systems. For example, an implementation may have a web services API, a WCF services API, a Database API, and RESTful API with the ability to add more interfaces, as required. These interfaces may be configured for providing adapted information for third party services, adapted based on common functionality and information stored on platform 100. For example, a particular access control system may require information packaged based on a specific protocol that may be different from another access control system. Accordingly, universal API 114 is adapted to be able to access information stored on data structures, including trusted profile information and biometric data sets in response to various computer-implemented instruction sets, and queries.

[00112] Universal API 114 is configured to generate output payloads that are developed in response to specific requirements of various external systems. For example, a lookup table or other logical conditions, functions, and triggers may be applied to transform the data set from a generic function to a specific function for use with the system. [00113] Universal API 114 is important for the integration of 3rd party software packages directly into the platform 100, and also provides us the ability to do more than one integration at a time. For example, in global corporations, there may be 3-5 Physical Access Control systems in place, one for the retail stores, one for the corporate offices, one for their warehouses, and one for their data centers. [00114] The platform 100 unifies the biometric data across all the systems so that when an employee goes between their locations, they do not need to re-enroll, they just work. The platform 100 is provisioned to provide a frictionless user experience (e.g., increased convenience and security). The different data types and structures are also handled to provide for cross platform support and increased flexibility in relation to new services being added, new biometric modalities being added, as provided from a diverse range of devices that may be trusted at different levels of trust.

[00115] Platform 100 includes Trust Al 116, an identity manager unit 118, a biometric matching unit 120, a data security unit 122, a directory services unit 124, and a template distribution unit 126. The platform 100 further includes a single identity database layer 128, which maintains one or more data structures configured for the storage of one or more biometric data sets.

[00116] Trust Al 116 is a policy engine configured to dynamically reweight and modify how the system interacts with information stored on various biometric and non-biometric data sets over a period of time. In some embodiments, feedback, machine learning, and/or artificial information (Al) techniques are utilized by the Trust Al 116 such that the requirements for establishing a "trusted profile" are adaptive to identified environmental information (e.g., time of day, location of users, month, weather), convenience information (e.g., success rate of authentication by modality, average time of matching / verification), events (e.g., compromised data alerts, compromised network, security incidents).

[00117] The "trust level" associated with specific modalities, device types, specific devices, communications pathways, encryption methods, etc. may be dynamically modified in view of specific outcomes that the Trust Al 116 is configured to trend towards. For example, a biometric system may be configured to intelligently balance convenience and security level between acceptable thresholds.

[00118] The Trust Al 116 is configured to advantageously utilize determined and/or monitored differences in the obtaining of processing of biometric and non-biometric data sets from different modalities or different sources to balance convenience and security level between acceptable thresholds. For example, if five modalities are available to the Trust Al 116, the Trust Al 116 may be configured to select at least two modalities for determining (e.g., by verification or matching) associated with an unknown user that provides at least high confidence score for a highly secured facility. The Trust Al 116 may be configured for determining the specific combination of modalities and requirements (e.g., 2-5 fingers for fingerprints, password, retinal scan, voice scan), based on trust level associated with each element, a threshold of convenience (computing must be faster than 10 seconds), a threshold of security (high security could mean a score between 60 and 80) and also other extrinsic information, such as position of individual, consequences of malicious access, time of day, behavioural cues, etc. [00119] Security requirements can be different for all types of applications - The level of identity assurance required by a simple application login is likely very different than the level of identity assurance required to perform a high risk transaction such as a large financial money wire. However, higher security authentication techniques often cause a tradeoff of convenience. [00120] When it comes to biometrics, it can be difficult to know the level of identity assurance that a biometric modality provides. In many cases the market solution involves combining biometrics with other modes of authentication and creating static rules or policies regarding which types are required for various transactions. This comes at a cost to the overall user experience and slows the adoption rate of biometric technology.

[00121] The Trust Al 116 is configured to solve these problems by dynamically assessing the risk and identity assurance requirements of transactions using various captured data and matching the authentication requests to the appropriate authentication modes. This technology both helps ensure that the necessary security/identity assurance requirements are met for all authentication requests, while at the same time assessing scenarios where the identity assurance requirements are low and thus lowering the authentication requirements to the user - improving the user experience where possible.

[00122] The Trust Al 116 uses a number of "inputs" to determine the level of risk and identity assurance requirements associated with an authentication request. Examples include, but are not limited to authentication patterns for a specific user, time of day authentication patterns, day of week authentication patterns, geographical authentication patterns, device type/identifier authentication patterns, and other extrinsic factors, such as whether there are known vulnerabilities with the type of device requesting authentication, is the request originating from a geographical location known for fraudulent attacks, among others; behavioural biometric factors such as whether behavioral biometric data captured using the SDK 150 during the authentication request, and are there usage patterns within the behavior, walking pace, posture detected through accelerometer, fingerprint touch screen gestures, typing patterns, among others.

[00123] In some embodiments, the factors for consideration are voluntary (e.g., user actively provides them), and in some other embodiments, the factors are involuntary (e.g., the modalities are passively tracked and the user is unaware). In yet further embodiments, the factors are a combination of voluntary and involuntary.

[00124] Accordingly, using a combination of these data inputs (when available), the Trust Al 116 is configured to intelligently determine the likelihood that the authentication claimant is the correct identity. If the output is that the claimant is likely the requested identity, then the Trust Al can reduce the authentication requirements by allowing the use of less factors for authentication, biometrics that offer more convenient/easy use, or in some cases bypassing further authentication altogether. The Trust Al is configured to reduce the authentication requirements to the minimum set by the relying application. Therefore the relying application would have the ability to set a minimum authentication requirement that the Trust Al could output to the user.

[00125] The Trust Al 116 may be configured to raise the authentication requirements beyond the minimum requested by the application if it detects risk when evaluating the various data input factors. This ensures that a balance is kept between strong security/low convenience and low security/highly convenient authentication methods. The authentication requirements may, for example, be based on an equal acceptance rate where a false rejection rate and a false acceptance rate are tuned to be equal.

[00126] The identity manager unit 118 may be configured for providing and maintaining trusted identity profiles for one or more users. In some embodiments, identity manager unit 118 is configured for cross-linking of identity profiles and information such that trends, strengths, and/or weaknesses in relation to trust may be propagated across users and profiles. In some embodiments, the identity manager unit 118 may also be configured to identify duplicates. [00127] The biometric matching unit 120, The biometric matching unit 120 is configured for mass scale matching across a variety of template types, and security levels. For example, ISO vs Vendor2 templates, sizes of 384 vs 768 bytes. The biometric matching unit 120 developed by Applicant has been also scale-tested to work with matching 250,000 templates in under a second. [00128] An analytics engine is provided that is configured to store, manage, and report on all events within the platform 100, adapted for the creation of an audit trail, and leveraging the data to predict template usages, and dynamically re-indexing the matching engine based on usage (e.g., successful / unsuccessful authentications, computing time). [00129] A directory services unit 124 is provided that is configured to manage the security of users within the system, and also to handle the variety of credentials, and biometric modalities, the service is also able to integrate into 3 ^rd party directory services such as Active Directory or LDAP. [00130] A template distribution unit 126 is configured for the generation of templates based on stored biometric data set information and the propagation of the templates to different parallel processing units.

[00131] The platform 100 further includes a single identity database layer 128, which maintains the one or more data structures configured for the storage of one or more biometric data sets, such that the set of templates associated with an identity of a particular user can be associated with user profile information, and corresponding trust and confidence levels can be associated with each of the templates, for example, based on characteristics of extract, how current the template is, whether the modality has been compromised, etc.

[00132] Platform 100 includes a biometric software development kit (SDK) 150, including configured interfaces that are designed for communication with a variety of different biometric devices that are configured to capture one or more biometric modalities. These biometric devices, for example, may include various authenticator systems (e.g., facial 130, voice 132, behavioural 134, eye 136, finger 138, heartbeat, password, PIN capture systems). These biometric devices may include both systems that are designed as single- purpose devices, or general computing devices that are configured to be able to provide functionality beyond biometric recognition, such as smartphones, tablets, etc.

[00133] The platform 100 may also connect to devices from various manufacturers and organizations, include biometric door access (e.g., Vendorl) devices 140, biometric cabinet access (e.g., Vendor2) devices 142, and other third party devices 144. In some embodiments, various third party databases and storage may be in communication with platform 100 such that information may be obtained in relation to extrinsic factors that may not be associated with a particular individual, but may rather be associated with population data in general (e.g., the number of people residing in the Eastern United States) , groups of individuals (e.g., customers of a particular social media platform have had their identities compromised), or extrinsic information (e.g., event-related data, time of day, date), among others.

[00134] The platform 100 is configured to receive information in the form of data sets from the biometric devices into universal biometric software development kit (SDK) 150 (e.g., a standardized biometric SDK). The data sets may include information including biometric data payloads (e.g., identifying features of biometric data), information relating to the capture, information relating to the completeness of capture, information relating to the device itself, information relating to the communication method in which the data is transmitted, information relating to the security features relating to the data being transmitted, among other information. The data sets, where captured by a device capable of general computing functions, may be adapted to track device type, whether the secured feature is sandboxed, whether secure communication protocols were used, the type of secure communication profile, etc.

[00135] The platform 100 is configured as a hardware abstraction layer that provides a degree of separation from the devices and the system on the top end. As devices all use different methods to communicate, from TCP/IP or UDP protocols, synchronous or asynchronous communication, SDKs, or cross-service APIs, and these methods may evolve as different generations of protocols are released.

Universal SDK [00136] Universal SDK 150 and platform 100 are adapted to simplify the adoption of biometric technology for application developers, by normalizing the communication paths to all modalities by creating a single SDK that allows application developers to implement multiple biometric modalities through a single integration. Using the platform 100, application developers are able to access to the leading modalities in a variety of categories (including but not limited to; face, eyes, voice, fingerprint, cardiac, and behavioural biometric modalities).

[00137] The platform 100's SDK 150 can be accessed by both application developers who are looking to embed biometric technologies into their mobile applications, as well as by hardware-based biometric device manufacturers who want to include compatibility for use with the platform.

[00138] Communication standards are not always identical across each biometric modality, and SDK 150 is configured to ensure that a common level of communication and security standards are met across all biometric modalities.

[00139] Standardized user interfaces and user experience flows are provided within the SDKs, permitting application developers to include multiple modality types within their application without worrying that the "look and feel" of each modality being drastically different. [00140] Standardized communication & security requirements are provided. For example, wide area networks such as WiFi points and cellular networks can be intercepted by fraudulent users, and it is important that biometric technologies within the platform meet high standards for transferring data between the device and platform 100. The requirements include but are not limited to using secure public/private key encryption to ensure the safe transfer of data.

[00141] SDK function mapping is performed to utilize (where possible) automated systems for mapping SDK function calls. This technology helps expedite the process of updating SDK libraries when a modality releases a new SDK and allows the platform 100 to provide technology to the market faster than other platform vendors. Universal API

[00142] Similar to the market problems relating to a divergent set of modalities and devices, some application developers may find it more difficult to take advantage of biometric technology when they either don't already have a mobile application to integrate an SDK, or if the use case is not suitable for a mobile deployment of biometrics. [00143] The Universal API 114 is configured to provide a platform from which any application with an identity requirement can utilize one or more biometric technologies. [00144] The API 114 is the gateway into the platform 100 and can be used by both mobile application developers who are implementing biometric functionality, as well as application developers who may not already have a mobile application and want to leverage the platform 100 for biometric authentication. [00145] The Universal API 114 serves the following primary functions: it provides a gateway for authentication requests and responses to/from relying applications; it handles requests for authentication are then passed onto the Trust Al before biometric matching; and it provides a gateway for biometric identification (1 :n) requests from either a mobile authenticator or applications that have integrated the SDK 150, and it provides a gateway for uploading and downloading template data to biometric devices, facilitating the secure transfer of biometric data across devices.

[00146] FIG. 2 is illustrative of an example workflow for a request for authentication, according to some embodiments. The workflow may be performed, for example, by the platform 100 where a request for authentication is received, for example, through the SDK 150. The authentication process includes utilizing the Trust Al 116 to classify and determine the modality needs required for a particular risk level. The API 114 may interoperate with various biometric devices and other extrinsic devices to obtain biometric data sets that are utilized for authentication (e.g., by verification or matching), and the matching unit 120 is configured to perform verification on a 1 : 1 basis (e.g., where the target identity to be confirmed against is known), or on a 1 :n basis (e.g., where the target identity to be confirmed against is unknown).

Trust Al

[00147] Security requirements can be different for all types of applications - The level of identity assurance required by a simple application login is likely very different than the level of identity assurance required to perform a high risk transaction such as a large financial money wire. However, higher security authentication techniques often cause a tradeoff of convenience. [00148] When it comes to biometrics, it can be difficult to know the level of identity assurance that a biometric modality provides. In many cases the market solution involves combining biometrics with other modes of authentication and creating static rules or policies regarding which types are required for various transactions. This comes at a cost to the overall user experience and slows the adoption rate of biometric technology.

[00149] The Trust Al 116 is configured to solve these problems by dynamically assessing the risk and identity assurance requirements of transactions using various captured data and matching the authentication requests to the appropriate authentication modes. This technology both help ensure that the necessary security/identity assurance requirements are met for all authentication requests, while at the same time assessing scenarios where the identity assurance requirements are low and thus lowering the authentication requirements to the user - improving the user experience where possible.

[00150] The Trust Al 116 uses a number of "inputs" to determine the level of risk and identity assurance requirements associated with an authentication request. Examples include, but are not limited to authentication patterns for a specific user, time of day authentication patterns, day of week authentication patterns, geographical authentication patterns, device type/identifier authentication patterns, and other extrinsic factors, such as whether there are known vulnerabilities with the type of device requesting authentication, is the request originating from a geographical location known for fraudulent attacks, among others; behavioural biometric factors such as whether behavioral biometric data captured using the SDK 150 during the authentication request, and are there usage patterns within the behavior, walking pace, posture detected through accelerometer, fingerprint touch screen gestures, typing patterns, among others.

[00151] In some embodiments, the factors for consideration are voluntary (e.g., user actively provides them), and in some other embodiments, the factors are involuntary (e.g., the modalities are passively tracked and the user is unaware). In yet further embodiments, the factors are a combination of voluntary and involuntary.

[00152] Accordingly, using a combination of these data inputs (when available), the Trust Al 116 is configured to intelligently determine the likelihood that the authentication claimant is the correct identity. If the output is that the claimant is likely the requested identity, then the Trust Al can reduce the authentication requirements by allowing the use of less factors for authentication, biometrics that offer more convenient/easy use, or in some cases bypassing further authentication altogether. The Trust Al is configured to reduce the authentication requirements to the minimum set by the relying application. Therefore the relying application would have the ability to set a minimum authentication requirement that the Trust Al could output to the user.

[00153] The Trust Al 116 may be configured to raise the authentication requirements beyond the minimum requested by the application if it detects risk when evaluating the various data input factors. This ensures that a balance is kept between strong security/low convenience and low security/highly convenient authentication methods.

[00154] FIG. 3 is an illustration of a workflow illustrating a process for dynamic modification of security threshold, according to some embodiments. Using (but not limited to) the data inputs outlined in the above section, the Trust Al 116 uses artificial intelligence technologies to dynamically determine the authentication requirements for a given transaction. As illustrated in FIG. 3, an authentication request is received which triggers an API call through the API 114. The Trust Al 116 is invoked, wherein authentication information is received from both voluntary and involuntary sources, in addition to extrinsic sources. The authentication information is then checked against contextual data from previous authentication events and the original biometric template in data storage to determine the risk level / accuracy of the presented biometric modality and current contextual data for authentication purposes.

[00155] In some embodiments, the Trust Al 116 maintains an internal reference model comprising a data matrix linking various trust levels, biometric modalities, levels of trust, user profiles, computing time, etc. such that analysis may be conducted against known data sets and linkages can be assigned weightings and scores appropriately based on past behaviours and events.

[00156] As indicated in FIG. 3, there may be classifications between various risk levels (shown as high, medium, and low), and the distinction between each of the thresholds may be modified over time in view of feedback received by the Trust Al 116 as it rebalances convenience, available processing power, consequences of unauthorized access, among other factors.

Administrator Console [00157] As described above, a component of the platform 100 is an interactive administrator console, in some embodiments. The administrator console provides a single enforcement point for access policies, remove authentication and authorization logic from applications, bridging the gap between access to core, custom on-premise resources and other backend applications. [00158] The challenge for administrators, such as IT and Operations managers, includes properly analyzing the threats to and vulnerabilities of an information system, and identify appropriate and cost-effective counter-measures.

[00159] The interactive administrator console serves as a "command and control" interface for the administrator, and administrators may have different roles, skillsets, and desired outcomes. For example, some administrators may be IT administrators seeking to monitor access and identify root causes for security breaches, while other administrators may be business analysts tasked with tweaking the operation of the platform 100 to obtain improved outcomes that, in some embodiments, are related directed to key performance indicators that are relevant to the administrator (e.g., total fraud level relative to acceptable fraud level, profits and losses derived from the fraud level, time-to-completion of a task). Risk assessments are performed by the administrators, and the platform 100 is configured to dynamically present information that represents specific variables of interest, indicative of threats, vulnerabilities, assets, and countermeasures, at varying levels of detail. In some embodiments, additional processing is performed to generate summary values that are representative of consolidated data.

[00160] There can be different scales of implementation - smaller implementations (e.g., household, small office), mid-sized implementations (shared-use facilities, warehouses), and large implementations (country-level implementations, global identity verification mechanism), and accordingly, an extremely large amount of data may be available and tracked over a period of time. Accordingly, being able to effectively sift through and process this data may be impossible for any given person, and computer-implemented technical features may be necessary in some embodiments to provide computer-aided decision making tools.

[00161] Accordingly, the dashboards are designed to empower administrators beyond conventional security administrator dashboards, providing indicators not only relating to security (e.g., false positives, negatives, true positives, negatives), but rather of overall experience across a variety of factors, such as ease of use, availability across a user base, sensitivity, specificity, or combinations thereof. A holistic understanding of security and identity management may then be mapped to specific outcomes, predicted or actual, such that informed business decisions may either be made by the administrator, suggested to the administrator, or automatically made on behalf of the administrator (for example, a major breach is determined at a time when the administrator is asleep - the platform 100 may, in these severe situations, be configured to automatically modify trust requirements in response to the breach).

[00162] A large amount of data is available to the platform 100, and in some embodiments, the platform 100 is configured to resize, reformat, color, reposition or otherwise modify how informational elements are presented to the administrator to improve the consumption of information and relevance of decision making by the administrator. Information is tracked such that changes over time are depicted (e.g., visually using graphs and charts), and information can be synthesized in the form of "risk", "trust", or "impact" scores, or holistic combinations thereof. For example, an overall confidence parameter may be determined and visually depicted that, may be dynamically weighted and calculated as model variables change.

[00163] For example, a trend line of a match score over time can be shown on FIG. 4A at 404. A definitive biometric match score line visually represents the accuracy (or match) of the presented biometric to the biometric template in data storage at a time of a biometric authentication (access) event. [00164] At FIG. 12, each of the one or more dynamically rendered user interface elements represents a separate biometric modality match score or an aggregated biometric modality match score for an individual authentication event, and the one or more dynamically rendered user interface elements include corresponding control elements which when interfaced with, directly cause a corresponding risk policy to be created, edited, or deleted. The change can be implemented by a trust score slider interface element 812, for example.

[00165] In some embodiments, predictive features are included whereby predictive sensitivity analyses are provided prior to the provisioning of changes to the operation of the policy engine. For example, total fraud levels may be interpolated from existing data (especially where existing data forms a sufficiently large corpus of data), and these may be rendered or otherwise overlaid overtop of existing interface elements and visual displays to provide a useful decision making tool. A second slider alongside 812 may also be provided in some embodiments that allows both a difficulty level (e.g., false rejection rate) and a fraud rate (e.g., false acceptance rate) to be modified. When both slides are moved alongside one another, the system backend re-weights and modifies match score requirements.

[00166] Dynamic dashboards can be utilized for conducting audits of the efficacy of the platform 100, indicating identify compliance inspections, verified realtime authentication events, among others. The dashboards may track different types of users, such as employees, customers, partners, among others.

[00167] Visualizations are generated in the form of charts, graphs or on a map in real time, the visualizations having interactive interface elements. These interactive interface elements include drag and drop pointers that may be moved across timelines, informational widget bars that allow for filtering by biometric modality or verification mechanisms, among others. Sliders may be provided that allow for dynamic modifications of trust levels (or the modifications of other priorities of the platform 100), which are then interpreted by the policy engine in performing automatic determinations of which biometric modality or verification mechanisms to request on challenge requests, and weightings thereof. [00168] Given a sufficiently large corpus of historical information or predictive information, recommendations for policy modifications may be suggested. The dynamic dashboards are rendered or otherwise generated or instantiated by interface engines configured to dynamically generate computer-implemented graphical user interfaces and interactive elements. These interfaces may be derived in accordance with a role or other characteristic of the administrator, and different administrators may be provided with different dashboards. A modality page is shown at FIG. 6A.

[00169] Each of the one or more biometric modalities data sets is rendered to display only the relevant information to a user based on previous actions (i.e., setting a risk level or a biometric modality type). The one or more dynamically rendered graphical user interface elements include corresponding control elements which when interfaced with, generate a corresponding recommendation for usage of said biometric modality. This graphical user interface generation engine is configured for generating an interface that highlights the differences of a comparison of a multitude of biometric modalities to make it intuitive for administrators with no knowledge of biometrics to make informed and appropriate decisions.

[00170] These interfaces and interactive elements adapt to prior usage behavior and automatically emphasize data sets or visualizations that have a greater impact on the balanced plurality of outcomes. The emphasis may be conducted free of human intervention, and may be generated instead based on a role or identify key performance indicators associated with the role.

[00171] FIG. 4A is an example administrator console dashboard screenshot, in accordance with some embodiments. In FIG. 4A, the administrator is Mark (shown as 402), and Mark is in charge of overseeing various user groups spread out over different geographic locations. Mark may be in charge of a large number of facilities, and the facilities chosen to be shown to Mark may be selected based on a prioritized ranking so that only facilities having pertinent issues (e.g., unsuccessful authentications or breaches) are shown to Mark.

[00172] Mark, for example, may be an IT security specialist, and a visualization 404 may be provided wherein a map is provided having markers 406 and 408 indicative of various facilities, ranking the facilities by alerts. The size and color of markers 406 and 408 may be modified, for example. Facility "cards" 410, 412, and 414 show summary information for each facility, including a visualization widget indicative of overall activity at each facility.

[00173] FIG. 4B is similar to FIG. 4A, showing an alert / event widget bar where alerts are shown in portion 416 (individual alerts shown in 418), and events are shown in portion 420 (individual events shown in 422). The alert / event widget bar aids in tracking root cause of various breaches or other events (e.g., failed authentications that led to abandonment of a process, such as an online shopping cart).

[00174] FIG. 5A is another administrator dashboard view, according to some embodiments, where an administrator is able to view the individual access activity of various users. In this example, visualizations are provided on individual user cards 502, 504, 506, and 508, showing their access as tracked over a period of time. In some embodiments, only a portion of users are shown (e.g., automatically selected by the platform 100 as users requiring specific attention. In FIG. 5B, an alternate view is shown, wherein a summary list of authentications and events for various users is shown in the table 512. [00175] FIG. 6A is an administrator dashboard where the administrator is provided a view 602 of a specific user, according to some embodiments. The specific user view is shown in relation to modalities 606, 608, 610, 612, that exist on in relation to the user's profile account, and in some embodiments, the email, phone, profile picture, and/or other identifying information 604 can be synchronized (one way, or two-way synchronized) with a backend directory service (e.g., LDAP or Active Directory).

[00176] The modalities show examples of challenge mechanisms available to the platform 100, and as shown in this example, facial recognition, retinal recognition, fingerprint recognition are available, but physiological monitoring is not. The list of applications 614 is shown, along with user groups 616, and available devices 618. [00177] FIG. 6B is another administrator dashboard view, according to some embodiments, where an administrator is able to view the individual access activity of various facilities. Facilities 620 and 622 have additional visual elements overlaid representative of potential issues that need administrator attention at each of the facilities 620 and 622. [00178] FIGS. 7A, and 7B are further administrator dashboard views according to some embodiments, where an administrator is able to view the individual access activity of various facilities. FIG. 7A is a user-by-user view, FIG. 7B is an activity summary view.

[00179] FIG. 8 is a risk management administrator dashboard view, according to some embodiments. Risk management may be an administrator role-dependent view, where different elements are automatically prioritized based on defined desired outcomes for a particular administrator. In the view depicted, a security tracking administrator is able to quickly, at a glance, review policies 802, showing access information related to VPN access 804, a front door 806, remote access 808, and data center access 810, and further, is able to define new policies.

[00180] A slider bar 812 is provided where the administrator is able to indicate a risk level, and in some embodiments, the platform 100 is configured to automatically recommend or define a risk level by machine-interpreting the new policy parameters (e.g., what facilities does it cover, what types of access). In some embodiments, risk levels can be inherited or copied from existing policies. Challenge states 818, and corresponding actions may be provided, and specific authentication and modalities 816, and characteristics thereof may be identified 814. In some embodiments, the platform 100 automatically determines authentication challenge modalities and verification mechanisms automatically at the time of challenge request, based for example, on contextual factors of the challenge request, the modalities / mechanisms available to the user at the time (user is travelling in airport, only has access to mobile device, cannot use a secure token left behind in an office), among others. A side widget bar is provided in relation to alerts and events.

[00181] FIG. 9 is an administrator dashboard view directed to specific modalities and verification mechanisms, according to some embodiments. In FIG. 9, an overall trust level 902 associated with a modality or verification mechanism 904 can be shown, and a sidebar 906 is shown where testing results 908, technologies supported 910, and a summary 912 can be provided. In some embodiments, the testing results are used to tweak and tune the operation of the modality or verification mechanism, for example, modifying the level of trust associated with the modality or verification mechanism, or requiring additional modalities to be present when an identity challenge is invoked. [00182] FIG. 11A is an example block schematic of a computer-implemented platform architecture, according to some embodiments. Multiple vendor systems 1102, 1104, 1106, 1108 feed provide primary biometric match information to a data receiver 1110, which is configured as part of platform 100, which aggregates the biometric match information across one or more modalities in respect of biometric access challenge requests. A normalization engine 1112 is utilized to normalize modalities and scores based on quality of enrollment, vendor biases, and known false rejection / false acceptance scores associated with each of the vendors corresponding to vendor systems 1102, 1104, 1106, and 1008. The conversion engine 1114 generates a combined match score based on one or more primary authentication mechanisms, which may include various types of biometrics as shown in FIG. 1 D, other types of authentication mechanisms such as one-time use codes, among others. This information is provided to graphical user interface generation engine 1116.

[00183] FIG. 11 B is an example block schematic of the graphical user interface generation engine 1116, according to some embodiments. The graphical user interface generation engine 1116 is implemented using processors, including in some embodiments, specific graphics processors dedicated to generating one or more renderings of devices and movements thereof, as mapped to a simulated X,Y Cartesian surface, or in some embodiments, as shown in a simulated X, Y, Z, Euclidean space that is mapped to an X,Y Cartesian space. Other types of coordinate systems are possible, including, for example, radial coordinate systems, cylindrical coordinate systems, spherical coordinate systems, and other combinations of linearly independent vectors.

[00184] A primary authentication mechanism 1152 is configured to track a primary biometric input (or a combination of primary biometric inputs thereof, such as eyeprint and fingerprint), and resides on a user computing device associated with a specific user profile. The primary authentication mechanism 1152 resides on a mobile application operable on the user computing device, and the mobile application is invoked (e.g., opened) during the primary authentication. When the mobile application is invoked, raw sensory data is extracted from onboard circuitry, including, for example, a coupled gyroscope 1154, an accelerometer 1156, and a GPS location detection mechanism 1158. The raw sensory data is timestamped and stored in one or more memory arrays on the onboard circuitry, and tracked for a duration when the mobile application is invoked and when it is closed, or a portion of the duration thereof. In particular, timestamped data may be tracked in a time duration proximate to the use of the primary authentication mechanism.

[00185] In some embodiments, the raw data is processed to generate one or more angular motion vectors, one or more translational motion vectors, and/or one or more geolocation movement vectors, which are then associated with specific timestamped memory array buckets to generate frames of rotation, translation, or geolocation movement. In further embodiments, rates of change between specific timestamped raw data is utilized to extend the frames of rotation, translation, or geolocation movement. The onboard sensory movement data, raw or processed in various embodiments, is transmitted through network 1190 in relation to each access or authentication attempt through the mobile application.

[00186] In rendering an administrator interface to be displayed or to be controlled to be displayed on an administrator display device, graphical user interface generation engine 1116 includes a device rendering engine 1160, a 2D/3D graphics processor 1162, a rotation / translation engine 1164, and a data storage 1166. The device rendering engine 1160 is configured for generating one or more signals indicative of commands or controls or instruction sets that are adapted for rendering graphics on the administrator display device. The device rendering engine 1160, in some embodiments, controls the 2D/3D graphics processor 1162 in pre-processing the graphics or encapsulating the instruction sets. [00187] The interface generation engine 1160 receives control or command signals from the rotation / translation engine 1164, which processes the onboard sensory movement data in generating one or more rendering effects in relation to a centroid of the displayed rendering of the device rendering engine 1160 that indicate either a rotation effect or a translation effect to occur, which may include re-mapping of coordinates representing a simulated rendering of a device in 2D or 3D space in accordance with either vectorized movement of the centroid (in relation to translation), or modifications thereof of visual points of the rendering about the centroid (in relation to rotation), where one or more transformation matrices (e.g., rotational matrices) are applied in respect of rotation pairs or rotation triplets. In a three dimensional rendering simulated on a two dimensional screen, an additional step of flattening the three dimensional rendering is required to ensure that the two dimensional representation in Cartesian space is accurate in respect of the coordinate transformation in Euclidean space. In some embodiments, the the rotation / translation engine 1164 is configured to interpolate or extrapolate motion in respect of intermediate frames, for example, through application of approximation or curve-fitting approaches which are adapted to map the rotations or translations to simplified non-linear transformations thereof.

[00188] A match score generation engine 1168 is invoked to generate a match score based at least on the primary authentication mechanism 1152 outputs, for example, through an application programming interface with platform 100. The match score is received by the device rendering engine 1160 in respect of generating a visual effect that is proportionate (or inversely proportionate) to the match score. The matches may be compared against templates stored in template storage 1172, and match scores may be modified (e.g., by modifying weights thereof) based on tracked differences and deviations between different devices provided by different vendors, through processing of vendor normalization data sets by vendor modification engine 1170. The administrator display device includes input device controller and an event handler, which are utilized to receive inputs indicative of actions taken by the administrator.

[00189] The administrator may move a mouse, for example, to indicate profiles or authentication requests that the administrator would like to view in more detail. The renderings of the devices by device rendering engine 1160 may have effects provided modifying the base renderings in accordance with the match score. Based on the positioning of the mouse cursor, in accordance with various embodiments, a first selection event (e.g., mouse hover) is detected by the event handler and a secondary effect is rendered by device rendering engine 1160 showing the device moving either in accordance with a path (e.g., in a loop, the centroid of the rendered device moving across the path) or in a rotation (e.g., in a loop, the centroid remaining stationary while the rendered device rotates in accordance with a rotation in two or three dimensions).

[00190] Upon detection of a second selection event, a tertiary effect is rendered by device rendering engine 1160 showing the device moving either in accordance with a path (e.g., in a loop, the centroid of the rendered device moving across the path) or in a rotation (e.g., in a loop, the centroid remaining stationary while the rendered device rotates in accordance with a rotation in two or three dimensions).

[00191] In a preferred embodiment, the first selection event is a mouse hover and the second selection event is a mouse selection. In this embodiment, the first selection event triggers a first dynamic visual effect corresponding to the secondary biometric data, and the first dynamic visual effect is a looped rotation in respect of a centroid. The rotation includes rendered rotational arrows whose characteristics are modified responsive to a level of tracked deviation from tracked rotations in respect of successful access attempts by the specific user associated with the access request. The second selection event is a mouse selection proximate or on the rendering, which then triggers a second dynamic visual effect, which is a looped translation where the rendered device centroid is translated across a path in combination with the rotation about the centroid. The path includes a rendered pathway arrow whose characteristics are modified responsive to a level of tracked deviation from tracked movements in respect of successful access attempts by the specific user associated with the access request. Other embodiments are contemplated.

[00192] The administrator interface is rendered as a grid or list showing a series of flagged access attempts, and is designed for speedy and convenient review of a large volume of flagged access attempts. The administrator can, for each rendering, indicate whether the access attempt is likely fraudulent or authentic by way of visually inspecting the characteristics of the access request, for example, by way of inspecting the visual characteristics of the rendering (e.g., size, color, opacity), the secondary biometric, or the tertiary biometric. The administrator can use a secondary input interface (e.g., a keyboard), after selecting a rendering and press "Y" to mark it as authentic, or "N" to mark it as inauthentic, for example. The platform 100 includes a retraining mechanism that utilizes the markings recorded by the administrator to retune weightings associated with aspects of the access requests.

[00193] For example, the platform 100 could include a neural network having a series of computing nodes each indicative of a feature and having interconnections representing weights thereof, the marked records being utilized for re-training the neural network to update the weights associated with the interconnections in accordance with a reward and/or penalty mechanism to optimize an objective function. The neural network for example, is the internal reference model that is represented by the data matrix linking various trust levels, biometric modalities, levels of trust, user profiles, computing time, etc.

[00194] FIG. 12 is a graphical rendering of the administrative interface 1200, according to some embodiments. In generating this rendering, the platform 100 is a backend architecture through which the backend data is accessed and populated.

[00195] A database call is transmitted to the platform 100, based on a view that is exposed for a particular administrator. When an application for receiving a primary authentication is activated, the application initiates recording of data to start delivery of rotation data, movement data, among others. Rotation data and movement data can be obtained from accelerometers and gyroscopes, which are onboard. The sensors can be polled in intervals (e.g., based on an update frequency, set at 60 times a second), or data can be pulled (e.g., from a message bus). This data is captured and recorded to establish parameters which control how renderings are performed in respect of a secondary tracked aspect and/or a tertiary tracked aspect, such as rotation and a path).

[00196] A two or three dimensional rendering 1202 of the computing device during the time of biometric authentication provides a graphical preview of the way in which an end user interacts with the device when capturing biometric information. The rendering of the computing device has various modifiable graphical characteristics, including a size factor 1204, a length (which can be determined from the size factor), a width (which can be determined from the size factor), opacity (example renderings 1206 and 1208 are shown at different opacities than rendering 1202), a color, and a displayed position in a rendered 3D space (e.g., on a screen), among others. When rendered, aspects of the computing device are tracked and graphical elements are sized off of these aspects. For example, the computing device rendering in some embodiments is represented in the form of a centroid point (as a coordinate triplet (x,y,z) or a coordinate pair (x,y) 1210). The rendered computing device can be a placeholder, for example, rendered based off of a particular type of device used for the authentication (e.g., iPhone™, a tablet, a flip phone, a laptop, a handheld lock such as a Tapplock™). A type of primary authentication is shown in a visual element 1212. [00197] The size factor 1204, a length (which can be determined from the size factor), a width (which can be determined from the size factor), opacity (example renderings 1206 and 1208 are shown at different opacities than rendering 1202), a color (while different opacities are shown for 1206, 1208, and 1202, they may also be in different colors), and a displayed position in a rendered 3D space (e.g., on a screen) can be modified, in an embodiment, based on the match score.

[00198] The size factor 1204 in some embodiments is an inverse proportion of the match score relative to a perfect match score (e.g., f = perfect match / match score), which is then applied to the length and the width of the rendering (or depth if the rendering is 3D). Similarly, a color factor, an opacity factor, among others, can be applied. For a color factor, a percentage between color ranges of red to green can be utilized, and for an opacity factor, f can be utilized to modify the opacity of the rendering 1202.

[00199] A visual modification will modify the rendering responsive to the actual match score for the primary authentication mechanism. The modification may include re-sizing, a color change, an opacity change, etc.

[00200] In the example shown in FIG. 12, a resizing factor is applied based on the match score. The resizing factor f is inversely proportional to the quality of the match score. For example, if the match score indicates a high quality match, the rendering of the device is shown to be small relative to the other devices shown for other access requests. If the match score indicates a low quality match, the rendering is shown to be large relative to the other devices.

[00201] The resizing factor f can be also modified by a secondary resizing factor f2, which may be determined based on a vendor / device version profile of the primary authentication mechanism. For example, if a fingerprint reader Model A is provided by Company B, the match score may be more trustworthy than Model B provided by Company C. Accordingly, a trust matrix derived in some embodiments, based on a combination of the false acceptance rate and the false rejection rate, and used to derive an adjustment value for the resizing factor f2 indicative of a modified level of trust for the vendor / device version profile. Alternate embodiments include changing the color of the device from green (e.g., indicative of a high quality match), yellow (e.g., indicative of a lower quality match), and red (e.g., indicative of a failed match).

[00202] This graphical user interface 1200 along with rendering 1202 is adapted to visually assist the system administrators in ensuring proper enrollment and verification events. An improved decision support system having a specifically tuned visual interface is thus provided.

[00203] The visual renderings 1202 are modified in accordance with a primary authentication mechanism, a secondary authentication mechanism, and a tertiary authentication mechanism adapted to visually guide the administrator to visually view aspects of the primary, secondary, and tertiary authentication mechanisms simultaneously, near simultaneously, or responsive to the movement of an input, such as a mouse cursor 1216. The visual renderings 1202, for example, may also be utilized by the administrator to help explain to the end user how to better capture biometrics to avoid false rejection rates (e.g., bad match scores appear to occur when device is used at a poor angle. [00204] FIG. 13 is a graphical rendering of the administrative interface 1300, according to some embodiments, where a rendering 1202 is shown following a rotation 1302 indicative of an example tracked secondary biometric mechanism. In the example of FIG. 13, the rotation is rendered as rotating at a fixed position (e.g., set at the volumetric centroid) of the device, but not all embodiments are limited to the fixed position. In some embodiments, the backend system tracks the rotational events over the duration of time to generate an average-based template of rotational events tracked proximate to authentication events where a higher match score was obtained (e.g., more trustworthy authentication events).

[00205] In this embodiment, the primary biometric shown is a questionable fingerprint match (represented by visual component 1212), flagged for review by the system as the system is unable to achieve a sufficient match score for the authentication request (e.g., used for modifying size factor 1204).

[00206] The secondary biometric shown is a rotation 1302 that is tracked during a predefined duration of time proximate to the authentication request (e.g., +/- 3 s). The tracked movement may be obtained, for example, in the form of accelerometer data (e.g., in the form of changes in velocity in the x, y, and z axes) and/or gyroscopic data (an orientation in three dimensional space relative to a reference frame, an unbiased rotation rate, a gravity vector, an accelerator vector, and/or an magnetic field vector). The accelerometer data and the gyroscopic data are triggered by an activation of the sensory mechanisms (e.g., using Apple's CoreMotion SDK™), tracking motion and environment based data using on-board hardware of the devices.

[00207] These data points may be tracked, for example, through the use of a mobile application residing on the device that was utilized during the authentication request. The data may be obtained through one or more ordered n-tuples of data, which are processed to form one or more vectors based on the one or more rotation matrices. The n-tuples of data are organized into temporal frames based on timestamps of the datasets.

[00208] The device is first rendered as a placeholder image 1202 based off a mobile device type of the user. The rotation matrices are sequentially applied to modify the positional coordinates of the rendering in 2-D or 3-D space, graphically rotating the rendering in accordance with the volumetric centroid 1210 of the device shown in the interactive visual element.

[00209] The way in which an end user holds their device also ties back to their behavioural and contextual data. If a user normally holds the device at a 95 degree angle for a face verification, and an authentication event determines the device is being held at a vastly different angle, the system can flag the transaction and relay the information in a visual manner to the system administrator. Different biometric modalities require the end user to hold the device at different angles, heights, etc., depending on the biometric being captured. The device captures, in various embodiments, fingerprints, one-time use codes, passcodes, retinal scans, gait, etc.

[00210] A main biometric modality is utilized as a primary authentication mechanism, and the rendering shows secondary and tertiary characteristics visually as an improved aid for an administrator to help with reviewing borderline cases. [0021 1] The rendered device is rotated in accordance with the one or more vectors such that either a rotation 1202 during the actual authentication event is shown, in some embodiments (e.g., a static rotation is shown), or a dynamic rotational effect is shown in other embodiments. [00212] The dynamic rotational effect, for example, is based upon the tracked rotation during the duration of time, and the rendering is shown to be looping through the rotational effect. From the perspective of the administrator, the administrator observes the rendering 1202 sweeping through the rotation 1302 repeatedly, such that the primary authentication match score is observable by way of a scaling factor or other visual characteristic of rendering 1202, and the secondary biometric characteristic (rotation tracked during a duration proximate to the primary authentication event) is shown by way of the rotation 1302. The speed of rotation 1302, as described below, is modified through a velocity feature (ω, in terms of radians/second) of a rotation matrix applied to the coordinate groups of rendering 1202. [00213] To implement the rotational effect, a baseline orientation of the device is established. The baseline orientation may be based on either the orientation when the rotation tracking began, or in alternate embodiments, based on orientation at the time of access request, or based on a reference orientation, such as in relation to a reader, or to the ground. The visual interface element 1202 is rendered based on the baseline orientation (e.g., pointing downwards because the device is in the user's pocket).

[00214] The rotation matrices are generated based on raw gyroscope and/or accelerometer data, and applied to the coordinate positioning of the device, for example, rotating the rendering 1202 about centroid 1210. The rate of change captured in the each of the axes are used to modify the rate upon the rotation is rendered, ω. In some embodiments, the rotation rendered matches the relevant duration, and is a looped effect that is triggered during detection of the input 1216 being visually proximate, selecting, or hovering near rendering 1202. In other embodiments the rotation rendered is sped up and a time-shortened version of the relevant duration, and is also looped. Accordingly, an administrator is able to view multiple aspects of the secondary biometric (rotation of device) at once, including rotation, and angular velocity ω as determined by the tracked gyroscopic and accelerometer data.

[00215] A database call is adapted to selectively retrieve containers populated with biometric validation information associated with one or more access requests that are marked for review (e.g., by way of a Boolean flag, or stored on a stack or queue of flagged access requests, stored on a buffer that is periodically flushed when reviewed by the administrator). The flagged access requests are database objects which are tied to specific user profiles, either current user profiles, or point-in-time user profiles at the time or proximate to the time of the access requests. A stack is advantageous as a data structure where it is important to have more recent flagged requests reviewed first (e.g., where it is unlikely that the administrator will be able to review all requests). A queue is advantageous as a data structure where it the order of which the requests were made is more important (e.g., if the administrator is using the administrator console as a dynamic authentication step to approve / reject access requests in real-time, in accordance with one of the preferred embodiments). Other data structures are possible (e.g., linked-lists, arrays).

[00216] A data structure of flagged access requests includes each flagged access request as a separate object storing an profile identifier along with a container of biometric match information. To reduce data processing requirements at the edge computing device rendering the administrator interface, in some embodiments, the containers of biometric match information are pre-processed to only store pertinent information for the rendering of an interactive visual element 1206, as described below. This information is utilized to control graphical manipulation of the interactive visual element 1206.

[00217] In alternate embodiments, to reduce data processing requirements at a backend platform 100, the containers of biometric match information are provided as raw information, which an edge computing device then utilizes to generate and/or graphically manipulate a rendering.

[00218] Flagged access requests can be flagged for a variety of conditions and/or triggers. In a preferred embodiment, all requests with a match score below a first threshold are flagged for review. In another preferred embodiment, two pre-defined match scores are utilized, a first, higher level for flagged access, and a second, lower level for flagged rejection. The match scores are received as inputs and, where a plurality of biometrics and/or other verification mechanisms are utilized, represent a holistic level of confidence based on provided information that the user is who the user purports to be. The match scores may be adjusted based on a reliability metric (e.g., a ratings deviation level such as Glicko RD) based on a number and quality of informational samples for comparison.

[00219] In some embodiments, a number of high-confidence match scores are also included in the set of flagged access requests (e.g., randomly selected) to track administrator accuracy and attention to detail in view of access requests that are not likely to be falsified.

[00220] An example set of data is provided below as Table 1 in respect of example flagged access requests. Table 1 is a simplified set of data and meant to show a simplified example. Alternate, more complex approaches are contemplated and described below. However, these more complex approaches require greater computational resources. [00221] Each access request has a request #, a profile ID (which, in some embodiments, is anonymized so that an administrator is unable to check who the actual user is behind a particular access request), a tracked timestamp, a determination of whether access was actually granted or not at the time of provisioning (in the embodiment where the dashboard is being utilized in real-time to review pending access requests, all of the determinations will be in a pending state), an overall match score automatically derived from the backend system 100 based upon a computational review of all or a portion of all parameters provided at or proximate to the time of the access request.

[00222] In this example, the access information is tracked in the form of a primary authentication mechanism (e.g., fingerprint, voice-print, facial scan, retinal scan, dynamically generated barcodes), among others, along with secondary and tertiary tracked biometric aspects (e.g., rotation, path, as provided through gyroscopic data, accelerometer data, etc.). The secondary and tertiary access information itself is tracked using an application or other software / hardware residing on or coupled to an authentication device, and may be passively tracked, in some embodiments. [00223] The data set may include raw data, in some embodiments, or processed data (rotation matrices, vector translation path, and standard deviations and/or variances from prior rotation matrices and/or vector translation paths). The rotation matrices may be based on one or more reference rotational axes. The rotation matrices in addition to the vector translation paths may be utilized as a representation of the overall movement of the device in Euclidean space. Rotation and translation can be captured for a relevant duration. If the primary authentication occurs on an application, in some embodiments, the tracking occurs when the application is opened by the user for a relevant duration (e.g., 1 second before and 1 second after the access request). The application requests from a message bus gyroscopic and accelerometer information during the time in which it is open.

[00224] A frame of reference is utilized to establish the rotation matrices, and the angles may be tracked as sets of Euler angles derived from the gyroscope data. Euler angles used can be Euler angles or Tait-Bryan angles (e.g., yaw, pitch, roll). Rotations may thus be tracked in the form of triplet angles and vectors representing thereof, or matrices that can be applied directly to coordinate positions of rendering 1202 elements such that the matrices are be rotated in Euclidean space. For example, each graphical point of rendering 1202 is processed through the matrix to move to another point in the Euclidean space, which is then utilized in a model to generate a graphical representation of rendering 1202, showing a rotation effect in the simulated Euclidean space of the graphical user interface. [00225] The rotation matrices, in an embodiment, are simplified representations indicative of movements. In an example embodiment, a single rotation matrix is generated based on gyroscopic data captured at the beginning of a relevant duration and gyroscopic data captured at the end of the relevant duration. Additional dimensions may be generated based on a rate of change in each of the Euler angles, indicative of how quickly the device was rotated, etc.

[00226] In alternate embodiments, multiple rotation matrices are utilized representing one or more rotations during a relevant duration (e.g., compound rotations). For example, such rotation matrices are able to capture sequential rotations (1302 then 1304), such as hand tremors, complex movements (e.g., device was rotated clockwise 1302 and then counter- clockwise 1304 relative to the X-axis, in a simplified example, more complicated examples have rotations in multiple axes). In some embodiments, the number of rotation matrices generated are limited and can be segmented into one or more equally spaced time-frames during the relevant duration. The limitation allows for the conservation of processing resources, especially if a large number of renderings will ultimately be displayed. [00227] Each sequential rotation can be associated with a rotation speed in various axes, indicative of a rate of change of Euler angles between each beginning and ending data set for each of the segmented time-frames. Rotation matrices can be stored as vector-based data structures such as a multi-dimensional array. Multiple rotations may be indicative of a type of behavior. In some embodiments, the rotation speed that is detected is scaled either faster or slow to allow the administrator to view subtle differences. A slider or other interface element may also be provided to speed up or slow down rotations or other movements. To capture the rotation speed, a new dimension is added to the rotation matrix indicative of a rate of rotation. Each compound rotation is associated with a separate rate of rotation (in a simplified example, a rotation right at 30 degrees / second followed by a rotation left at 45 degrees / second.

[00228] Similarly, a path is generated from the accelerometer data captured during the relevant duration. The path is based on tracked frames of movement, generated based on tracked accelerometer readings (e.g., acceleration / g-forces encountered by the device in 2- 3 reference axes). [00229] In a first example embodiment, the path is a single Euclidean vector generated based off of the movement as captured between the start of the relevant duration and the end of the relevant duration. This approach is simple to process and while it yields a path, the path is a simplified, straight line path. For example, raw g-force data can be extracted from the mobile device and converted into movement in respect of a reference frame by determining a change in velocity and corresponding change in position. The change in g- force data between the start of the relevant duration and the end of the relevant duration is utilized to generate the single Euclidean vector of this example. The acceleration and velocity of movement between frames is tracked and stored, for example, as additional dimensions on the vector. [00230] In alternate example embodiment, multiple vectors are generated at different snapshots of times within the relevant duration. Each vector may represent a straight line path, and when combined, provide a more complex path showing sequential movements (for example, a straight-line movement from 0.1s to 0.2s, another movement from 0.2s to 0.3s, etc. The acceleration and velocity of movement between frames is tracked and stored and can change from vector to vector.

[00231] In yet another alternate example embodiment, the g-force data and changes thereof between frames are utilized to map the movement to curves of best fit (e.g., curve fitting). To conserve processing resources, curves of best fit are determined based on simplified degrees of freedom. For example, the number of degrees in polynomial interpolation may be pre-defined or limited.

[00232] In another embodiment, the number of degrees is dynamic based on a sensed processor load and/or available memory on the graphic controller rendering the movement in relation to a visual interface element. Accordingly, more complex paths can be shown in relation to

[00233] Table 1 :

105673 00302 23:12 12 FALSE Face Scan (0 degrees, 0 (12, -5, -3)

2018-04- degrees, -180

03 100 degrees) (left handed)

(upside down?)

166887 00405 09:15 45 FALSE Dynamic (-30 degrees, (4.6, 1 .7, -0.6)

2018-04- barcode 27.5 degrees,

03 15 degrees)

100

[00234] As shown in Table 1 , the tracked secondary and tertiary biometric data can be illustrative of an access request being more trustworthy or less trustworthy. The administrative interface is adapted to aid a human reviewer easily view the secondary and/or tertiary biometric aspects in an interactive graphical rendering of a visual element.

[00235] For example, the secondary biometric data can indicate that the device was held upside down, pulled from a lower position (e.g., a pocket), used by a left handed user, used by a right handed user, etc. In a further embodiment, tracked prior access requests are utilized in determining a standard deviation or a variance from an average or a median approach path / rotation, the standard deviation or variance tiered such that different amounts of standard deviations or variance trigger different modifications of the rendering. In some embodiments, the rotation 1302 is also depicted graphically in the form of a dashed line rotation arrow that is rendered, and visual characteristics of the dashed line rotation arrow are modified in respect of the standard deviation or variance. [00236] The administrative interface is a console interface that provides a snap-shot view 1200, which brings together, in one or more summary windows, a limited list of flagged biometric access requests retrieved from the backend platform 100. For each flagged access requests, an individual interactive visual element 1202 is controlled that may provide additional information responsive to an event handler determining that the administrator's inputs 1216 correspond to a selection or action proximate to the interactive visual element 1202. [00237] For example, inputs 1216 may be provided in the form of a mouse selection (x, y coordinate pair), a mouse hover (x, y coordinate pair and hover duration), and proximity may be determined by way of a determined graphical radius around each interactive visual element. [00238] The interactive visual element 1202 is a two or three dimensional rendering of an authentication device (e.g., a smart phone) that is/was proximate to, or used during the authentication event. For example, a smart phone may have an application residing thereon or components residing thereon which track, in addition to providing a primary authentication mechanism (e.g., fingerprint reader, face scanner, voiceprint scanner, retinal scanner), secondary and tertiary biometric authentication data sets (e.g., gait, device orientation, pathway through 3-D space), among others. The application may, while being opened and used for the primary authentication, record gyroscope, accelerometer, or GPS location data.

[00239] In an alternate embodiment, the secondary or tertiary biometric information is GPS location data, and similar to the examples below in respect of the path, a GPS path can be shown indicative of the user's movements for a period of time prior to or after the access request. However, for GPS location data, the application needs to be configured to track GPS location sets for a longer duration of time (e.g., when the user left home to travel to his/her workplace). Other data sets for secondary or tertiary biometric information include device ID, IP addresses, operating system versions, authentication patterns, and/or presence detection.

[00240] Pagination and other approaches may be utilized to conserve resources to avoid unnecessarily generating renderings, movement or rotational matrices for access requests that are not currently being displayed on the administrative console. As the number of identities secured in an account, say an enterprise versus a mom-and-pop shop the system dynamically renders only the amount of data necessary (i.e., high risk access requests, event failures, etc.) to ensure fast computing and to not overwhelm the user with information. For example, pagination and intelligent loading. Edge computing is also enabled to allow for analytics and knowledge generation to occur at the source of the data (the end user's device) as not to overwhelm the system and reduce the number of computational pulls required, only the necessary data sets relevant to the administrator console and its users ever actually come in contact with the service.

[00241] In further embodiments, where there are multiple options for secondary or tertiary biometric information to be displayed, the administrator console is configured to select a most relevant type of information to be shown to the user through the renderings, for example, based on a most clicked on portion of a report, pages visited, most commonly run reports, etc.

[00242] FIG. 14 is a graphical rendering of the administrative interface 1400, according to some embodiments, where a rendering is shown following a path 1402 indicative of an example tracked secondary biometric mechanism.

[00243] Similar to the above example, a pathway in 3D-space 1402 is tracked based on the accelerometer data (e.g., in the form of changes in velocity in the x, y, and z axes) and/or gyroscopic data (an orientation in three dimensional space relative to a reference frame, an unbiased rotation rate, a gravity vector, an accelerator vector, and/or an magnetic field vector). In this example, there are three frames extracted from the data, for example, v1 , v2, and v3. These frames of data are utilized to render the translation effect with respect to rendering 1202. Rendering 1202 has a centroid 1210 which graphically moves along the path 1402.

[00244] The pathway can be depicted in various methods, such as through one or more rendered arrows or lines 1402 (straight line or curved) showing the path the device moved during the relevant time period. In some embodiments, 1402 is only represented in the form of visual movement of rendering 1202 and not rendered as a separate graphical element.

[00245] The pathway of some embodiments is a single straight line vector path. In other embodiments, multiple straight line vector paths are shown as tracked during segments of the relevant duration. In further embodiments, curved paths are shown based on curve- fitting interpolations between tracked n-tuples of positional data. In the example shown in FIG. 14, a complex pathway 1402 is shown, consisting of two curves, but other curves can be generated. [00246] The curve fitting, for example, is based on different degrees of polynomial interpolation, and the number of degrees of interpolation can be pre-defined, dynamic, or modified based on the an interactive slider on the administrative console. As a simplified example, each frame may be fit using a curve that fits it to a curve based on y=ax+b, y = ax ^A 2 + bx+c, and so on. Each additional degree of fitting leads to more computational resources being utilized, so in some embodiments, the number of degrees is set at 3, 4, or 5. A simplified approach is to utilize a series of polynomial curves with two degrees.

[00247] Dynamic approaches to reducing the number of degrees of curve fitting are possible, based on CPU and memory availability. If a large number of renderings are generated at once, in a further example, if the tracked CPU availability decreases below 50%, the degree of curve fitting is iteratively reduced until the tracked CPU availability remains above 50%.

[00248] In some embodiments, the path includes both a translation effect being rendered along with a rotational effect being rendered. In these embodiments, the rendering is shown travelling across the path 1402 (e.g., using the volumetric centroid 1210 to follow the path) and rotations are rendered based on the volumetric centroid and one or more reference axes.

[00249] FIG. 15 is a graphical rendering of the administrative interface 1500, according to some embodiments, where a rendering is shown following a path and showing a rotation indicative of an example tracked secondary biometric mechanism. In this view, the input 1216 is tracked and a rotational effect 1302 / 1304 and a translational effect 1402 can be rendered.

[00250] To conserve computing resources, the rendering is shown having the secondary and tertiary biometric information causing rendering changes only when a selection or other input trigger is recognized (e.g., hover over) as indicating of a selection of a particular rendering associated with a request.

[00251] Responsive to the trigger or activation event, the visual element is then rendered and controlled to illustrate the rotational and pathway effects as described in relation to FIGS. 13-15. In some embodiments, aspects of the raw or processed data is shown in textual form alongside the rendering, for example, in a pop-over window.

[00252] FIG. 10 is a schematic diagram of computing device 1000, exemplary of an embodiment. As depicted, computing device includes at least one processor 1002, memory 1004, at least one I/O interface 1006, and at least one network interface 1008.

[00253] Each processor 1002 may be, for example, microprocessors or microcontrollers, a digital signal processing (DSP) processor, an integrated circuit, a field programmable gate array (FPGA), a reconfigurable processor, a programmable read-only memory (PROM), or combinations thereof. Processors are be used to implement the various logical and computing units of the system, as shown in FIG. 1 , for example, and different units may have different processors, or may be implemented using the same set of processors or the same processor.

[00254] Memory 1004 may include a suitable combination of computer memory that is located either internally or externally such as, for example, random-access memory (RAM), read-only memory (ROM), compact disc read-only memory (CDROM), electro-optical memory, magneto-optical memory, erasable programmable read-only memory (EPROM), and electrically-erasable programmable read-only memory (EEPROM), Ferroelectric RAM (FRAM). Memory 1004 may be used to store verification information, hashes thereof, among others. [00255] Each I/O interface 1006 enables computing device 1000 to interconnect with one or more input devices, such as a keyboard, mouse, camera, touch screen and a microphone, or with one or more output devices such as a display screen and a speaker. I/O interfaces 1006 can include command line interfaces. These I/O interfaces 1006 can be utilized to interact with the system, for example, to provide inputs, conduct inquiries, respond to identity challenges, etc.

[00256] Each network interface 1008 enables computing device 1000 to communicate with other components, to exchange data with other components, to access and connect to network resources, to serve applications, and perform other computing applications by connecting to a network (or multiple networks) capable of carrying data including the Internet, Ethernet, plain old telephone service (POTS) line, public switch telephone network (PSTN), integrated services digital network (ISDN), digital subscriber line (DSL), coaxial cable, fiber optics, satellite, mobile, wireless (e.g. Wi-Fi, WiMAX), SS7 signaling network, fixed line, local area network, wide area network, and others, including combinations of these. Network interfaces 1008 are utilized, for example, to interact with various applications, receive inputs from biometric applications, external tracking systems, etc.

[00257] The computing device 1000, in some embodiments, is a special purpose rack mounted appliance that is designed to be integrated into a security infrastructure data center, where it connects with a message bus and facility access or virtual access management computer systems. The computing device 1000 is electronically coupled to security devices, including physical access sensors and mechanisms (e.g., fingerprint readers, facial scanners, mobile applications connected to mobile devices having fingerprint readers, facial scanners, accelerometers, gyroscopes, GPS, etc.), and virtual security mechanisms (e.g., active directories, certificate servers).

[00258] Program code is applied to input data to perform the functions described herein and to generate output information. The output information is applied to one or more output devices. In some embodiments, the communication interface may be a network communication interface. In embodiments in which elements may be combined, the communication interface may be a software communication interface, such as those for inter-process communication. In still other embodiments, there may be a combination of communication interfaces implemented as hardware, software, and combination thereof.

[00259] Throughout the foregoing discussion, numerous references will be made regarding servers, services, interfaces, portals, platforms, or other systems formed from computing devices. It should be appreciated that the use of such terms is deemed to represent one or more computing devices having at least one processor configured to execute software instructions stored on a computer readable tangible, non-transitory medium. For example, a server can include one or more computers operating as a web server, database server, or other type of computer server in a manner to fulfill described roles, responsibilities, or functions. [00260] The technical solution of embodiments may be in the form of a software product. The software product may be stored in a non-volatile or non-transitory storage medium, which can be a compact disk read-only memory (CD-ROM), a USB flash disk, or a removable hard disk. The software product includes a number of instructions that enable a computer device (personal computer, server, or network device) to execute the methods provided by the embodiments.

[00261] The embodiments described herein are implemented by physical computer hardware, including computing devices, servers, receivers, transmitters, processors, memory, displays, and networks. The embodiments described herein provide useful physical machines and particularly configured computer hardware arrangements.

[00262] Although the embodiments have been described in detail, it should be understood that various changes, substitutions and alterations can be made herein.

[00263] Moreover, the scope of the present application is not intended to be limited to the particular embodiments of the process, machine, manufacture, composition of matter, means, methods and steps described in the specification.

[00264] As can be understood, the examples described above and illustrated are intended to be exemplary only.