WO2019089636A1

WO2019089636A1 - Biometric user authentication for online session using mobile device

Info

Publication number: WO2019089636A1
Application number: PCT/US2018/058268
Authority: WO
Inventors: William Christopher SUMMERLIN; David Michael WESTERHOFF; Timothy Chiheng CO
Original assignee: PINN Technologies
Priority date: 2017-10-31
Filing date: 2018-10-30
Publication date: 2019-05-09

Abstract

Methods and systems for authenticating a user's identity for a third party online session on a terminal include the following steps: (i) receiving a request from the third party to authenticate the online session on the terminal; (ii) requesting user to verify the online session and biometrically authenticate user identity via a trusted user device; (iii) receiving requested session verification and user authentication from the trusted user device; and (iv) authenticating the user to the third party for the online session.

Description

BIOMETRIC USER AUTHENTICATION FOR ONLINE SESSION

USING MOBILE DEVICE

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to Provisional Application No. 62/579,553, filed on October 31 , 2017, the entire contents of which are incorporated herein by reference.

BACKGROUND

Conventional security for online accounts typically involves logging on to one's account with a username and a password. Two-factor logon provides additional security by requiring further user authentication by issuing a code to the user via previously-established contact method, such as by sending a SMS to the user's mobile phone or sending the user an e-mail. Both conventional and two-factor logons are susceptible to hacking if the hacker has access to the user's email account or mobile phone, for example.

SUMMARY

In general, in a first aspect, the invention features methods for authenticating a user's identity for a third party online session on a terminal. The method includes the following steps: (i) receiving a request from the third party to authenticate the online session on the terminal; (ii) requesting user to verify the online session and biometrically authenticate user identity via a trusted user device; (iii) receiving requested session verification and user authentication from the trusted user device; and (iv) authenticating the user to the third party for the online session.

In general, in a further aspect, the invention features methods for authenticating a user's identity for a third party online session on a terminal that includes requesting the online session from the third party on the terminal and verifying the online session and biometrically authenticating user identity via a trusted user device.

In general, in another aspect, the invention features systems for authenticating a user's identity for a third party online session on a terminal. The systems include a device configured to receive a request to verify online session and biometrically authenticate user identity on terminal, collect user biometric authentication data, collect session verification data, and transmit the user authentication data and session verification data uniquely associated with the device. The systems further include a server in communication with the device, the server configured to receive the user authentication data and session verification data from the device, and authenticate user identity to the third party for the online session.

Among other advantages, implementations of the technology may allow for secure biometric user authentication during an online session. Because biometric information is used for authentication, illicit logons and subsequent compromise of a user's account can be substantially reduced, if not entirely eliminated.

The disclosed technology can be deployed without requiring a user to acquire custom hardware. For instance, secure online account access can be achieved using the sensors and transmitters on a user's mobile phone, which are ubiquitous in today's society and often uniquely associated with the device's owner.

The disclosed technology can prevent replay attacks (i.e., where a valid data transmission is maliciously or fraudulently repeated or delayed). For example, binding a user and their device with a cryptographic key for a specific online session ensures that the unique combination of both the user and the device will be able to authenticate the user's identity and verify the online session. Devices that have not been registered or bound to given users will not be able to authenticate against another's biometrics due to asymmetric key hashing.

The details of one or more implementations of the subject matter of this disclosure are set forth in the accompanying drawings and the description below. Other features, aspects, and advantages of the subject matter will become apparent from the description, the drawings, and the claims.

DESCRIPTION OF DRAWINGS

FIG. 1 is a schematic diagram of an embodiment of a system for authenticating a user's identity for a third party online session on a terminal.

FIG. 2 is a flowchart showing steps in the operation of the system shown in FIG. 1.

FIG. 3 is a flowchart showing steps in exemplary session verification processes using various session keys.

FIG. 4 is an exemplary terminal screenshot of a third party online session logon screen.

FIG. 5 is an exemplary terminal screenshot of a trusted identity provider

authentication website. FIG. 6A is an exemplary terminal screenshot of a first authentication step in a trusted identity provider authentication flow.

FIG. 6B is an exemplary device screenshot of a first authentication step in a trusted identity provider authentication flow.

FIG. 7 A is an exemplary terminal screenshot of a second authentication step in a trusted identity provider authentication flow.

