Identity confirmation during authentication requests using nearby mobile computing devices

There are provided systems and methods for identity confirmation during authentication requests using nearby devices. A device and/or service provider may detect an authentication request, including one for device process or a service provider interaction. In response to the request, the device may scan for nearby devices over short range wireless communications and identify one or more devices that are close to the device. An identity confirmation request may be generated, which may include a picture of a user that should be performing the authentication, such as a user owning the device or account that is being accessed. The request may be transmitted to the nearby devices to require that users of the nearby devices can identify that user and utilizing the device to process the authentication request. This may include using facial recognition to image the user by the other devices.

TECHNICAL FIELD

The present application generally relates to authentication through mobile computing devices, and more specifically to using short range wireless communications to confirm user identity during device authentication processing through mobile computing devices.

BACKGROUND

Users may utilize various computing devices, such as tablet computers, mobile smart phones, and wearable computing devices, to perform computing functions while the user is mobile. For example, users may wish to perform payment processes using mobile devices, which may include electronic transaction processing for purchase with merchants and/or transfers to other users. However, computing devices, and especially mobile devices may be susceptible to fraudulent use and access by unauthorized users. Service providers may institute various types of authentication mechanisms to reduce fraud, but bad actors may still be capable of determining authentication credentials and accessing account or sensitive data, including through remote login actions. This is due to the remote nature of an online service provider from the location of requested authentication and access request by a device, where the service provider is not able to confirm an identity of the user. Thus, service providers may run an increased risk of fraud and loss due to malicious actions that may circumvent authentication mechanisms and precautions with mobile computing devices.

DETAILED DESCRIPTION

Provided are methods utilized for identity confirmation during authentication requests using nearby computing devices. Systems suitable for practicing methods of the present disclosure are also provided.

A computing device and/or service provider may receive an access and/or authentication request, where a user's identity, authentication credentials, and/or other information may be required to be confirmed before the user is authenticated and provided access to an electronic account or content. For example, a user may attempt to access or login to an account with an online service provider, such as an email, messaging, social networking, and/or payment and transaction processing account. The user may also wish to perform an action with the online service provider, including paying for a transaction using a payment account with the service provider, viewing sensitive information, or changing account credentials. The device may be utilized by a user to perform various electronic transaction processing processes, including shopping, purchase, user transfers, and other user or merchant transactions. The communication device may therefore include one or more software processes to perform the aforementioned actions, which may be included with one or more applications executing on the communication device. The service provider may require completing an authentication mechanism to provide the requested access. In other embodiments, the device may have an authentication mechanism to provide access and/or use of the device, such as an unlocking mechanism to unlock and use the device, an application opening or usage authentication requirement, and/or an authentication mechanism to make changes to device parameters, information, or credentials (e.g., a password change). The device may also provide access to a physical location, such as an electronic lock of a door, location, safe, or vehicle.

In response to the requested access, the device or service provider may output an authentication request that requires the user to enter in credentials (e.g., a username, password, and/or personal identification number (PIN)). The device or service provider may determine that identity confirmation of the user using the device needs to be performed, where the identity confirmation is to confirm that the user using the device is the user that is associated with the requested access, such as the account, the owner of the device, or a valid other user that has access to the account, device, or resource. The identity confirmation requirement may be to confirm user identification as using the device to respond to the authentication request and challenge, and therefore is the user that is validly requesting the access and may be provided to access without risking virtual fraud, theft, or misappropriation through the device. In some embodiments, the identity confirmation may be required where the device is attempting use or login with the service provider or to the device in a new or foreign location, at an unusual time, or in an unusual set of events or circumstances. However, in other embodiments, the device/service provider may provide increased security through instituting the identity confirmation for all logins or access requests or the owner of the device/account may require the identity confirmation to provide the increased security.

In order to confirm an identity of the user using the device to respond to the authentication request, the device and/or service provider may determine other nearby devices to the device. In some embodiments, a first device processing the authentication request may perform a short range wireless scan of nearby devices, for example through Bluetooth, Bluetooth Low Energy (BLE), Long-Term Evolution (LTE) Direct, near field communications (NFC), or other short range wireless protocol that allows for device-to-device communications and identification of nearby devices. For example, the first device may ping for nearby devices that may respond with identification of the nearby devices, or may emit an identifier that causes the nearby devices to communicate with the first device. In some embodiments, the first device and/or the service provider may identify the nearby devices by determining a geo-location of the first device and performing geo-location matching with other devices within a proximity to the first device's geo-location, such as within a geo-fence established around or nearby the first device's geo-location, where the geo-fence may change based on various factors such as density of other user computing devices in the area, e.g., a denser concentration may result in a smaller geo-fence. The first device and/or the service provider may identify at least one other nearby device, such as a second device, to request the identity confirmation of the user using the first device.

In some embodiments, the second device(s) may be selected based on one or more parameters. In some embodiments, the first device and/or service provider may select the second device(s) based on a closest detected device, such as closest geo-locations or nearby devices detected as the closest through triangulation or received signal strength indicator (RSSI) measurements with the devices communicating over short range wireless communications. These devices may be selected to provide a best unimpeded view of the user using the first device for identity confirmation. In other embodiments, the device or service provider may select the second device(s) based on known contacts and/or social connects (e.g., through a social network platform, messaging, contact list, device interactions, transaction histories, etc.) of the user associated with the first device, account, or other resource being accessed through the authentication request. The second device may also be selected based on an account with the service provider, for example, if the devices share an account or interact between two or more accounts. The first device and/or service provider may also select a plurality of devices to provide additional security in the identity confirmation and thereby provide better authentication mechanisms to prevent fraud.

