Patent ID: 12204632

Corresponding reference characters indicate corresponding parts throughout the drawings. References made throughout this disclosure. relating to specific examples, are provided for illustrative purposes, and are not meant to limit all implementations or to be interpreted as excluding the existence of additional implementations that also incorporate the recited features.

DETAILED DESCRIPTION

Some internet resources, such as user accounts (with user profiles) that a user may have with a service provider (e.g., a cellular carrier, other utility, banks, e-commerce websites, etc.) and payment portals may be targeted by hackers. In some scenarios, a hacker may attempt to access a user credential entry page in order to try multiple guesses at user credentials, hoping to break into a user account and access user information, products, or services. Service providers thus have an incentive to minimize exposure of user credential entry pages-even while providing user credential entry pages to legitimate account holders.

One defense that a service provider may use to mitigate hacker attempts is to encourage legitimate account holders to use applications installed on their devices (e.g., UEs), and persist some data on the UE (associated with the installed application, for example a “cookie”). When an account holder attempts to access the internet resource, the service provider's servers, which host the internet resource, use the persisted data on the UE to distinguish between access attempts by legitimate account holders and possible hacker attempts. Upon recognizing the persisted data on a UE, and linking it to an established user account or device, the service provider's servers may then permit the UE to access the user credential entry page. However, without the persisted data, for example with virtualized applications, this mode of distinguishing between access attempts by legitimate account holders and hackers may not be available.

Solutions for user authentication within a virtualized application include: receiving an indication of a login attempt by a user equipment (UE) using the virtualized application; based on at least receiving the indication of the login attempt by the UE, transmitting a short message service (SMS) message to the UE, the SMS message indicating an authentication code; receiving an indication of the UE having received the authentication code; based on at least determining that the indication of the UE having received the authentication code is valid, accepting user credentials from the virtualized application; and based on at least determining that the user credentials are valid, granting the virtualized application access to a controlled resource. In some examples, the controlled resource comprises a secured user account or a payment portal.

Aspects of the disclosure improve security of internet activity by granting virtualized applications access to controlled resources, even while reducing the exposure of user credential entry screens to hacker attacks. Aspects of the disclosure permit service providers to seamlessly authenticate virtualized applications into authentication frameworks, so that users are not required to install fully-functioning applications. For example, a service provider may alert a user to pay a bill using an application furnished by the service provider (which then facilitates access to a controlled resource such as a payment portal). The user may now enjoy the option to use a virtualized app to accomplish this task, while preserving the service provider's security measures.

Aspects of the disclosure operate in an unconventional manner, for example by incorporating a SMS (e.g., a silent SMS) to authenticate a UE, and based on the UE authentication being valid, permits authentication of the user of the UE. Some examples permit use of biometric authentication over a virtualized application.

Authentication is a two-part sequence: (1) verifying that the UE is actually on a specific cellular network using a device token sequence (implemented as silent SMS carrying an authentication code, in some examples), and verifying the correct mobile country code (MCC) and mobile network code (MNC) for the UE, and (2) authenticating user credentials (e.g., user name and password and/or biometric information).

With reference now to the figures,FIG.1illustrates an exemplary arrangement100that advantageously enables user authentication within a virtualized application144, in order to access a controlled resource152aor152b(e.g., a resource that is access-controlled and requires user credentials) from UE102. In some examples, controlled resource152acomprises a secured user account through which a user104is able to view account activity (e.g., past transactions, offers, etc.), and controlled resource152bcomprises a payment portal, through which user104may make secure payments related to the secured user account. In arrangement100, user104uses UE102to control execution of virtualized application144that actually executes on a host node140, rather than on UE102itself. This precludes an immediate need to install a full application118on UE102, in order to access controlled resource152aor152b, although user104may already have full application118on UE102, or may prefer to install full application118on UE102at a later time, after testing virtualized application144.