FIG. 7B is an exemplary device screenshot of a second authentication step in a trusted identity provider authentication flow.

FIG. 8 is an exemplary device screenshot of an error message during the second authentication step in a trusted identity provider authentication flow.

FIG. 9A is an exemplary terminal screenshot of a confirmation of successful authentication in a trusted identity provider authentication flow.

FIG. 9B is an exemplary device screenshot of a confirmation of successful authentication in a trusted identity provider authentication flow.

FIG. 10 is an exemplary terminal screenshot of a third party website where user is redirected after successful authentication by the trusted identity provider.

FIG. 1 1 is a schematic diagram of an example computer system.

Like reference numbers and designations in the various drawings indicate like elements.

DETAILED DESCRIPTION

Referring to FIG. 1 , a system 100 for authenticating a user's identity for a third party online session on a terminal 105 includes a third party server 145, a trusted identity provider ("TidP") authentication server 140, a terminal 105 (e.g., laptop or desktop computer) and a mobile device 115. Here, the third party refers to an entity that is different from a user 101 and the TidP who provides authentication server 140. Generally, user 101 will maintain a secure online account with the third party. Common examples of third parties include financial institutions, government institutions, education institutions, health care providers, entertainment streaming services, and online retailers, among others. With system 100, user 101 logs on to their account in an online session with third party server 145 through a public network 135 (e.g., the internet).

Mobile device 115 is a mobile phone or any other personal networked device (e.g., networked wirelessly or wired) uniquely associated with user 101 and capable of communicating with TidP server 140 in collecting and transmitting user information (e.g., biometric information) related to authenticating the user's identity and verifying the online session. User biometrics can be collected with the device's biometrics module 125. In implementations, only mobile devices that are pre-registered by user 101 on TidP server 140 can be used to authenticate the user's identity and verify the online session. Un-registered devices and/or devices uniquely bound to a different user will not be able to verify the session.

Referring also to FIG. 2, an exemplary process 200 of authenticating the user's identity for the third party online session using system 100 is shown. In step 210, user 101 requests an online session with third party server 145, using terminal 105, through public network 135. For example, the user can request an online session with a financial institution by attempting to log into the user's bank account on a laptop. Third party server 145 prompts TidP server 140, through a backdoor connection 155, to authenticate the user's identity for the online session in step 220.

TidP server 140 requests user 101 to verify the online session and authenticate the user's identity using user's device 115 in step 230. The request may be displayed to user 101 as part of the third party's login flow, by maintaining a synchronous connection with TidP authentication server 140. For example, the bank website itself can display the request. Alternatively, or additionally, user 101 may be directed to a TidP login flow for verification and authentication. For example, the bank website can redirect user 101 to a TidP interface on terminal 105.

Step 230 also includes TidP server 140 generating an encoded session key that uniquely identifies the online session requested by user 101. TidP server 140 transmits the key to terminal 105. The key can contain information such as the identity of the third party and the time of the session request. The key can be encoded in various forms, for example, as an encrypted image, an audiovisual signal, or a data packet.

For session verification, terminal 105 needs to successfully communicate the key with user device 115. In step 240, user 101 detects the key generated by terminal 105 with device 115 and sends it to TidP server 140 to verify the session. For example, for an encrypted image session key, the user can take a picture of the key (e.g., QR code) shown on the terminal display with the device's camera. For an audio key (e.g., audible or inaudible sounds), the user can record the sounds with the device's microphone. For identity authentication, user 101 inputs authentication data (or authentication user information) using the device's biometrics module 125. Authentication data can include the user's biometrics, as well as other information, such as the user's e-mail address, their phone number, or a password previously established with TidP server 140. In step 240, device 115 sends that biometric and other authentication data to TidP server 140 over secure connection 130. In some embodiments, device 115 can verify user identity by comparing it to previously stored biometrics and transmit only a confirmation token to TidP server 140.

Upon receipt of session verification and user identity authentication information, TidP server 140 can authenticate user 101 to third party 145 for the online session on terminal 105 in step 250. The third party can then allow user 101 to continue the online session on the terminal. For example, the user's logon to their bank account via their laptop is completed, and the user is allowed to fully access their account information.