The first device or service provider may generate a message having an identity confirmation request for transmission to the selected nearby device(s) once identified. The message may include an image of the first user or other identifying characteristics of the user that is the owner or valid associated user of the device/account/resource, such as a description of appearance, dress, or known items in possession of the user. Other information may also be provided, such as a name, license plate of a vehicle for the user, or other identifier that may be used to visually and/or through speech identify the user and confirm the identity of the user using the first device as the correct party. In some embodiments where the device or account may be shared by multiple users, multiple images or user identifying descriptions may be provided. The message may also include a request to confirm the user's identity, such as a message that states “Do you see [this user] within your vicinity?” or “Please confirm you can see [this user].” The message may include a responsive interface element to provide confirmation of denial of the presence of the user, or the message may be returned with a message or comments that confirm or deny the presence (e.g., a text message back that states “Yes” or “No”). The message may be formatted as a text message, push notification for an application, banner message, or other message that may be displayable on the selected second device(s).

In some embodiments, the message may include further requests. For example, the message may request that one or more other users for the second device(s) capture an image of the user using the first device and transmit that image back to the device or service provider. Thus, the image may include a process to access a camera and capture an image of the user, which may include a camera viewfinder interface. The message may also request that the other user(s) point the second device(s) at the user using the first device if identified. This may assist in triangulation of a position of the first device and location matching of the triangulated position of the first device to a known geo-location of the first device. Thus, the message may also or instead include a process to access compass, mapping, accelerometers, gyroscopes, or other movement detection sensors on the second device(s) to assist in capturing data for triangulation. The message may then be sent to the second device(s) through short range wireless communications, for example, by pushing the message from the first device to the second device(s), or may be sent over network connections with the second device by the service provider.

The first device and/or the service provider may receive a response over the short range wireless communications or network connection(s) with the second device(s). The first device or service provider may then perform identity confirmation using the response. Where an identification request requires only an affirmative response or other reply (e.g., “Yes” or “No” to whether the user can be seen), the first device or service provider may confirm the identity using the responsive data, text, or selection. However, where an image is provided with the response, image matching, facial recognition, or other image processing may be used to determine whether the correct user is recognized as using the first device. In some embodiments, triangulation data may be received where multiple second devices are pointed towards the user when requested to identify the user. Such data may also be captured when the second devices capture images of the user. The first device or service provider may utilize signal and/or location triangulation to determine a location that the second devices are pointing, and may determine whether the triangulated position matches the geo-location of the first device detected using a location detection component and/or short range wireless communications of the first device.

In some embodiments, a score may be calculated to determine whether the user's identity can be confirmed, such as if enough of the detected data is sufficient to meet a threshold score or value to proceed with authentication of the user on the first device. For example, in order to proceed with electronic transaction processing, the service provider may calculate a risk in proceeding with the transaction based on the identity data detected of the user using the first device. The risk assessment or level may be determined for how risky the transaction is to complete based on the identity data. Thus, the risk level may indicate the potential fraud in the transaction and whether there is fraud or risk of loss in proceeding with the transaction by authenticating the user using the first device. Risk factors for the risk assessment or risk level may include amount of funds in the account for use in completing the transaction (e.g., if there are sufficient funds), a number of reversed or fraudulent past transactions including those during device failure, a length of account ownership or since opening, available payment instruments for the account, a number or amount of transactions, an amount of the transaction, a comparison of the amount to past transactions, a location of the transaction, a time of the transaction, participants in the transaction and whether there are past connections or transactions between the participants (e.g., if the user of the failed device and the target of the transaction are friends or family and known each other), or other factor that may indicate potential risk. If there is an unacceptable level of risk, such as if the risk level exceeds a threshold level or number, then the service provider may not proceed with the authentication of the user and may mark the transaction as failed. One or more other nearby devices may then be requested to confirm the identity of the user to proceed with the authentication and transaction, and the user's identity may be retested. In some embodiments, the device and/or user using the device may be flagged for potential fraud and locked out of the device, account, or other resource if the identity cannot be verified.

If there the user can be accurately identified, the device and/or service provider may confirm the identity of the user and proceed with authentication if the authentication credentials are correct. Thus, if there is no risk in the authentication or the risk is at an acceptable level (e.g., below a threshold amount), the user may be permitted the requested access and/or perform the process requested by the user (e.g., electronic transaction processing). Additionally, if the identity may be confirmed, then the parameter or data that enabled the identity confirmation (e.g., the new location or unusual time request) may be added to stored data so that identity confirmation may not be required in the future for similar situations. The user may also be associated with the device for a time period so that the user may perform additional actions without requiring identity confirmation and/or authentication.