Host node140has a virtualization environment142that intakes a light application146, which is a software package version of full application118that may have been modified (relative to full application118) in order to meet file size and execution limitations. For example, whereas full application118may exceed 15 megabytes (MB) and use background networking, light application146may be reduced to smaller 10 MB and have background networking functionality removed. When virtualization environment142begins a virtualization session for user104, virtualization environment142intakes light application146and creates an instance of light application146as virtualized application144for execution within virtualization environment142. Screens produced by virtualized application144are displayed on UE102, as an application experience110. Some example screens are shown inFIG.2. In some examples, application experience110is displayed directly in a user interface (UI) on UE102.

Turning briefly toFIG.2, three example screens from virtualized application144are shown, that may be displayed to user104as application experience110: an initial login prompt screen200, a user credential entry screen210, and a user credential entry screen220. When user104first attempts to access controlled resource152a(or152b, e.g., in order to respond to a notice to pay a bill, or check whether user104qualifies for some promotion), user may select (click) a link associated with controlled resource152a. Because controlled resource152arequires access credentials, initial login prompt screen200is displayed by application experience110. Initial login prompt screen200has a login prompt message202, informing user104that a properly credentialed login is required, and a selectable (clickable) login control button204is provided.

User credential entry screen210is used for user104to enter a username212into a username edit box214and a password216into password edit box218. User credential entry screen220provides a biometric data alternative for user credentials, such as facial recognition, using a camera224or a fingerprint reader226(on UE102, as shown inFIG.1). User credential entry screen220has a prompt message222to inform user104to provide the biometric data that is used for obtaining access to controlled resource152aor152b.

Returning toFIG.1(but with continued reference toFIG.2), communication between UE102and each of host node140, a service provider node150, and authentication server160is described. UE102uses a transceiver106to communicate over a network660with at least host node140and service provider node150. Network660may be, for example, the internet, and is described further in relation toFIG.6. UE reaches network660through a cellular network120, via an air interface124to a base station122, or through a router132(e.g., a Wi-Fi router), via an air interface134. It should be understood that other networking routes may be used. It should also be understood that authentication server160or service provider node150communicate as necessary to facilitate user authentication processes.

In one illustrative example, a hacker136is attempting to compromise user accounts by guessing user credentials, and may try login attempts at service provider node150using a high number of possible user credential variations. In some examples, hacker136represents a human, although in some other examples, hacker136represents automated attack software (e.g., a “bot”). For defense against hacker136, service provider node150screens login attempts by accepting login credential entry from only recognized devices. In some examples, full application118facilitates this security measure by storing persistent data (e.g., a cookie or some other data) on UE102, so that when user104attempts to access controlled resource152aor152b, service provider node150recognizes UE102. Upon initial registration of UE102with service provider node150, additional steps may be needed. However, for subsequent access attempts, service provider node150already recognizes UE102(due to the persistent data) and login by user104becomes simpler. This permits user104to access controlled resources152aand152bwith relative convenience, while mitigating attempts by hacker136.

However, in some scenarios, user104has not yet installed full application118on UE102, and virtualized application144may be curtailed in functionality such that it is unable to store persistent data on UE102. Therefore, measures that enable user authentication within virtualized application144are described with additional reference toFIGS.3and4.FIG.3is a message sequence diagram300that shows a series of messages used in some examples of arrangement100, and is described in conjunction withFIG.4.FIG.4illustrates a flowchart400of exemplary operations associated with user authentication within a virtualized application. The messages of messaging sequence diagram300occur during various operations of flowchart400. In some examples, at least a portion of messaging sequence diagram300and at least a portion of flowchart400may each be performed using one or more computing devices600ofFIG.6.FIGS.1,3, and4should be viewed together.

Operation402(FIG.4) provides setup for user authentication within virtualized application144. User104sets up a secured user account at service provider node150(message at302ofFIG.3), and the service provider (that operates service provider node150) makes light application146available for execution by host node140(message304). Light application146has connectivity logic to service provider node150so that, when light application146executes as virtualized application144within virtualization environment142, selected inputs by user104on UE102, specifically user104interacting with application experience110, are provided to service provider node150(and/or authentication server160). In some examples, user104sets up a secured user account at authentication server160. In some examples, authentication server160is a separate node, with a different internet protocol (IP) address, than service provider node150. In some examples, however, authentication server160is not a separate node than service provider node150, and the functionality described for authentication server160is performed at or by service provider node150.