Device 1 15 can authenticate user identity to TidP server 140 by using biometrics module 125. Biometrics module 125 allows device 115 to collect user biometrics and other authentication information to authenticate user identity. TidP server 140 can determine whether the collected biometrics and authentication information match those of user 101 enrolled on a secure TidP network 150 through the associated user device 1 15. If the biometrics and other authentication information of user 101 match those of the enrolled user, and device 1 15 is a device registered on TidP network 150 for that user, TidP server 140 can authenticate user identity. The details of the secure enrollment process and how the network is secured are provided in Provisional Application No. 62/551,651 , entitled "System for Secure Network Enrollment," filed on 8/29/2017, and in International Application No.

PCT/US2018/048515, entitled "SYSTEM FOR SECURE NETWORK ENROLLMENT," filed August 29, 2018, the contents both of which are incorporated herein by reference in their entirety.

Biometrics can be collected while user 101 interacts with device 1 15 (e.g., using device camera, display, keyboard, and/or and touch panel). Biometric data includes biometric identifiers that are distinctive, measurable characteristics used to label and describe individuals. Biometric identifiers can be categorized as physiological versus behavioral characteristics. Physiological characteristics are related to the shape of the body. Examples include, but are not limited to, fingerprint, palm veins, face recognition, DNA, palm print, hand geometry, iris recognition, retina and odor/scent. Behavioral characteristics are related to the pattern of behavior of a person, including but not limited to typing rhythm, gait, and voice.

Biometrics module 125 can use the device camera, display and keypad or touch panel, to measure biometric data. Device 1 15 may have other cameras and sensors for gathering images (still and video), microphones and other sensors for gathering audio data (e.g., speech data), IR cameras and other thermal image sensors, accelerometers for measuring gait, computer mouse (e.g., for gathering data on scrolling, moving, clicking), trackpads (e.g., scrolling and swiping), keyboards, keypads, and touchscreens.