As previously discussed, the online service provider may provide account services to users of the online service provider, as well as other entities requesting additional services, which may be used to process electronic transactions during device operation, as discussed herein. A user wishing to establish the account may first access the online service provider and request establishment of an account. The account may be established by providing account details, such as a login, password (or other authentication credential, such as a biometric fingerprint, retinal scan, etc.), and account creation details. The account creation details may include identification information to establish the account, such as personal information for a user, business or merchant information for an entity, or other types of identification information including a name, address, and/or other information. The user may also be required to provide financial information, including payment card (e.g., credit/debit card) information, bank account information, gift card information, benefits/incentives, and/or financial investments, which may be used to process transactions after identity confirmation. In order to create an account, the user may be required to select an account name and/or provide authentication credentials, such as a password, personal identification number (PIN), answers to security questions, and/or other authentication information. A token may be issued to the device of the user for their respective personal account, where the token may include data (which may be encrypted) allowing the service provider to identify the user and their account and authenticate the user. Additionally, the online payment provider or other service provider may provide digital wallet services, which may offer financial services to send, store, and receive money, process financial instruments, and/or provide transaction histories. The application or website of the service provider, such as PayPal® or other online payment provider, may provide payments and the other transaction processing services.

In this manner, a device and/or service provider may provide increased security for digital access requests, such as account usages, device processes, and/or data processing, by leveraging the short range wireless communication capabilities over the device to detect nearby devices. This helps prevent bad actors from compromising devices or accounts when utilizing stolen credentials. Thus, authentication mechanism may be made more robust to reduce digital fraud and misappropriation and increase security when utilizing devices for authentication with a remote device/server over a network.

System100includes a first user device110, a second user device120, and a service provider server130in communication over a network150. A first user (not shown) may utilize first user device110to request authentication, such as to access first user device110and/or a service provided by service provider server130. First user device110and/or service provider server130may determine that the authentication request requires identity confirmation of the first user using first user device110being the authorized user for the authentication request. Second user device120may be identified as being within a proximity distance or range of first user device110so that a second user (not shown) may identify first user device110. Second user device120may receive a request to identify the first user, and based on a response, the first user's identity may be confirmed or denied.

First user device110may be implemented as a communication device that may utilize appropriate hardware and software configured for wired and/or wireless communication with second user device120and/or service provider server130. For example, in one embodiment, first user device110may be implemented as a personal computer (PC), a smart phone, laptop/tablet computer, wristwatch with appropriate computer hardware resources, eyeglasses with appropriate computer hardware (e.g. GOOGLE GLASS®), other type of wearable computing device, implantable communication devices, and/or other types of computing devices capable of transmitting and/or receiving data, such as an IPAD® from APPLE®. Although only one communication device is shown, a plurality of communication devices may function similarly.

First user device110ofFIG. 1contains an authentication application112, other applications114, a database116, and a communication module118. Authentication application112and other applications114may correspond to executable processes, procedures, and/or applications with associated hardware. In other embodiments, first user device110may include additional or different modules having specialized hardware and/or software as required.

Authentication application112may correspond to one or more processes to execute modules and associated devices of first user device110to receive an access request, which requires authentication of a user using first user device110, and authenticate the user based on the user's identity being confirmed as a valid user using first user device110based on an identity confirmation request sent to second user device120. In this regard, authentication application112may correspond to specialized hardware and/or software utilized by first user device110to first receive or generate an authentication request, for example, in response a request to access a virtual or real item, account, object, location, or another thing, such as unlocking first user device110, executing a process on first user device110, accessing an account or other resource with service provider server130, and/or utilizing the account/resource. The access request may be generated through use of authentication application112or through another application of first user device110, such one or more of other applications114. In other embodiments, the access request may occur through a real-world interaction by the user, based on an access permission granted by another user, or through a request to use a service of service provider server130. Authentication application112may correspond to a general browser application configured to retrieve, present, and communicate information over the Internet (e.g., utilize resources on the World Wide Web) or a private network. For example, authentication application112may provide a web browser, which may send and receive information over network150, including retrieving website information, presenting the website information to the user, and/or communicating information to the website. However, in other embodiments, authentication application112may include a dedicated application of service provider server130or other entity (e.g., payment provider, etc.), which may be configured to provide services through the application.

Thus, authentication application112may receive input corresponding to the access request, which may include authentication credentials or other input that requests use of a process, account, or service. In response to the access request, authentication application112and/or service provider server130may determine that an identity of the user using first user device110may be required to be validated and confirmed as an authorized used for the access request. Authentication application112may perform a scan, such as through Bluetooth, Bluetooth Low Energy, radio, infrared, WiFi, near field communications, LTE Direct, or other short range communication protocol, to determine that second user device110is within range of first user device110. Authentication application112may also display a list of eligible verification users within range to first user device110within an interface and allow the user to select one of the eligible verification users. This may be displayed based on prior authentications and/or verifications performed by the eligible verification users and/or connections between first user device110and/or the user with the eligible users. Thus, the user may select one of the devices, such as second user device120, through the interface for the verification of the user's identity. In other embodiments, second user device120may be detected as being within proximity to first user device110using geo-locations and/or geo-fencing. In response to determining that second user device120is within proximity to first user device110, an identity confirmation request may be transmitted to second user device120, such as by first user device110using the short range wireless communication protocol. The request may correspond to a message having an image of the authorized user associated with the access request. The request may therefore ask a user using second user device120to determine whether they can identify the authorized user in proximity to them. If the user using second user device120affirmatively identifies the user, such as the user using first user device110, then authentication application112may receive confirmation of the identity, and may provide the requested access to the device, process, account, and/or service. However, if the identity cannot be confirmed, authentication application112may deny the requested access.