Operation404continues the setup process in examples in which user104wishes to use biometric data as user credentials. Operation404includes service provider node150(or authentication server160) receiving a biometric registration from UE102for use of biometric data for the user credentials, wherein receiving the biometric data comprises an image of the face of user104or the fingerprint of user104. Camera224may be used to capture a facial image, and fingerprint reader226may be used to read a fingerprint. The biometric registration information is sent as message306.

At406, hacker136attempts to guess user credentials at service provider node150or authentication server160, using message308. Service provider node150(or authentication server160) recognizes this attempt as not coming from a registered device, and so this attempt is ignored at440. In some scenarios, bot and hacker attempts to guess user credentials may exceed legitimate login attempts.

The service provider notifies user104that a bill is due for payment or that user104has qualified for some promotion in operation408, using message310. In some examples, message310may be a text message (e.g., an SMS message) or an email. User104launches virtualized application144in operation410, using message312. In some examples, this occurs by user104directing a browser112to a website linked to host node140and performing some action at the website to trigger host node140to begin executing virtualized application144. Operation412includes displaying initial login prompt screen200(seeFIG.2) in virtualized application144. Initial login prompt screen200is sent from virtualized application144(executing at host node140) as message314to UE102for display as application experience110.

At414, user104selects login control button204(e.g., via a tap on a touchscreen of UE102, where login control button204is displayed within application experience110), and UE102sends an indication of a login attempt to host node140, specifically, to virtualized application144, as message316a. Virtualized application144forwards the indication of the login attempt by UE102to service provider node150as message316b, which then forwards the indication to authentication server160as message316c. In some examples, virtualized application144forwards the indication of the login attempt by UE102directly to authentication server160. In some examples, application experience110contains sufficient functionality (e.g., as html code provided from virtualized application144) to provide the indication of the login attempt by UE102directly to service provider node150or authentication server160, without needing to involve host node140. Whichever path is implemented, operation414includes receiving an indication of a login attempt by UE102using virtualized application144.

At operation416, authentication server160sends (transmits) an authentication code to UE102as message318, for example using SMS or another messaging service. Operation416includes, based on at least receiving the indication of the login attempt by UE102, transmitting an SMS (or other type) message318to UE102, message318indicating an authentication code164. In some examples, authentication server uses a security function162to securely generate authentication code164so that hacker136is unable to spoof authentication code164. In some examples, message318comprises a silent SMS message. A silent SMS message is one in which the recipient device (e.g., another cellular phone) does not display the message or otherwise alert the user of the recipient device. For additional security, some examples may limit the number of messages318that authentication server160sends to UE102(e.g., only three per any 5-minute time window), to limit risk in the event that UE102has been compromised by hacker136.

UE102receives authentication code164at418, and processes authentication code164at420(represented as320inFIG.3). In some examples, operation420comprises merely copying authentication code164. In some examples, operation420comprises performing a one-way function (e.g., a hash function) on authentication code164. In some examples, operation420comprises combining (e.g., concatenating) authentication code164and persistent data on UE102and performing a one-way function on the combination of authentication code164and the persistent data. In some examples, operation420is performed by response logic114on UE102. In some examples, the persistent data comprises an international mobile equipment identity (IMEI) number116.

The result of operation420is an indication166of UE102having received authentication code164. UE102returns indication166as a response message322to authentication server160, in operation422. Operation424includes authentication server160receiving indication166of UE102having received authentication code164. Authentication server160is able to perform the first of the two stages: verifying that UE102is actually on cellular network120, for example by verifying the MCC and MNC for UE102using message318. In some examples, indication166of UE102having received authentication code164comprises an indication selected from the list consisting of: a copy of authentication code164, a result of a one-way function performed on authentication code164, and a result of a one-way function performed on a combination of authentication code164and persistent data (e.g., IMEI number116) on UE102. Authentication server160(and by extension, service provider node150) now have the ability to distinguish UE102from hacker136, and use this ability to permit user104to move to the next stage of authentication (user credentials).