Depending on the available sensors and the user interface, device 1 15 may be configured to include a facial recognition module (e.g., 2D image facial recognition, 3D image facial recognition), a hand geometry module, a keystroke dynamics module, a speech recognition module, a mouse motion module, a video analysis module (e.g., for gait detection), an audio analysis module (e.g., voice recognition modules, both text dependent and text independent modules), an accelerometer data analysis module (e.g., for gait detection), a language analysis module, a heartbeat module, a driving behavior module, a fingerprint module, an iris module, a foot shape/pressure module, an ear biometric module, an operator signature module, a thermal signature module, a device fingerprint module (e.g., for mobile devices, cars, computers, etc. ; see, e.g., https://audiofingerprint.openwpm.com), a network forensics module, a license plate recognition (LPR) module (e.g., fixed or cascade), a driving behavior module, an audio signature module (e.g., for detecting the audio signature of a car), an NFC module, a fixed low energy wireless module, and a cascade low energy wireless module.

Device 1 15 has a secure connection 130 with TidP server 140. A secure connection can ensure that data exchange between device 115 and TidP server 140 is not compromised. Secure connection 130 can be provided by the device's secure hardware security module ("HSM"), which is part of biometrics module 125. The HSM is an integrated circuit capable of providing basic computing functions, and is configured to encrypt and securely store (and/or transmit) biometric data, run various types of instructions stored in the storage medium, and provide a secure interface between TidP server 140 and device 1 15. The HSM is a physical computing component (e.g., a SIM card or other integrated circuit) that safeguards and manages digital security keys for strong authentication and provides cryptoprocessing, which includes functionality such as security key generation (also called cryptographic key generation), encryption, decryption, and secure key storage. More information about the operation of the HSM is provided in Provisional Application No.

62/551,651 and in International Application No. PCT/US2018/048515.

Device 1 15 also includes a mobile verification module 120 that allows device 115 to communicate with terminal 105 in verifying the user's online session to TidP server 140. Mobile verification module 120 includes all software, firmware, and hardware necessary to interact with terminal 105 in verifying the online session. An online session can be verified by placing device 115 is in physical proximity to terminal 105 and recording some unique signal (e.g., session key) corresponding to the online session generated by terminal 105. For example, device 115 can be used to take a picture of an encoded session key code displayed by terminal 105 (e.g., a Quick Response Code ("QR code")). Alternatively, or additionally, device 115 can communicate with terminal 105 via a local Wi-Fi network, and/or via another wireless communication technology (e.g., Bluetooth, NFC), and detect the terminal's encoded session key through data exchange over the wireless connection. A hard wire connection between terminal 105 and device 1 15 can also be used (e.g., via a USB or other cable connection). Alternatively, or additionally, device 115 can record the session key through audiovisual signals generated by terminal 105 (e.g., flashing lights displayed on the terminal's screen, or audible or inaudible sound waves generated by the terminal's loudspeakers).

Terminal 105 includes a terminal verification module 1 10 that receives the session key generated by TidP server 140 and communicates the encoded session key to device 115. Module 1 10 includes all software, firmware and hardware that allows for the encoded session key to be communicated to device 1 15. Module 1 10 can be built into the terminal or can be a separate drive coupled to the terminal. For session keys that are images, module 110 can prompt the terminal to display the key. For data packet keys, the module can be configured to generate a local wireless signal (e.g., over Wi-Fi, Bluetooth, or NFC), to detect the presence of device 1 15 in this local network, and to send the packet to the device's mobile verification module 120 over that network. For audiovisual signals (e.g., lights or sounds), module 1 10 can prompt terminal 105 to generate such signals.

TidP server 140 can also communicate with terminal verification module 1 10 to direct terminal 105 to display a request to user 101 to verify the online session and to authenticate the user's identity over the trusted device. For example, the request can include an explanatory diagram demonstrating how verification and authentication can be accomplished. For instance, for authentication, the request can explain which biometric information should be collected using device 1 15. For verification, the request can provide instructions on how to use device 115 to capture the session key (e.g., take picture of visual session key, etc.).

Also referring to FIG. 3, various exemplary session verification processes using different types of session keys are shown. In step 310, user 101 requests an online session on a third party website via desktop terminal 105. In response, in step 320, third party server 145 directs user 101 to TidP server 140. TidP server 140 issues a session key to terminal 105 in step 330. TidP server 140 requests user 101 to verify the session using the session key and to authenticate identity via user's trusted mobile device in step 340. For example, TidP server 140 can direct terminal verification module 1 10 to display the request to user 101 on terminal 105.

The request to verify the session depends on the type of session key. For an image session key, user 101 is instructed to take a picture of the key (e.g., QR code) displayed on terminal 105. For a data packet key, user 101 is instructed to bring device 1 15 (e.g., a phone) into the range of the short-range wireless signal (e.g., Bluetooth, Wi-Fi, or NFC) generated by terminal 105 (e.g., a laptop). The range depends on the type of network signal. For example, the proximity for NFC data exchange can be on the order of 4 cm. For an audiovisual key (e.g., light flashes displayed by laptop screen, or audible or inaudible sounds), user 101 is instructed on how to record such signals.

In step 350, user 101 can authenticate the user's identity to TidP server 140 by inputting biometric data into device 115. For example, if the TidP authentication request specifies that the user's fingerprint and photo is required, user 101 would use the device's camera and touch sensors to input such authentication information into the phone. Device 115 can securely transmit the authentication information, or confirmation of a biometrics match, to TidP server 140 over secure connection 130.

Session verification steps 360-362 can vary depending on which type of session key is used to verify the online session. For an image session key, terminal 105 is directed by terminal verification module 110 to display the session key on terminal 105 in step 360(1). To verify the session, user 101 takes a picture of the session key displayed on terminal 105 with device 1 15 in step 362(1).

If the session key is a data packet, user 101 brings device 115 within a proximity (as specified in the verification request) of the terminal in step 360(2). When terminal verification module 110 detects the device's proximity, module 1 10 generates the data packet in 362(2). For an audiovisual signal session key, user 101 positions device 115 to record the signal as instructed in the verification request 360(3). For example, if the signal is an inaudible sound wave, user 101 is instructed to bring device 115 close enough to terminal 105 for device 115 to detect such a sound. If the signal is flashing lights displayed on terminal 105, then user 101 is instructed to record the lights with the device's camera. Terminal verification module 110 directs terminal 105 to generate the audiovisual signal in step 362(3). In certain embodiments, User 101 needs to provide module 110 with an indication that device 115 is ready (e.g., appropriately positioned) to record the signal. In certain embodiments, module 110 can detect that device 115 is ready automatically. For example, module 110 may be equipped with a proximity sensor that can detect whether device is close enough to record the inaudible sound wave signal.

After the session key is recorded by device 115, device 115 transmits the session key to TidP server 140 to verify the session in step 370. When TidP server 140 has received both the user's authentication data and session verification, TidP server 140 can authenticate the user's identity to the third party for the online session in step 380. The third party can then allow user 101 access to the session.

In general, although FIG. 3 shows the use of only a single type of session key, TidP server 140 can generate a combination of session keys for additional security. For example, TidP server 140 can generate an image session key and a data packet key. In that case, user 101 would have to take a picture of the image session key and bring device 115 in proximity to terminal 105 to gather the data packet key.

One or more of the aforementioned embodiments contemplate the use of a session key for session verification. Alternatively, or additionally, TidP server 140 may verify the session by a push method, an example of which is shown in FIGS. 4-10. For instance, user 101 can request an online session on terminal 105 with a third party on a third party website logon page. FIG. 4 shows an example screenshot 400 of a third party website logon page. User 101 may select to login to the website using their TidP account by inputting their username 410 and password 420 and selecting the option to sign in using a TidP sign in link 430 on the screen.

In other embodiments, the third party website logon page does not require username 410 and password 420 and user 101 may select to login to the website using their TidP account by selecting the option to sign in using TidP sign in link 430 on the screen. TidP server 140 can authenticate user 101 to the third party without user 101 specifying username 410 and password 420 for the third party website logon page.

Upon selecting to sign in using TidP sign in link 430, the third party can redirect user 101 to a TidP website on terminal 105. The TidP website can push a request to authenticate the user's identity to the user's device 115. The pushed request alone can contain sufficient information about the third party session to verify the online session. Thus, by having user 101 authenticate their identity on the device from a pushed request, TidP server 140 can both verify the session and authenticate user 101. TidP server 140 can then authenticate the user to the third party for that online session.

FIG. 5 shows an exemplary screenshot 500 of a TidP website displayed on terminal 105 after the third party redirect. The website shows a progress bar 510 that indicates the progress of the authentication flow. A status text 520 verbally describes the current step in the authentication flow. Directions 530 provide additional instructions to user 101 about how to complete the current authentication flow step. A Device image 540 shows an image of what is being displayed on user's device 115, which has received a push request from the TidP server.

As a first step in the authentication process, user 101 is asked whether they agree to go through the TidP authentication process. FIGS. 6A-B show exemplary screenshots of the TidP website on a terminal 600 and a user's device 601 for the first step in the authentication flow. A status text 610 indicates that the first step in the flow is to accept the request to go through the TidP authentication process. Directions 620 explain that the user needs to select an "accept" button 630 on the TidP website displayed on device 601 to progress through the flow.

User 101 is then requested to enter authentication information, such as a password, phone number, and/or biometrics. FIGS. 7A-B are exemplary screenshots on a terminal 700 and a device 701 of this second authentication step in a trusted identity provider

authentication flow. A status text 710 indicates that the second step in the flow is to enter a password. Directions 720 explain that user 101 needs to enter a password using a device's keypad 730 to progress through the flow. While user 101 is entering their password, device 701 also collects biometrics. For example, the device's camera can be used to take an image of the user's face, as indicated by an icon 740. If biometrics cannot be properly collected by device 701, an error message can be displayed on device 701. For example, FIG. 8 shows an exemplary device screenshot 800 of an error message 810 that can be displayed during the second authentication step in a TidP authentication flow. Error message 810 can provide instructions about how to position device 701 to accurately collect biometrics.

If user identity is properly authenticated after inputting authentication information, successful authentication confirmation is displayed on both the TidP website and device. FIGS. 9A-B are exemplary screenshots on a terminal 900 and a device 901 confirming successful authentication in a TidP authentication flow. Upon successful authentication with device 901, TidP server 140 authenticates user 101 to the third party for that online session. The TidP website redirects back to the third party online session, where user 101 is allowed to fully access their third party account. FIG. 10 is an exemplary terminal screenshot 1000 of a third party website where user 101 is redirected after successful authentication by TidP server 140.

In some embodiments, the entire authentication process is accomplished entirely by the user's interaction with their mobile device. The terminal simply mirrors actions, verified or unverified, taken on the mobile device in real time.

FIG. 11 is a schematic diagram of an example computer system 1100. The system 1100 can be used to carry out the operations described in association the implementations described previously. In some implementations, computing systems and devices and the functional operations described above can be implemented in digital electronic circuitry, in tangibly-embodied computer software or firmware, in computer hardware, including the structures disclosed in this specification (e.g., system 1100) and their structural equivalents, or in combinations of one or more of them. The system 1100 is intended to include various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers, including vehicles installed on base units or pod units of modular vehicles. The system 1100 can also include mobile devices, such as personal digital assistants, cellular telephones, smartphones, and other similar computing devices. Additionally, the system can include portable storage media, such as, Universal Serial Bus (USB) flash drives. For example, the USB flash drives may store operating systems and other applications. The USB flash drives can include input/output components, such as a wireless transmitter or USB connector that may be inserted into a USB port of another computing device.

The system 1100 includes a processor 1110, a memory 1120, a storage device 1130, and an input/output device 1140. Each of the components 1110, 1120, 1130, and 1140 are interconnected using a system bus 1150. The processor 1110 is capable of processing instructions for execution within the system 1100. The processor may be designed using any of a number of architectures. For example, the processor 1110 may be a CISC (Complex Instruction Set Computers) processor, a RISC (Reduced Instruction Set Computer) processor, or a MISC (Minimal Instruction Set Computer) processor.

In one implementation, the processor 1110 is a single-threaded processor. In another implementation, the processor 1110 is a multi -threaded processor. The processor 1110 is capable of processing instructions stored in the memory 1120 or on the storage device 1130 to display graphical information for a user interface on the input/output device 1140.

The memory 1120 stores information within the system 1100. In one implementation, the memory 1120 is a computer-readable medium. In one implementation, the memory 1120 is a volatile memory unit. In another implementation, the memory 1120 is a non-volatile memory unit.

The storage device 1130 is capable of providing mass storage for the system 1100. In one implementation, the storage device 1130 is a computer-readable medium. In various different implementations, the storage device 1130 may be a floppy disk device, a hard disk device, an optical disk device, or a tape device.

The input/output device 1140 provides input/output operations for the system 1100. In one implementation, the input/output device 1140 includes a keyboard and/or pointing device. In another implementation, the input/output device 1140 includes a display unit for displaying graphical user interfaces.

The features described can be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. The apparatus can be implemented in a computer program product tangibly embodied in an information carrier, e.g., in a machine-readable storage device for execution by a programmable processor; and method steps can be performed by a programmable processor executing a program of instructions to perform functions of the described implementations by operating on input data and generating output. The described features can be implemented advantageously in one or more computer programs that are executable on a programmable system including at least one programmable processor coupled to receive data and instructions from, and to transmit data and instructions to, a data storage system, at least one input device, and at least one output device. A computer program is a set of instructions that can be used, directly or indirectly, in a computer to perform a certain activity or bring about a certain result. A computer program can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

Suitable processors for the execution of a program of instructions include, by way of example, both general and special purpose microprocessors, and the sole processor or one of multiple processors of any kind of computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a processor for executing instructions and one or more memories for storing instructions and data. Generally, a computer will also include, or be operatively coupled to communicate with, one or more mass storage devices for storing data files; such devices include magnetic disks, such as internal hard disks and removable disks; magneto- optical disks; and optical disks. Storage devices suitable for tangibly embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, ASICs (application-specific integrated circuits).

To provide for interaction with a user, the features can be implemented on a computer having a display device such as a CRT (cathode ray tube) or LCD (liquid crystal display) monitor for displaying information to the user and a keyboard and a pointing device such as a mouse or a trackball by which the user can provide input to the computer. Additionally, such activities can be implemented via touchscreen flat-panel displays and other appropriate mechanisms.

The features can be implemented in a computer system that includes a back-end component, such as a data server, or that includes a middleware component, such as an application server or an Internet server, or that includes a front-end component, such as a client computer having a graphical user interface or an Internet browser, or any combination of them. The components of the system can be connected by any form or medium of digital data communication such as a communication network. Examples of communication networks include a local area network ("LAN"), a wide area network ("WAN"), peer-to-peer networks (having ad-hoc or static members), grid computing infrastructures, and the Internet.

The computer system can include clients and servers. A client and server are generally remote from each other and typically interact through a network, such as the described one. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.

While this specification contains many specific implementation details, these should not be construed as limitations on the scope of any inventions or of what may be claimed, but rather as descriptions of features specific to particular implementations of particular inventions. Certain features that are described in this specification in the context of separate implementations can also be implemented in combination in a single implementation.

Conversely, various features that are described in the context of a single implementation can also be implemented in multiple implementations separately or in any suitable

subcombination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the

implementations described above should not be understood as requiring such separation in all implementations, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

Thus, particular implementations of the subject matter have been described. Other implementations are within the scope of the following claims. In some cases, the actions recited in the claims can be performed in a different order and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In certain implementations, multitasking and parallel processing may be advantageous.

Claims

What is claimed is:

1. A method for authenticating a user's identity for a third party online session on a terminal, comprising:

receiving a request from the third party to authenticate the online session on the terminal; requesting user to verify the online session and biometrically authenticate user identity via a trusted user device;

receiving requested session verification and user authentication from the trusted user device; and

authenticating the user to the third party for the online session.

2. The method of claim 1 , wherein the trusted user device is a mobile device.

3. The method of claim 1, further comprising the steps of:

requesting the user to input biometric data into the trusted user device;

receiving, by the trusted user device, the biometric data from the user; and storing the biometric data as user authentication.

4. The method of claim 1 , wherein the biometric data comprises one or more biometric identifiers associated with the user's identity.

5. The method of claim 4, wherein one or more of the biometric identifiers associated with the user's identity are physiological biometric identifiers.

6. The method of claim 4, wherein one or more of the biometric identifiers associated with the user's identity are behavioral biometric identifiers.

7. The method of claim 1, wherein the step of authenticating the user to the third party for the online session comprises:

determining whether the requested session verification and user authentication from the trusted user device is received from a device pre-registered to the user; and

in response, authenticating the user to the third party for the online session.

8. A method for authenticating a user's identity for a third party online session on a terminal, comprising:

requesting the online session from third party on the terminal; and

verifying the online session and biometrically authenticating user identity via a trusted user device.

9. The method of claim 8, wherein the step of verifying the online session and biometrically authenticating user identity via a trusted user device comprises:

displaying an audiovisual session key on the terminal; and

recording the audiovisual key, using the trusted user device.

10. The method of claim 8, wherein the step of verifying the online session and biometrically authenticating user identity via a trusted user device comprises:

positioning the trusted user device in proximity of the terminal; and

transmitting a data packet key from the terminal to the trusted user device.

11. A system for authenticating a user's identity for a third party online session on a terminal, comprising:

a device configured to:

receive a request to verify online session and biometrically authenticate the user identity on a terminal;

collect user biometric authentication data;

collect session verification data; and

transmit the user biometric authentication data and session verification data uniquely associated with the device; and

a server in communication with the device, the server configured to:

receive the user biometric authentication data and session verification data from the device; and

authenticate the user identity to the third party for the online session.

12. The system of claim 1 1, wherein the terminal is configured to:

mirror actions taken by the device, in real time.

13. The system of claim 1 1, wherein the device is a mobile device.

14. The system of claim 11, wherein the user biometric authentication data comprises one or more biometric identifiers associated with the user's identity.

15. The system of claim 14, wherein the one or more of the biometric identifiers associated with the user's identity are physiological biometric identifiers.

16. The system of claim 14, wherein the one or more of the biometric identifiers associated with the user's identity are behavioral biometric identifiers.

17. The system of claim 14, wherein one or more of the biometric identifiers associated with the user's identity are behavior biometric identifiers and one or more biometric identifiers associated with the user's identity are physiological biometric identifiers.

18. The system of claim 11, wherein the server is further configured to:

generate one or more session keys associated with the online session.

19. The system of claim 18, wherein the terminal comprises a terminal verification module configured to:

receive the session key; and

direct the terminal to display the request to the user.

20. The system of claim 11, wherein the device comprises a hardware security module configured to:

encrypt user biometric authentication data;

store user biometric authentication data; and

connect the device with the server via a secure connection.