Authentication application112may further include processes used to perform electronic transaction processing for a payment or a transfer. During processing of a payment or transfer transaction, authentication application112may be utilized to select payment instrument(s) for use in providing payment for a purchase transaction, transfer, or other financial process. As discussed herein, authentication application112may utilize user financial information, such as a credit card, bank account, or other financial account, as a payment instrument when providing payment information. Additionally, authentication application112may utilize a digital wallet stored with an account with a payment provider, such as service provider server130, as the payment instrument, for example, through accessing a digital wallet or account of a user with service provider server130through entry of authentication credentials and/or by providing a data token that allows for processing using the account. Authentication application112may utilize a digital token for the payment account, digital wallet, and/or payment instruments by providing the digital token to authenticate the user and/or use the user's payment account, digital wallet, and/or payment instruments, which may be encrypted and/or provided through a secure channel, to a transaction participant to authenticate the account, digital wallet, and/or payment instruments to service provider server130and allow for transaction processing and payment using the account, digital wallet, and/or payment instruments. Authentication application112may also receive transaction data elements, including a recipient (e.g., an identifier associated with second communication device110) and a transaction amount. Authentication application112may be utilized to view the results of payment, for example, using transaction histories, dispute resolution processes, and other post-transaction process.

In various embodiments, first user device110includes other applications114as may be desired in particular embodiments to provide features to first user device110. For example, other applications114may include security applications for implementing client-side security features, programmatic client applications for interfacing with appropriate application programming interfaces (APIs) over network150, or other types of applications. Other applications114may also include additional communication applications, such as email, texting, voice, and IM applications that allow a user to send and receive emails, calls, texts, and other notifications through network150. In various embodiments, other applications114may include financial applications, such as banking, online payments, money transfer, or other applications. Other applications114may also include other location detection applications, such as a mapping, compass, and/or GPS application, which may be used to determine a location for the user that is communicated to service provider server130. Other applications may include social networking applications and/or merchant applications. Other applications114may include device interfaces and other display modules that may receive input and/or output information. For example, other applications114may contain software programs, executable by a processor, including a graphical user interface (GUI) configured to provide an interface to the user.

First user device110may further include database116stored in a transitory and/or non-transitory memory of first user device110, which may store various applications and data and be utilized during execution of various modules of first user device110. Thus, database116may include, for example, identifiers (IDs) such as operating system registry entries, cookies associated with authentication application112and/or other applications114, IDs associated with hardware of first user device110, or other appropriate IDs, such as IDs used for payment/user/device authentication or identification. Database116may include an access request, entered authentication credentials (e.g., a username/password), a message that may be transmitted to second user device120, and/or an identity confirmation result.

First user device110includes at least one communication module118adapted to communicate with second user device120and/or service provider server130. In various embodiments, communication module118may include a DSL (e.g., Digital Subscriber Line) modem, a PSTN (Public Switched Telephone Network) modem, an Ethernet device, a broadband device, a satellite device and/or various other types of wired and/or wireless network communication devices including microwave, radio frequency, infrared, Bluetooth, and near field communication devices.

Second user device120may be implemented as a communication device that may utilize appropriate hardware and software configured for wired and/or wireless communication with first user device110and/or service provider server130. For example, in one embodiment, second user device120may be implemented as a personal computer (PC), a smart phone, laptop/tablet computer, wristwatch with appropriate computer hardware resources, eyeglasses with appropriate computer hardware (e.g., GOOGLE GLASS®), other type of wearable computing device, implantable communication devices, and/or other types of computing devices capable of transmitting and/or receiving data, such as an IPAD® from APPLE®. Although only one communication device is shown, a plurality of communication devices may function similarly.

Second user device120ofFIG. 1contains an identity confirmation application122, other applications124, a database126, and a communication module138. Identity confirmation application122and other applications124may correspond to executable processes, procedures, and/or applications with associated hardware. In other embodiments, second user device120may include additional or different modules having specialized hardware and/or software as required.

Identity confirmation application122may correspond to one or more processes to execute modules and associated devices of second user device120to confirm an identity of a user using first user device120in response to an identity confirmation request. In this regard, identity confirmation application122may correspond to specialized hardware and/or software utilized by second user device120to first receive a short range wireless communication, such as a ping or device presence request, from first user device110that identifies second user device120as in proximity to first user device110. In other embodiments, identity confirmation application122may provide a geo-location of second user device120that may be used to determine that second user device120is in proximity to first user device110. After first user device110and/or service provider server130determine that second user device120is nearby to first user device110, a message to confirm an identity of a user using first user device110may be transmitted to second user device120and processed by identity confirmation application122.