Decision operation426(represented as324inFIG.3) determines whether indication166of UE102having received authentication code164is valid, for example by comparing indication166with authentication code164, reproducing the result of the one way function of operation420, or some other process. If indication166comprises a hash of authentication code164and IMEI number116, authentication server160and/or service provider node150will be able to independently reproduce indication166, because authentication server160and/or service provider node150will have learned IMEI number116during the setup process in operation402, and authentication server160generated authentication code164. If indication166is invalid, it is ignored at440.

If indication166is valid, user104will be permitted to enter user credentials. Operation428includes, based on at least determining that indication166of UE102having received authentication code164is valid, controlling virtualized application144to permit entry of user credentials. In some examples, this may involve authentication server160or service provider node150sending a message326to virtualized application144to display user credential entry screen210or user credential entry screen220(seeFIG.2). Virtualized application144sends user credential entry screen210or user credential entry screen220to application experience110as message328. In some examples, the user credentials comprise username212and/or password216. In some examples, the user credentials comprise biometric data. Thus, in some examples, controlling virtualized application144to permit entry of user credentials comprises an action selected from the list consisting of: displaying user credential entry screen210or220in virtualized application144, and controlling virtualized application144to read biometric data (e.g., from camera224or fingerprint reader226).

At430, user104enters the user credentials, which are returned to service provider node150. In some examples, this is accomplished by UE102sending message330ato host node140(e.g., application experience110communicating with virtualized application144) and host node140forwarding message330ato service provider node150as message330b. In some examples, UE102communicates directly with service provider node150. Operation432includes receiving, through virtualized application144, the user credentials. Because of the earlier stage of validating UE102via message318(e.g., with operations416-428), operation432comprises, based on at least determining that indication166of UE102having received authentication code164is valid, accepting user credentials from virtualized application144. Decision operation434(represented as332inFIG.3) determines whether the user credentials are valid, for example using an identity management154that lists authorized users and user accounts. If they are not, the login attempt is ignored at440.

Operation436includes, based on at least determining that the user credentials are valid, granting virtualized application144access to controlled resource152aor152b. service provider node150sends a message334ato host node140, which is forwarded to UE102as a notification in virtualized application144, using message334b. In some examples, controlled resource152acomprises a secured user account. In some examples, controlled resource152bcomprises a payment portal. In operation438, user104makes a payment or performs other user account activity using message336, such as updating a user profile in identity management154, purchasing products or services, responding to promotions, or other activity.

FIG.5illustrates a flowchart500of exemplary operations associated with user authentication within a virtualized application. In some examples, at least a portion of flowchart500may be performed using one or more computing devices600ofFIG.6. Operation502includes receiving an indication of a login attempt by a UE using the virtualized application. Operation504includes, based on at least receiving the indication of the login attempt by the UE, transmitting an SMS message to the UE, the SMS message indicating an authentication code. Operation506includes receiving an indication of the UE having received the authentication code. Operation508includes, based on at least determining that the indication of the UE having received the authentication code is valid, accepting user credentials from the virtualized application. Operation510includes, based on at least determining that the user credentials are valid, granting the virtualized application access to a controlled resource.

FIG.6illustrates a block diagram of computing device600that may be used as a component of arrangement100, for example, as any component described herein that may require computational or storage capacity. Computing device600has at least a processor602and a memory604that holds program code610, data area620, and other logic and storage630. Memory604is any device allowing information, such as computer executable instructions and/or other data, to be stored and retrieved. For example, memory604may include one or more random access memory (RAM) modules, flash memory modules, hard disks, solid-state disks, persistent memory devices, and/or optical disks. Program code610comprises computer executable instructions and computer executable components including any instructions necessary to perform operations described herein. Data area620holds any data necessary to perform operations described herein. Memory604also includes other logic and storage630that performs or facilitates other functions disclosed herein or otherwise required of computing device600. An input/output (I/O) component640facilitates receiving input from users and other devices and generating displays for users and outputs for other devices. A network interface650permits communication over a network660with a remote node670, which may represent another implementation of computing device600.