The message may include an image of the user that is associated with the requested access on first user device110, such as an owner or authorized user of first user device110and/or an account or service provided by service provider server130. Identity confirmation application122may output the user image with a request to confirm that the user can be seen. The message may also request that a user using second user device120capture an image or video of the user shown in the message's image if that user can be identified and/or point second user device120in the direction of the user. In this regard, identity confirmation application122may be used to capture an image and/or device directional data (e.g., a line of sight, compass direction, etc.). Identity confirmation application122may receive input from the user and/or detected data by second user device120in response to the message, and may transmit the input and/or data to first user device110and/or service provider server130for processing to determine an identity of the user using first user device110.

In various embodiments, second user device120includes other applications124as may be desired in particular embodiments to provide features to second user device120. For example, other applications124may include security applications for implementing client-side security features, programmatic client applications for interfacing with appropriate application programming interfaces (APIs) over network150, or other types of applications. Other applications124may also include additional communication applications, such as email, texting, voice and IM applications that allow a user to send and receive emails, calls, texts, and other notifications through network150. Other applications124may also include other location detection applications, such as a mapping, compass, and/or GPS application, which may be used to determine a location for second user device120. Other applications124may include device interfaces and other display modules that may receive input and/or output information. For example, other applications124may contain software programs, executable by a processor, including a graphical user interface (GUI) configured to provide an interface to the user.