ADDITIONAL EXAMPLES

An example method of user authentication within a virtualized application comprises: receiving an indication of a login attempt by a UE using the virtualized application; based on at least receiving the indication of the login attempt by the UE, transmitting an SMS message to the UE, the SMS message indicating an authentication code; receiving an indication of the UE having received the authentication code; based on at least determining that the indication of the UE having received the authentication code is valid, accepting user credentials from the virtualized application; and based on at least determining that the user credentials are valid, granting the virtualized application access to a controlled resource.

An example system for user authentication within a virtualized application comprises: a processor; and a computer-readable medium storing instructions that are operative upon execution by the processor to: receive an indication of a login attempt by a UE using the virtualized application; based on at least receiving the indication of the login attempt by the UE, transmit an SMS message to the UE, the SMS message indicating an authentication code; receive an indication of the UE having received the authentication code; based on at least determining that the indication of the UE having received the authentication code is valid, accept user credentials from the virtualized application; and based on at least determining that the user credentials are valid, grant the virtualized application access to a controlled resource.

One or more example computer storage devices have computer-executable instructions stored thereon, which, upon execution by a computer, cause the computer to perform operations comprising: receiving an indication of a login attempt by a UE using the virtualized application; based on at least receiving the indication of the login attempt by the UE, transmitting a short message service (SMS) message to the UE, the SMS message indicating an authentication code; receiving an indication of the UE having received the authentication code; based on at least determining that the indication of the UE having received the authentication code is valid, accepting user credentials from the virtualized application; and based on at least determining that the user credentials are valid, granting the virtualized application access to a controlled resource.

Alternatively, or in addition to the other examples described herein, examples include any combination of the following:the SMS message comprises a silent SMS message;the indication of the UE having received the authentication code comprises an indication selected from the list consisting of: a copy of the authentication code, a result of a one-way function performed on the authentication code, and a result of a one-way function performed on a combination of the authentication code and persistent data on the UE;accepting user credentials from the virtualized application comprises an action selected from the list consisting of: displaying a user credential entry screen in the virtualized application, and controlling the virtualized application to read biometric data;receiving a biometric registration from the UE for use of biometric data for the user credentials, wherein receiving the biometric data comprises an image of a user's face or a user's fingerprint;the controlled resource comprises a secured user account;the controlled resource comprises a payment portal;displaying an initial login prompt screen in the virtualized application;the user credentials comprise a username and/or a password;the user credentials comprise biometric data;the biometric data comprises a fingerprint and/or an image of a user's face; andthe persistent data on the UE comprises an IMEI number.

The order of execution or performance of the operations in examples of the disclosure illustrated and described herein is not essential, unless otherwise specified. That is, the operations may be performed in any order, unless otherwise specified, and examples of the disclosure may include additional or fewer operations than those disclosed herein. For example, it is contemplated that executing or performing a particular operation before, contemporaneously with, or after another operation is within the scope of aspects of the disclosure. It will be understood that the benefits and advantages described above may relate to one embodiment or may relate to several embodiments. When introducing elements of aspects of the disclosure or the examples thereof, the articles “a,” “an,” “the,” and “said” are intended to mean that there are one or more of the elements. The terms “comprising,” “including,” and “having” are intended to be inclusive and mean that there may be additional elements other than the listed elements. The term “exemplary” is intended to mean “an example of.”

Having described aspects of the disclosure in detail, it will be apparent that modifications and variations are possible without departing from the scope of aspects of the disclosure as defined in the appended claims. As various changes may be made in the above constructions, products, and methods without departing from the scope of aspects of the disclosure, it is intended that all matter contained in the above description and shown in the accompanying drawings shall be interpreted as illustrative and not in a limiting sense.