Second user device120may further include database126stored in a transitory and/or non-transitory memory of second user device120, which may store various applications and data and be utilized during execution of various modules of second user device120. Thus, database126may include, for example, identifiers (IDs) such as operating system registry entries, cookies associated with identity confirmation application122and/or other applications124, IDs associated with hardware of second user device120, or other appropriate IDs, such as IDs used for payment/user/device authentication or identification. Database126may include a received identity confirmation message, as well as input (e.g., confirmation of the user's identity) and/or data captured in response to the message.

Second user device120includes at least one communication module138adapted to communicate with first user device110and/or service provider server130. In various embodiments, communication module138may include a DSL (e.g., Digital Subscriber Line) modem, a PSTN (Public Switched Telephone Network) modem, an Ethernet device, a broadband device, a satellite device and/or various other types of wired and/or wireless network communication devices including microwave, radio frequency, infrared, Bluetooth, and near field communication devices.

Service provider server130may be maintained, for example, by an online service provider, which may provide leased device services for the first user associated with first user device110and the second user associated with second user device120. In this regard, service provider server130includes one or more processing applications which may be configured to interact with first user device110, second user device120, and/or another device/server to facilitate authenticating users and/or devices for use of one or more accounts and/or services provided by a service provider. In one example, service provider server130may be provided by PAYPAL®, Inc. of San Jose, Calif., USA. However, in other embodiments, service provider server130may be maintained by or include a financial service provider, social networking service, email or messaging service, media sharing service, and/or other service provider, which may provide authentication services requiring identity confirmation, for example, for the use of an account.

Service provider server130ofFIG. 1includes an authentication processing application140, a transaction processing application132, other applications134, a database136, and a network interface component138. Authentication processing application140, transaction processing application132, and other applications134may correspond to executable processes, procedures, and/or applications with associated hardware. In other embodiments, service provider server130may include additional or different modules having specialized hardware and/or software as required.

Authentication processing application140may correspond to one or more processes to execute modules and associated specialized hardware of service provider server130to authenticate a user using first user device110in response to an access request, where the authentication occurs based on confirming the user's identity through a message transmitted to second user device120. In this regard, authentication processing application140may correspond to specialized hardware and/or software to receive an access request, and in response to the access request, determine that the user using first user device110requires their identity to be confirmed as a valid or authorized user for giving access to a device, account, and/or service based on the request. Authentication processing application140may determine that the identity is required to be confirmed based on the parameters of the access request, such as the location, time, or transaction details (e.g., amount, items, etc.). In some embodiments, authentication processing application140may determine second user device120is in proximity to first user device110by requesting a scan of nearby devices through short range communications by first user device110and/or detecting geo-locations of first user device110and second user device120. Thus, authentication processing application140may provide one or more of the processes discussed in reference to authentication application112on first user device110, and vice versa.

In some embodiments, authentication processing application140may generate a message for second user device120to confirm the identity or presence of a valid user using first user device110. The message may include an image of the user that may be taken from database136and/or data associated with an account of the user. The message may be pushed to second user device120through first user device110, or may be transmitted to second user device120over network150. In response to the message, authentication processing application140may receive identity confirmation or denial data from first user device110and/or second user device120, which may include a response to whether the user using second user device120was capable of identifying the user in the message's image. The response data may further include an image, which may be processed using facial recognition to determine whether the user is identified. Additionally, location and/or directional data may be provided, which may be used with other directional data to perform location triangulation of the location of where the user in the image was identified. Authentication processing application140may determine whether that triangulated location matches a geo-location of first user device110. If the user can be confirmed as utilizing first user device110during the authentication request, the user's identity may be confirmed and authentication processing application140may provide the requested access, service, and/or other process that required the authentication.

Transaction processing application132may correspond to one or more processes to execute modules and associated specialized hardware of service provider server130to process a transaction, where the transaction may include transaction data generated by first user device110. In this regard, transaction processing application132may correspond to specialized hardware and/or software used by a user associated with first user device110to establish a payment account. In various embodiments, the financial information may include payment instrument information, such as account/card numbers and information. The account may be used to send and process payments, for example, by referring to stored financial information. The payment account may be accessed and/or used through a browser application and/or dedicated payment application executed by first user device110and engage in transaction processing through transaction processing application132. The payment account may also be accessed through an authentication mechanism by first user device110, which may require identity verification and confirmation through second user device120. In some embodiments, first user device110and/or a merchant device may generate transaction data, and may communicate with transaction processing application132to process the transaction with the account. Transaction processing application132may process a payment using the financial information to an account of another user or a merchant. Transaction processing application132may process the payment, and may provide a transaction history to first user device110for transaction authorization, approval, or denial. Additionally, transaction processing application may apply any rewards and/or loyalty benefits available to the user to the transaction, where such benefits are not applied directly by first user device110.

In various embodiments, service provider server130includes other applications134as may be desired in particular embodiments to provide features to payment provider server150. For example, other applications134may include security applications for implementing server-side security features, programmatic client applications for interfacing with appropriate application programming interfaces (APIs) over network150, or other types of applications. Other applications134may contain software programs, executable by a processor, including a graphical user interface (GUI), configured to provide an interface to the user when accessing payment provider server134. In various embodiments where not provided by transaction processing application132, other applications134may include connection and/or communication applications, which may be utilized to transmit communications to one or more devices.

Additionally, service provider server130includes database136. Accounts in database136may include entity information, such as name, address, birthdate, payment/funding information, additional user financial information, and/or other desired user data. The entity may link to their respective accounts through an account, user, merchant, and/or device ID, as well as a generated token, which may be provided to second user device120for use. Thus, when an ID is transmitted to service provider server130, e.g., from first user device110, an account belonging to the entity may be found. Database136may also include authentication and identity requirements, as well as identity confirmation messages and responses for processing to provide access requested by one or more devices.

In various embodiments, service provider server130includes at least one network interface component138adapted to communicate with first user device110and/or second user device120over network150. In various embodiments, network interface component138may comprise a DSL (e.g., Digital Subscriber Line) modem, a PSTN (Public Switched Telephone Network) modem, an Ethernet device, a broadband device, a satellite device and/or various other types of wired and/or wireless network communication devices including microwave, radio frequency (RF), and infrared (IR) communication devices.

Network150may be implemented as a single network or a combination of multiple networks. For example, in various embodiments, network150may include the Internet or one or more intranets, landline networks, wireless networks, and/or other appropriate types of networks. Thus, network150may correspond to small scale communication networks, such as a private or local area network, or a larger scale network, such as a wide area network or the Internet, accessible by the various components of system100.

FIG. 2Ais an exemplary real-world environment where a device may utilize short range wireless communications to confirm identity of a user during authentication processing, according to an embodiment. In environment200a, a user102may utilize first user device110discussed in reference to system100ofFIG. 2A. Similarly, a user104autilizes a user device120aand a user104butilizes a user device120b, where user device120aand user device120bboth correspond generally to second user device120discussed in reference to system100ofFIG. 1.

Environment200amay correspond to a location1000where users102,104a, and104bmay be co-located and user102may require use of first user device110to perform some process and access some resource. For example, location1000may correspond to a merchant location where user102attempts to pay for a transaction with a merchant device using first user device110(e.g., through electronic transaction processing using an online service provider, account, and/or payment information). In order to proceed with the requested process, user102may utilize first user device110to request access and/or processing. This may require identity confirmation that user102is an authorized user for the access and/or processing requested through first user device110. For example, an authentication request may be provided on first user device110to authenticate user102as the valid user, where the authentication request further uses user devices104a-bto validate the identity of user102as the valid user.

In this regard, at location1000, first user device110determines that an identity confirmation process is required and uses signaling1002ato communicate with user device120aand signaling1002bto communicate with user device120bthrough short range wireless communications. Signaling1002a-bmay be performed through Bluetooth or other device-to-device communication protocol, and may further allow for first user device110to scan for the presence of user devices120a-bin proximity to first user device110and ping those devices for a response to detect their presence. User device120amay respond to first user device110through signaling1004to notify first user device110that user device120ais within a wireless communication proximity range. Similarly, user device120bmay respond to first user device110through signaling1006. Once first user device110determines that user devices120a-bare close enough to communicate with through a short range wireless connection, first user device110may prepare a message for user devices120a-bthat may request users104a-bto respond to the message.

The message may correspond to a request to confirm that the authorized user for the process, account, device, or other requested access and/or processing is actually user102. The message may be transmitted or pushed from first user device110to user devices120a-bthrough signaling1002a-b, respectively. The message may then populate on an interface of user devices120a-b. Thus, users104a-bmay be requested to confirm that they can view the authorized user at location1000. If the authorized user is different than user102, then users104a-bmay deny that they are able to confirm the presence of the authorized user at location1000and requesting the access/processing through first user device110. This may cause first user device110and/or a service provider to deny authenticating the user and providing the access/processing. However, if users104a-brespond in the affirmative and can confirm that user102is the authorized user and is seen at location1000, the requested access/processing may be authenticated and confirmed, and user device110may proceed with processing. The response data may be transmitted by user devices120a-bto first user device110through signaling1004and1006, respectively.

The message may further request that user104a-bcapture an image of the authorized user for the requested access and/or processing, which may correspond to capturing an image of user102. Facial recognition may be performed on the image to determine if user102in the image(s) matches a stored image of the authorized user, which may be stored by first user device110and/or a service provider. Additionally, user102is confirmed as the authorized user, the user image for the requested access/processing may be updated based on the captured image for use in future facial recognition. In some embodiments, user devices120a-bmay be pointed at user102based on a command to identify user102and point user devices120a-bat user102or when capturing an image of user102for identity confirmation. Using data of the direction, angle, or other location measurement, triangulation may be performed to locate where user devices120a-bare pointing. This may provide a triangulated location where the device directions converge. Using this location, a geo-location of first user device110at a current time or time of the requested access/processing may be determined, and may be matched to the triangulated position to further verify that user102is at location1000and using first user device110(e.g., another user at location1000has not misappropriated first user device110and is attempting to use first user device110fraudulently).

FIG. 2Bis an exemplary communication device interface displaying an identity confirmation request during authentication processing, according to an embodiment. Environment200bincludes second user device120as discussed in reference to system100ofFIG. 1. In this regard, second user device120displays an interface1100, such as a user interface that may be displayed by identity confirmation application122is system100.

Interface1100may be used to display an identity confirmation message to a second user using second user device120in order to confirm an identity of a first user using a first device, such as first user device110in system100and environment200a. Interface1100may be displayed based on the message being transmitted to second user device120from the first user device and/or a service provider performing the authentication of the user's identity. Thus, interface1100may display a message1102to the second user using second user device120, which may include message content1104stating “Please identify [this user].” Message content1104may be used to alert the second user of an action to take, and may be displayed with an image1106of the second user. Image1106may assist the second user in determining whether the authorized user requesting the access/processing on the first device nearby second user device120is actually using the first device. In the second user can identify the first user nearby the second user, the second user may confirm that the first user is present using identity confirmation1108. However, if the first user is not present, an identity denial1110may be provided, which may indicate that the first device is potentially being used fraudulently and additional security mechanism should be instituted.

In addition to presenting image1106for confirmation of the user's identity, additional mechanisms may be provided with message1102and second user device120to further confirm that the first user is present nearby second user device120. For example, a directional request1112may be displayed that asks the second user to point second user device120at the first user if visible from image1106. The second user may confirm instructions1114using option1116when second user device120is pointed at the user. In response, second user device120may capture directional data of second user device120so that triangulation of a position of the first user may be determined and matched to a geo-location of the first user device. The second user may also be requested to image the user1118through a viewfinder displayed with message1102, such as a scene1120. This may be used for image matching and/or facial recognition to confirm the presence of the first user. Additionally, the second user may enter one or more comments to comments field1122, such as an indication of whether the first user is acting suspiciously or under duress and additional security precautions should be instituted.

FIG. 3is an exemplary system environment for communication device and server provider processes to generate a network cache and digital ledger to complete electronic transaction processing in the event of device failure, according to an embodiment. Environment300ofFIG. 3includes a first user device110, a second user device120, and a service provider server130corresponding generally to the described devices and associated features found in system100ofFIG. 1.

In environment300, first user device110, second communication device110, and service provider server may execute modules and processes described in reference toFIG. 1. In this regard, first user device110may initially execute authentication application112to enter an authentication request1200in order to receive some access or perform some process. Authentication request1200may be associated with a location1202where authentication request1200is entered and processing is requested. Using location1202and/or a scan of nearby devices through short range wireless communications, nearby devices1204may be determined. Additionally, authentication request1200may be associated with an authentication result1206that is determined or provided to authentication application112based on actions and data processed by second user device110and service provider server130. For example, messages1208may include an identity message1210for transmission to second user device120, which may be responded to with detected data1212by second user device120.

Service provider server130executes authentication processing application140to process authentication request1200and determine that authentication request1200requires an authentication confirmation requirement1300. Nearby devices1204may be detected for identity confirmation requirement1300, and identity message1210may be generated by authentication processing application140having user image1302from user account data1308and an identity query1304to assist in determining an identity of a user using first user device110. Thus, authentication processing application140may access user account data1308to determine identity information1310for identity message1210, where identity information may include both user image1302and additional personal information1312for the user. However, in some embodiments, first user device110may provide one or more of the processes discussed in reference to service provider server130independently, for example, to verify a user identity using first user device110.

Identity message1210may be transmitted to second user device120, and received messages1400by second user device120may include identity message1210having user image1392and identity query1304. This may be received by second user device120over short range wireless communications with first user device110or network communications with service provider server130. In response to identity message1210, detected data1212may be determined by second user device1212and sent back to one or more of first user device110over the wireless connection or service provider server130over the network connection. Detected data1212may be processed to determine an identity result1306based on whether the authorized use of user account data1308can be identified as using first user device110. Thus, authentication results1206may be determined and provided to first user device110to respond to authentication request1200.

FIG. 4is an exemplary process flowchart for a network cache of device input for redundancy during device inoperability, according to an embodiment. Note that one or more steps, processes, and methods described herein may be omitted, performed in a different sequence, or combined as desired or appropriate.

At step402of flowchart400, an authentication request is received from a device, such as a request to access some device operation, application, and/or an online account with a service provider. The authentication request may also correspond to a request to perform some processing in an application, such as an electronic transaction processing request through a payment application and using an online payment provider platform. In response to the request, it is determined that a user identity is required to be confirmed, at step404. This may be due to a new or unlikely place, time, or amount/transaction data associated with the authentication request. For example, if the user is purchasing an abnormally large transaction or at a new location, the transaction may be flagged as suspicious and identity may be required to be confirmed. In other embodiments, the confirmation may be set by the service provider and/or user.

At step406, a scan for nearby devices is executed. The scan may be through short range wireless communications and signaling by the device receiving the authentication request, or may be performed through geo-location matching of the device to other nearby devices. The nearby device may be detected as within a close enough proximity to provide viewing of a user using the first device receiving the authentication request. Additionally, a service provider may also determine the nearby devices based on prior authentications and/or verifications performed by the nearby devices, which may be with the device and the user of the device. For example, one or more of the nearby devices may previously have authenticated the user's identity and may therefore be selected. The service provider may provide a user interface on the device that displays the eligible verification users and allows the user of the device to select one or more of the eligible verification users for transmission of a verification message of the user's identity. This allows the user of the device to designate trusted users to receive the verification message and prevents unknown parties from receiving user information of the user.

Thus, at least one nearby device is identified, at step408, which allows for a user of the nearby device(s) to view the first device and/or user using the first device. This allows those nearby users to confirm an identity of the user using the first device or notify the first device and/or a service provider that an unknown user is using the device in a potentially fraudulent manner. In some embodiments, the at least one nearby device may be selected by the user of the device requiring identity confirmation, for example, through a display of a plurality of nearby devices on an interface of the device requiring the identity confirmation. Thus, a list of nearby devices may be presented to the user to allow the user to designate another user and/or device for the identity confirmation. A confirmation request of the user's identity is generated and transmitted to the nearby device(s), at step410, which requests that the nearby user(s) determine whether they can see the user using the first device, capture an image of that user, and/or point the device at the user to provide data that may be processed to determine whether the authorized user's identity can be verified and authentication provided to access or process data.

Identity confirmation data is received at step412, which may include a user response to the identity confirmation request, a captured image, and/or device directional data. This may be received by the first device and/or by a service provider server for processing, and the user identity is attempted to be confirmed, at step414, using the received data. If the identity can be confirmed the user may be authenticated for the requested access/processing, at step416. However, if the user identity cannot be confirmed, such as if the data is insufficient, it may be determined whether a retest is available, such as if the data is insufficient but not clearly of a different user. However, if no retest is available, such as if the data is clearly of a different user, then authentication may be denied at step418. However, if the retest is available, flowchart400may return to step408in order to identify other nearby devices and proceed with requesting identity confirmation from those devices.

In various embodiments, the request for nearby devices to identify or confirm the user/user device may be selectively sent. For example, not all nearby devices may be sent a request, such as if a device is determined to be associated with fraudulent transactions, reported stolen or missing, or is otherwise determined to not be trustworthy. Such a determination can be based on device identifiers of the devices or other data obtained about the devices. In some embodiments, the nearby devices that are selected to receive identity confirmation message may be based on previously provided authentication and/or identification information. Scores may be determined and associated with the nearby secondary devices based on the authentication information, which may be used to determine if the nearby devices qualify to receive the identity confirmation message. In some embodiments, a previous identification confirmation performed by the nearby device (including with the device requiring user identity confirmation) may be used to select and/or score the nearby device.

In another embodiment, responses from nearby devices may not be weighed or considered the same. For example, a request may be sent to all nearby devices, even ones who may not be trustworthy, and responses received by some devices that includes ones not necessarily trustworthy. In such cases, the system may ignore responses from devices determined to be less trustworthy or may apply a lower weight to those responses compared to responses from devices that have been associated with a high number of valid transactions. Determining whether a device is trustworthy can be based on a transaction history associated with the device and generating a trustworthiness score based on the transaction history and any other factors the system may use in fraud prevention and other risk mitigation measures. When the trustworthiness score exceeds a certain threshold, which can vary depending on the type of access requested, the device associated with the score can be deemed untrustworthy. The trustworthiness score can also be used to determine a weight to assign responses from specific devices, where low scores can be associated with greater weights and higher scores associated with lower or even zero weight.

Computer system500includes a bus502or other communication mechanism for communicating information data, signals, and information between various components of computer system500. Components include an input/output (I/O) component504that processes a user action, such as selecting keys from a keypad/keyboard, selecting one or more buttons, image, or links, and/or moving one or more images, etc., and sends a corresponding signal to bus502. I/O component504may also include an output component, such as a display511and a cursor control513(such as a keyboard, keypad, mouse, etc.). An optional audio input/output component505may also be included to allow a user to use voice for inputting information by converting audio signals. Audio I/O component505may allow the user to hear audio. A transceiver or network interface506transmits and receives signals between computer system500and other devices, such as another communication device, service device, or a service provider server via network150. In one embodiment, the transmission is wireless, although other transmission mediums and methods may also be suitable. One or more processors512, which can be a micro-controller, digital signal processor (DSP), or other processing component, processes these various signals, such as for display on computer system500or transmission to other devices via a communication link518. Processor(s)512may also control transmission of information, such as cookies or IP addresses, to other devices.