Systems and methods for mobile emulator detection

The risk assessment computing system uses an emulator detection model to generate a risk indicator, addressing the challenge of distinguishing between legitimate devices and emulators, thereby enhancing network security by preventing fraud and unauthorized access.

WO2025174374A1PCT designated stage Publication Date: 2025-08-21EQUIFAX INC
View PDF 3 Cites 0 Cited by

Patent Information

Application Number
PCT/US2024/016036
Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
Filing Date
2024-02-15
Publication Date
2025-08-21

AI Technical Summary

Technical Problem

Existing network security systems struggle to effectively distinguish between legitimate devices and mobile device emulators or bots, which can impersonate trusted identities to gain access to secure resources, leading to potential fraud and security breaches.

Method used

A risk assessment computing system that utilizes an emulator detection model trained on attribute and interaction data to generate a risk indicator, determining the likelihood of a device being a mobile device emulator, thereby enhancing security by preventing unauthorized access.

Benefits of technology

The system improves network security by accurately identifying potential fraudulent activities and preventing unauthorized access, allowing entities to make informed decisions on granting access based on the risk of using a mobile device emulator.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure US2024016036_21082025_PF_FP_ABST
    Figure US2024016036_21082025_PF_FP_ABST
Patent Text Reader

Abstract

A method described herein involves various operations directed toward network security. The operations include receiving a request for a risk indicator of a target entity. The risk indicator can indicate a level of risk associated with the target entity based on whether the target entity is associated with a mobile device emulator. The operations include generating the risk indicator by applying the entity data to an emulator detection model trained on a training dataset comprising a corpus of attribute data and interaction data. Finally, the operations include providing, to a remote computing device, a responsive message comprising at least the risk indicator to control access to an interactive computing environment.
Need to check novelty before this filing date? Find Prior Art

Description

Attorney Docket No.096923-1390989 SYSTEMS AND METHODS FOR MOBILE EMULATOR DETECTION TECHNICAL FIELD

[0001] The present disclosure relates generally to network security. More specifically, but not necessarily exclusively, this disclosure relates to network security techniques that involve determining whether a device associated with a target entity is an emulator or bot. BACKGROUND

[0002] Various interactions are performed frequently through an interactive computing environment such as a website, a user interface, etc. The interactions may involve transferring resources for or otherwise based on content. The content may include computing resources or other products or services desired by an entity that may transfer the resources. Determining whether entities involved in the interactions or other potential interactions are legitimate can be difficult. For example, emulators and bots can be used by bad actors to attempt to gain access to secure resources by impersonating or spoofing a trusted identity or device. SUMMARY

[0003] Various aspects of the present disclosure provide techniques for providing network security by detecting emulators and bots attempting to access secure resources as a target entity or device associated with a target entity. Examples described herein can enhance network security through the detection and prevention of fraud by preventing bad actors from accessing secure resources or computing environments.

[0004] Some examples are systems and methods that provide risk assessment using a risk indicator. For instance, the system can receive a request for a risk indicator of a target entity determined from entity data associated with the target entity. The risk indicator can indicate a level of risk associated with the target entity based on whether the target entity is associated with a mobile device emulator. The system can train an emulator detection model for determining the risk indicator from the entity data using a training process. The training process can include: receiving, from a data repository, a training dataset including attribute data and interaction data; extracting features from the training dataset; and training the emulator detection model on the features. The system can also generate the risk indicator by applying the entity data to the trained emulator US2008229919481Attorney Docket No.096923-1390989 detection model. The system can also provide, to a remote computing device, a responsive message including at least the risk indicator to control access to an interactive computing environment.

[0005] In other aspects, a method can be used to control interactions between computing systems based on risk assessment. The method can include receiving, by a processing device, a request for a risk indicator of a target entity determined from entity data associated with the target entity. The risk indicator can indicate a level of risk associated with the target entity based on whether the target entity is associated with a mobile device emulator. The method can include generating, by the processing device, the risk indicator by applying the entity data to an emulator detection model trained on a training dataset including a corpus of attribute data and interaction data. The method can also include providing, by the processing device to a remote computing device, a responsive message including at least the risk indicator to control access to an interactive computing environment.

[0006] In other aspects, a non-transitory computer-readable medium can include instructions that are executable by a processor for causing the processor to perform various operations. The operations can include receiving a request for a risk indicator of a target entity determined from entity data associated with the target entity. The risk indicator can indicate a level of risk associated with the target entity based on whether the target entity is associated with a mobile device emulator. The operations can include generating the risk indicator by applying the entity data to an emulator detection model trained on a training dataset including attribute data and interaction data. The operations can also include providing, to a remote computing device, a responsive message including at least the risk indicator to control access to an interactive computing environment.

[0007] This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used in isolation to determine the scope of the claimed subject matter. The subject matter should be understood by reference to appropriate portions of the entire specification, any or all drawings, and each claim.

[0008] The foregoing, together with other features and examples, will become more apparent upon referring to the following specification, claims, and accompanying drawings. 2 US2008229919481Attorney Docket No.096923-1390989 BRIEF DESCRIPTION OF THE DRAWINGS

[0009] FIG.1 is a block diagram depicting an example of an operating environment in which a risk assessment computing system can be utilized to provide a risk assessment according to some aspects of the present disclosure.

[0010] FIG.2 is a block diagram depicting a process for generating a risk assessment according to some aspects of the present disclosure.

[0011] FIG. 3 is a block diagram of an application for generating a risk assessment according to some aspects of the present disclosure.

[0012] FIG.4 is a flow chart depicting an example of a process for generating a risk assessment using machine learning according to some aspects of the present disclosure.

[0013] FIG. 5 is a block diagram depicting an example of a computing device, which can be used to implement the embodiments described herein according to some aspects of the present disclosure. DETAILED DESCRIPTION

[0014] Disclosed systems and methods relate to network security techniques that involve determining whether a request to access a secure computing environment originates from a mobile device, or from a mobile device emulator functioning as that device. Identifying a manipulated identity or malicious activity can improve the security of an interactive computing environment, can improve the security of an interaction, and the like. Identities or devices can be spoofed or emulated to impersonate an entity with the aim of accessing a restricted resource or computing environment. For example, a bad actor can use an emulator or can spoof a device with the intention of initiating an interaction with a secure computing environment. An emulator can refer to hardware or software that enables a “host” computer system to function as another computer system, e.g., a “guest” computing system. Bad actors using these methods can circumvent security and access sensitive information or environments. For example, an emulator or mobile device emulator can run on a host computing system (e.g., a desktop computing system). The emulator can cause the host computing device to operate as another device (e.g., a mobile device), also referred to as a guest device. Thus, the desktop computing system can appear, to other systems with which interacts, as the mobile device. A bad actor can then use the desktop computing system functioning as the mobile device, to gain access to a secure computing system by appearing to be the mobile US2008229919481Attorney Docket No.096923-1390989 device. This allows the host computing system to circumvent security because it appears to be a trusted device, i.e., the mobile device.

[0015] Certain aspects described herein for performing risk assessments to determine a likelihood that a device associated with an entity is being spoofed using an emulator can address one or more of the foregoing issues. Generating a risk indicator indicative of a likelihood that a device attempting to access a secure system is an emulator can provide a more comprehensive and approach to risk assessment compared to conventional techniques, which are susceptible to spoofing attacks. The risk indicator can, for example, provide a probability that a device or identity attempting to access a secure computing environment is being spoofed using an emulator. This can improve an entity’s ability to prevent fraudulent activities and enhance security of online interactions.

[0016] In some aspects, a risk assessment computing system can receive a request for a risk indicator. For example, a risk assessment computing system can receive a request for a risk indicator in response to a user computing device attempting to access a secured interactive computing environment. The risk assessment computing system can receive entity data that includes attribute data and interaction data. From the entity data, the risk assessment computing system can extract a number of features on which to train a machine learning model. The trained model can then be applied to a sample of entity data to determine a risk indicator for a target entity. The trained model can, for example, identify patterns and characteristics associated with a device and interactions with that device that are difficult or impossible for a bot or emulator to replicate.

[0017] The risk indicator can, for example, indicate a probability that the target entity is requesting access to the interactive computing environment using a mobile device emulator, which can be evidence that a bot is requesting access, rather than the true user of the mobile device. Based on this risk indicator, an entity associated with the interactive computing environment can make an informed decision on whether to allow the target entity to access the interactive computing environment. For example, the risk indicator can be provided to a device associated with the entity.

[0018] Examples described herein provide improvements in the technical field of network security. For example, there exists a need to prevent bots, which are becoming increasingly sophisticated, from impersonating users and accessing secure computer systems. Systems and methods described herein facilitate detection of mobile device emulators, which can be used by bots to impersonate a known mobile device to gain access to a computer system. While the use of US2008229919481Attorney Docket No.096923-1390989 an emulator may not necessarily indicate malicious intent, the knowledge of whether a target entity is using a mobile device emulator can facilitate accurate risk assessment. For example, an entity can make a more informed decision on whether to allow a target entity using a mobile device emulator to access a system or resource based on the risk of the mobile device emulator being associated with a bot. Overview of a Risk Assessment Computing System

[0019] Referring now to the drawings, FIG. 1 is a block diagram depicting an example of an operating environment in which a risk assessment computing system can be used to provide a risk assessment associated with a target entity according to some aspects of the present disclosure. FIG. 1 depicts examples of hardware components of a risk assessment computing system 102, according to some aspects. The risk assessment computing system 102 can be a specialized computing system that may be used for processing large amounts of data using a large number of computer processing cycles. In other examples, the risk assessment computing system 102 may be or include a general- purpose computing system. The risk assessment computing system 102 can include a risk assessment server 104 for performing a risk assessment (e.g., predicting future risk of the entity, predicting likelihoods of a target entity using a mobile device emulator, etc.) with respect to a target entity attempting to access a secured resource of computing environment based on entity data including attribute data and interaction data.

[0020] The risk assessment server 104 can include one or more processing devices that can execute program code, such as a risk assessment application 106. The program code can be stored on a non-transitory computer-readable medium or other suitable medium. The risk assessment server 104 can perform risk assessment validation operations or access control operations for validating or otherwise authenticating, for example using other suitable modules, models, components, etc. of the risk assessment server 104, receive entity data such as attribute data and interaction data and the like received from the user computing systems 116, client computing systems 118, one or more data repositories, or any suitable combination thereof. In some aspects, the risk assessment application 106 can authenticate or deny a request for an interaction or for access using received entity data.

[0021] Entity data may be received by the risk assessment application 106 from a device associated with a target entity (e.g., user computing device 116), though the entity data 120 may be received from other suitable sources. The entity data can be determined or stored in one or more US2008229919481Attorney Docket No.096923-1390989 network-attached storage units on which various repositories, databases, or other structures are stored. An example of these data structures can include the data repository 118. Additionally or alternatively, a training dataset 122 can be stored in data repository 118. In some examples, the training dataset 122 can be used to train an emulator detection model 114. The emulator detection model 114 can be a machine learning model and can be trained to generate risk indicators associated with an interaction based on real-time data and the entity data 120.

[0022] The risk assessment application 106 can include a data collection module 108, a model creation module 110, an edge service module 112, and the emulator detection model 114. The data collection module 108 can, for example, maintain and control an API through which attribute data and interaction data associated with the user computing system 116 of the target entity are received. The model creation module 110 can generate and train the emulator detection model 114. The edge service module 112 can maintain and control an API to receive and handle risk indicator requests from the client computing system 124.

[0023] Network-attached storage units may store a variety of different types of data organized in a variety of different ways and from a variety of different sources. For example, the network- attached storage unit may include storage other than primary storage located within the risk assessment server 104 that is directly accessible by processors located therein. In some aspects, the network-attached storage unit may include secondary, tertiary, or auxiliary storage, such as large hard drives, servers, and virtual memory, among other types of suitable storage. Storage devices may include portable or non-portable storage devices, optical storage devices, and various other mediums capable of storing and containing data. A machine-readable storage medium or computer- readable storage medium may include a non-transitory medium in which data can be stored and that does not include carrier waves or transitory electronic signals. Examples of a non-transitory medium may include, for example, a magnetic disk or tape, optical storage media such as a compact disk or digital versatile disk, flash memory, memory devices, or other suitable media.

[0024] Furthermore, the risk assessment computing system 102 can communicate with various other computing systems. The other computing systems can include user computing systems 116, such as smartphones, personal computers, etc., client computing systems 124, and other suitable computing systems. For example, user computing systems 116 may transmit, such as in response to receiving input from the target entity, requests for accessing the interactive computing environment 126 to the client computing systems 124. In response, the client computing systems US2008229919481Attorney Docket No.096923-1390989 124 can send authentication queries to the risk assessment server 104, and the risk assessment server 104 can receive entity data 120 form the user computing system 116 and generate a risk indicator associated with the user computing system 116. In some aspects, the entity data 120 can be continually or periodically retrieved from the user computing system 116. While FIG.1 illustrates that the risk assessment computing system 102 and the client computing systems 124 are separate systems, the risk assessment computing system 102 and the client computing systems 124 can be one system. For example, the risk assessment computing system 102 can be a part of the client computing systems 124, or vice versa.

[0025] As illustrated in FIG. 1, the risk assessment computing system 102 may interact with the client computing systems 124, the user computing systems 116, or a combination thereof via one or more public data networks 128 to facilitate interactions between users of the user computing systems 116 and the interactive computing environment 126. For example, the risk assessment computing system 102 can facilitate the client computing systems 124 providing a user interface to the user computing system 116 for receiving various data from the user. The risk assessment computing system 102 can transmit validated risk assessment data, for example similarity- preserving hashes, comparisons or scores determined therefrom, etc., to the client computing systems 124 for providing, challenging, or rejecting, etc. access of the user entity to the interactive computing environment 126.

[0026] Each client computing system 124 may include one or more devices such as individual servers or groups of servers operating in a distributed manner. A client computing system 124 can include any computing device or group of computing devices operated by a seller, lender, or other suitable entity that can provide products or services. The client computing system 124 can include one or more server devices. The one or more server devices can include or can otherwise access one or more non-transitory computer-readable media.

[0027] The client computing system 124 can further include one or more processing devices that can be capable of providing an interactive computing environment 126, such as a user interface, etc., that can perform various operations. The interactive computing environment 126 can include executable instructions stored in one or more non-transitory computer-readable media. The instructions providing the interactive computing environment can configure one or more processing devices to perform the various operations. In some aspects, the executable instructions for the interactive computing environment can include instructions that provide one or more graphical US2008229919481Attorney Docket No.096923-1390989 interfaces. The graphical interfaces can be used by a user computing system 116 to access various functions of the interactive computing environment 126. For instance, the interactive computing environment 126 may transmit data to and receive data, such as via the graphical interface, from a user computing system 116 to shift between different states of the interactive computing environment 126, where the different states allow one or more electronic interactions between the user computing system 116 and the client computing system 124 to be performed.

[0028] In some examples, the client computing system 124 may include other computing resources associated therewith (e.g., not shown in FIG. 1), such as server computers hosting and managing virtual machine instances for providing cloud computing services, server computers hosting and managing online storage resources for users, server computers for providing database services, and others. The interaction between the user computing system 116, the client computing system 124, and the risk assessment computing system 102, or any suitable sub-combination thereof may be performed through graphical user interfaces, such as the user interface, presented by the risk assessment computing system 102, the client computing system 124, other suitable computing systems of the computing environment 100, or any suitable combination thereof. The graphical user interfaces can be presented to the user computing system 116. Application programming interface (API) calls, web service calls, or other suitable techniques can be used to facilitate interaction between any suitable combination or sub-combination of the client computing system 124, the user computing system 116, and the risk assessment computing system 102.

[0029] A user computing system 116 can include any computing device or other communication device that can be operated by a user or entity, such as the target entity, which may include a consumer or a customer. The user computing system 116 can include one or more computing devices such as laptops, smartphones, and other personal computing devices. A user computing system 116 can include executable instructions stored in one or more non-transitory computer-readable media. The user computing system 116 can additionally include one or more processing devices configured to execute program code to perform various operations. In various examples, the user computing system 116 can allow a user to access certain online services or other suitable products, services, or computing resources from a target entity, such as the client computing system 124, to engage in mobile commerce with the client computing system 124, to obtain controlled access to electronic content, such as the interactive computing environment 126, hosted by the client computing system 124, etc. US2008229919481Attorney Docket No.096923-1390989

[0030] In some examples, the target entity can use the user computing system 116 to engage in an electronic interaction with the client computing system 124 via the interactive computing environment 126. The risk assessment computing system 102 can receive a request, for example from the user computing system 116, to access the interactive computing environment 126 and can use data, such as real-time data, the entity data 120, or any other suitable data or signals determined therefrom, to determine whether to provide access, to challenge the request, to deny the request, etc. An electronic interaction between the user computing system 116 and the client computing system 124 can include, for example, the user computing system 116 being used to request a financial loan or other suitable service or product from the client computing system 124. An electronic interaction between the user computing system 116 and the client computing system 124 can also include, for example, one or more queries for a set of sensitive or otherwise controlled data, accessing online financial services provided via the interactive computing environment 126, submitting an online credit card application or other digital application to the client computing system 124 via the interactive computing environment 126, operating an electronic tool within the interactive computing environment 126 (e.g., a content-modification feature, an application- processing feature, etc.), etc.

[0031] In some aspects, an interactive computing environment 126 implemented through the client computing system 124 can be used to provide access to various online functions. As a simplified example, a user interface or other interactive computing environment 126 provided by the client computing system 124 can include electronic functions for requesting computing resources, online storage resources, network resources, database resources, or other types of resources. In another example, a website or other interactive computing environment 126 provided by the client computing system 124 can include electronic functions for obtaining one or more financial services, such as an asset report, management tools, credit card application and transaction management workflows, electronic fund transfers, etc.

[0032] A user computing system 116 can be used to request access to the interactive computing environment 126 provided by the client computing system 124. The client computing system 124 can submit a request, such as in response to a request made by the user computing system 116 to access the interactive computing environment 126, for risk assessment to the risk assessment computing system 102 and can selectively grant or deny access to various electronic functions based on risk assessment performed by the risk assessment computing system 102. Based on the request, US2008229919481Attorney Docket No.096923-1390989 the risk assessment computing system 102 can determine one or more risk signals or risk indicators for the target entity, which may submit or may have submitted the request via the user computing system 116. Based on a risk indicator determined from emulator detection model 114, the risk assessment computing system 102, the client computing system 124, or a combination thereof can determine whether to grant the access request of the user computing system 116 to certain features of the interactive computing environment 126. The risk assessment computing system 102, the client computing system 124, or a combination thereof can use the risk indicator for other suitable purposes such as identifying a manipulated identity, controlling a real-world interaction, and the like.

[0033] In a simplified example, the system illustrated in FIG. 1 can configure the risk assessment server 104 to be used for controlling access to the interactive computing environment 126. The risk assessment server 104 can receive entity data 120 associated with the user computing system 116 used by a target entity that submitted a request to access the interactive computing environment 126. The entity data 120 may, for example, include attribute data and interaction data collected from the user computing system 116. The risk assessment server 102 can receive the entity data 120 indicating attributes of the user computing system 116 itself and interactions between the target entity and the user computing system 116. In some examples, the entity data 120 may include data detected during a specified time period.

[0034] The risk assessment server 104 can determine a risk indicator associated with the target entity based on the entity data 120 by applying the entity data 120 to an emulator detection model 114. The risk assessment server 104 can access training datasets 122 in the data repository 118 and extract features from the training datasets 122. The risk assessment server 104 can use the extracted features to train the emulator detection model 114. The entity data 120 can be applied to the trained emulator detection model to generate the risk indicator, which can be, for example, a probability that the target entity is using a mobile device emulator to request access to the interactive computing environment 126. The risk assessment server 104 can transmit the risk indicator, or any inference derived therefrom, to the client computing system 124 for use in controlling access to the interactive computing environment 126.

[0035] The risk indicator associated with the target entity, or any suitable score or comparison determined therefrom, can be used, for example by the risk assessment computing system 102, the client computing system 124, etc., to determine whether the risk associated with the target entity US2008229919481Attorney Docket No.096923-1390989 accessing a good or a service provided by the client computing system 124 using the identity element exceeds a threshold, thereby granting, challenging, or denying access by the target entity to the interactive computing environment 126. For example, if the risk assessment computing system 102 determines that the risk indicator indicates that a probability of the target entity using a mobile device emulator to access the interactive computing environment is lower than a predetermined threshold, then the client computing system 124 associated with the service provider can generate or otherwise provide access permission to the user computing system 116 that requested the access. The access permission can include, for example, cryptographic keys used to generate valid access credentials or decryption keys used to decrypt access credentials. The client computing system 124 can also allocate resources to the target entity and provide a dedicated web address for the allocated resources to the user computing system 116, for example, by adding the user computing system 116 in the access permission. With the obtained access credentials or the dedicated web address, the user computing system 116 can establish a secure network connection to the interactive computing environment 126 hosted by the client computing system 124 and access the resources via invoking API calls, web service calls, HTTP requests, other suitable mechanisms or techniques, etc.

[0036] In some examples, the risk assessment computing system 102 may determine whether to grant, challenge, or deny the access request made by the user computing system 116 for accessing the interactive computing environment 126. For example, based on the risk indicator or other inferences, the risk assessment computing system 102 can determine that the target entity is a legitimate entity that made the access request and may authenticate the request. In other examples, the risk assessment computing system 102 can challenge or deny the access attempt if the risk assessment computing system 102 determines that the target entity may not be a legitimate entity. In some aspects, the risk indicator can be used as a factor in determining whether to allow the user computing system 116 to access the interactive computing environment 126. For example, the target entity’s use of a mobile device emulator may not, in and of itself, be indicative of malicious intent. Thus, the risk indicator can be used to determine whether to monitor the target entity based on the risk indicator falling above a predetermined threshold.

[0037] In some examples, the risk indicator used to determine access to the interactive computing environment 126 may be determined at least in part based on output from the emulator detection model 114. The emulator detection model 114 may be a random forest model that is US2008229919481Attorney Docket No.096923-1390989 trained using the training dataset 122 to generate a risk indicator (e.g., a score that predicts whether the target entity is using a mobile device emulator to request access to the interactive computing environment 126). The risk assessment server 104 can update the risk indicator associated with the target entity in real time based on continual collection and analysis of entity data associated with the user computing system 116. For example, the risk assessment server 104 may retrieve additional entity data and apply the emulator detection model to the additional entity data to determine, from the more recent data, a higher probability that the target entity is requesting access to the interactive computing environment via a mobile device emulator.

[0038] Each communication within the computing environment 100 may occur over one or more data networks, such as a public data network 128, a network 130 such as a private data network, or some combination thereof. A data network may include one or more of a variety of different types of networks, including a wireless network, a wired network, or a combination of a wired and wireless network. Examples of suitable networks include the Internet, a personal area network, a local area network (“LAN”), a wide area network (“WAN”), or a wireless local area network (“WLAN”). A wireless network may include a wireless interface or a combination of wireless interfaces. A wired network may include a wired interface. The wired or wireless networks may be implemented using routers, access points, bridges, gateways, or the like, to connect devices in the data network.

[0039] The number of devices illustrated in FIG. 1 is provided for illustrative purposes. Different numbers of devices may be used. For example, while certain devices or systems are shown as single devices in FIG. 1, multiple devices may instead be used to implement these devices or systems. Similarly, devices or systems that are shown as separate may be instead implemented in a signal device or system. Example of an Environment for Performing Risk Assessment

[0040] FIG.2 is a diagram of an environment 200 for performing risk assessment in accordance with aspects of the present disclosure. The environment 200 can include one or more components described above with reference to FIG.1, although other configurations are possible.

[0041] The environment 200 can include a user 202 where the user 202 is associated with a user computing system 116, which can either be a device 204 or a mobile device emulator 206. In either case, the user 202 can interact with the interactive computing environment 126 via a host application 208 installed on the device 204 or the mobile device emulator 206. The host application US2008229919481Attorney Docket No.096923-1390989 208 can include a software-development kit (SDK) 210 provided by the client computing system 124.

[0042] In some aspects, the SDK 210 can be configured to collect and transmit attribute data and interaction data. Attribute data can refer to, for example, data associated with the device 204 (or emulated device 206) of the user 202. Attribute data can include: battery data (e.g., a battery health indicator, a battery temperature, a battery model, a battery charge level, and the like); a charging state of the device 204 or emulated device 206 (e.g., if the battery of the device is currently charging); and device manufacturer data (e.g., a model number, operating system, serial number, and the like). Interaction data can refer to data indicative of the user’s interactions with the device 204 (or emulated device 206). For example, interaction data can include: data indicative with the user’s interactions with a GUI of the host application 208 (e.g., input data or navigation information indicating how the user is navigating the GUI); general screen-touch data (e.g., where on the screen the user is touching and what elements the user is interacting with); device sensor data (e.g., accelerometer data, GPS data, and the like); and screen time data (e.g., how long the device is in a sleep mode or how long the user is interacting with the interface of the device). The attribute data and the interaction data can be indicative of whether a user 202 is using a device 204 or a mobile device emulator 206 to interact with the host application 210.

[0043] The SDK 210 can collect the entity data (e.g., the attribute data and the interaction data) continually and can continually or periodically transmit the collected entity data to the risk assessment server 104. For example, the SDK 210 can transmit the entity data to the risk assessment server 104 via an API. In some aspects, the entity data can be collected over a predetermined sample interval and periodically transmitted to the risk assessment server 104.

[0044] In some aspects, the client computing system 124 can request a risk indicator for a data entity sample associated with a prior period of time (e.g., a time when suspicious activity associated with the target entity was detected). The risk assessment server 104 can request entity data collected during the indicated time period from the SDK 210. A risk indicator generated from such entity data can be used, for example, to compare a previous risk indicator with a current risk indicator to determine whether the risk associated with the target entity has changed over time.

[0045] The risk assessment server 104 can use a training dataset (e.g., training datasets 122) including a corpus of entity data to train the emulator detection model 114 based on features extracted from the training dataset, as will be further explained with reference to FIG.3 below. The US2008229919481Attorney Docket No.096923-1390989 trained emulator detection model 114 can be used to generate a risk indicator based on the received entity data. In some aspects, the risk indicator can be generated by the risk assessment server 104 in response to a request received from the client computing system 124 in response to the user 202 attempting to access the interactive computing environment 126 via the host application 208. The risk indicator can include a probability that the user is running the host application 208 on a mobile device emulator 206, as opposed to a device 204.

[0046] The risk indicator can be transmitted to the client computing system 124 as part of a response message. The risk indicator can be used by the client computing system 124 in determining whether to grant or deny access of the user 202 (e.g., the target entity) to the interactive computing environment 126. In some aspects, the risk indicator can be combined with other indicators or factors as a part of the analysis of whether to grant or deny access. Example of a Risk Assessment Application

[0047] FIG. 3 is a block diagram of a risk assessment application 106 according to aspects of the present disclosure. The risk assessment application 106 can be used to generate and train a model for generating a risk indicator associated with the likelihood that a target entity is using a mobile device emulator.

[0048] The risk assessment application can receive entity data transmitted via an API from the SDK 210 included in a host application 208 associated with an interactive computing environment 126 provided by a client computing device 124. The entity data can be received by the data collection module 108. In some aspects, the data collection module 108 can retrieve entity data from the SDK 210 periodically. In other aspects, the data collection module 108 can request entity data associated with a particular time period.

[0049] The model creation module 110 can include a number of sub-modules: a feature extraction module 302; a training module 304; and engine tuning module 306; a hyperparameter tuning module 308; and a threshold tuning module 310. The model creation module 110 can receive a training dataset (e.g., training datasets 122) including a corpus of entity data. The feature extraction module 302 can extract one or more features from the training dataset. Exemplary features can include: a maximum, minimum, or mean time a user interacted with a particular screen of the host application 208; an average accelerometer reading while interacting with the host application; a GPS area within which the user was located while interacting with the host application 208, and the like. In some aspects, the feature extraction module 302 can determine a US2008229919481Attorney Docket No.096923-1390989 weight associated with each feature, where the weight is higher for features that are more indicative of a user interacting with the host application 208 via an emulator.

[0050] The extracted features can be provided to the training module 304 for use in training the emulator detection model 114. In some aspects, the emulator detection model 114 can be a random forest (RF) model. The training module 304 can further tune the emulator detection model 114 based on input received from the engine tuning module 306. The engine tuning module 306 can receive hyperparameter values determined by the hyperparameter tuning module 308 and can pass these values to the training module 304 to further refine the emulator detection module. For example, by tuning the hyperparameters of the emulator detection module 114, the training module 304 can improve the performance (e.g., the accuracy and efficiency) of the emulator detection module 114.

[0051] In some aspects, the risk assessment application 106 can include a threshold tuning module 310. The threshold tuning module 310 can determine an optimal threshold for the risk indicator. For example, the risk indicator indicates a likelihood of the user 202 using a mobile device emulator 206 to interact with the host application 208. The threshold above which a user is identified as using a mobile device emulator can be optimized to minimize false negatives and reduce the instances of mislabeling devices as emulators.

[0052] The training module 304 can iteratively interact with the engine tuning module 306 to generate and output the emulator detection model 114. The emulator detection model 114 can be used by the risk assessment application 106 to generate a risk indicator each time a request is received for a target entity. Thus, the risk assessment application 106 will generate a risk indicator including a probability that the target entity is using a mobile device emulator to access an interactive computing environment 126 via the host application 208. Techniques for Generating a Risk Indicator

[0053] FIG. 4 is a flow chart depicting an example of a process 400 for generating a risk assessment associated with a target entity using machine learning according to some aspects of the present disclosure. In some examples, the operations of the process 400, or any subset thereof, may be performed by the risk assessment computing system 102 via the risk assessment server 104, but other suitable systems, devices, or subsets or combinations thereof may perform one or more operations described with respect to the process 400. For illustrative purposes, the process 400 is US2008229919481Attorney Docket No.096923-1390989 described with reference to certain examples depicted in the figures. Other implementations, however, are possible.

[0054] At block 402, the process 400 can include receiving a request for a risk indicator of a target entity determined from entity data associated with the target entity. The risk indicator can indicate a level of risk associated with the target entity based on whether the target entity is associated with a mobile device emulator. As discussed above, the entity data can include attribute data and interaction data. The attribute data can include data that is associated with the device 204 (or the emulator 206) that the target entity is using to attempt to access an interactive computing environment 126 via a host application 208. The interaction data can include data related to the target entity’s interactions with the host application 208 and with the device 204 (or emulator 206).

[0055] In some aspects, the entity data is received from the host application 208 via an API. The entity data can be continually or periodically transmitting to the risk assessment server 104. In some aspects, the risk assessment server 104 can receive a request for a risk indicator, where the request includes an indication of a time period. The risk assessment server 104 can receive entity data collected during that time period from which to generate the risk indicator.

[0056] At block 404, the process 400 can include training an emulator detection model for determining the risk indicator from the entity data using a training process. The emulator detection model can be a machine learning model and can be trained to predict whether an access request is originating from a mobile device or from an emulator acting as the mobile device. The training process can include receiving, from a data repository (e.g., the data repository 118), a training dataset 122. The training dataset can include a corpus of attribute data and interaction data. The training process can include extracting features from the training dataset and training the emulator detection model on the extracted features. The generated features can be indicative, for example, of a mobile device emulator being used to access an interactive computing environment 126. The use of a mobile device emulator can indicate an elevated risk that a bot, rather than the user of the mobile device being emulated, is attempting to gain access to the interactive computing environment 126. As described above, the training process can also include tuning hyperparameters of the emulator detection model to improve its accuracy and efficiency. US2008229919481Attorney Docket No.096923-1390989

[0057] At block 406, the process 400 can include generating the risk indicator by applying the entity data to the trained emulator detection model. The risk indicator can indicate a likelihood that the target entity is using a mobile device emulator to request access to an interactive computing environment 126. In some aspects, the emulator detection model can be trained to generate a risk indicator indicative of a likelihood that the target entity is a bot using either a device or an emulator to request access to the interactive computing environment 126. In some aspects, in which a time period for the risk indicator is specified in the request, the risk assessment server 104 can receive a first sample of entity data associated with the time period and apply the emulator detection model to the first sample to generate a risk indicator associated with the target entity based on the specified time period.

[0058] At block 408, the process 400 includes providing, to a remote computing device, a responsive message including at least the risk indicator to control access to an interactive computing environment. For example, the risk assessment server 104 can determine the risk indicator of the target entity and transmit the risk indicator to the client computing system 124 as part of a responsive message. The client computing system 124 can then use the risk indicator itself to determine whether to grant or deny access of the target entity to an interactive computing environment 126, or the client computing system 124 can use the risk indicator as a factor in the determination.

[0059] Accordingly, disclosed systems and methods facilitate fraud prevention by determining a risk indicator that can indicate a likelihood that a target entity is using an emulator to access an interactive computing environment or a likelihood that a bot is attempting to access the interactive computing environment. Disclosed systems and methods can enable entities to make informed decisions on whether to allow a target entity to access an interactive computing environment based on an allowable level of risk associated with a user using a mobile device emulator. Example of a Computing System

[0060] Any suitable computing system or group of computing systems can be used to perform the operations for the techniques described herein. For example, FIG.5 is a block diagram depicting an example of a computing device 500, which can be used to implement the risk assessment server 104. The computing device 500 can include various devices for communicating with other devices US2008229919481Attorney Docket No.096923-1390989 in the computing environment 100, as described with respect to FIG.1. The computing device 500 can include various devices for performing one or more operations, such as risk assessment operations, described above with respect to FIGs.1-4.

[0061] The computing device 500 can include a processor 502 that can be communicatively coupled to a memory 504. The processor 502 can execute computer-executable program code stored in the memory 504, can access information stored in the memory 504, or both. Program code may include machine-executable instructions that may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc., may be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, among others.

[0062] Examples of a processor 502 can include a microprocessor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or any other suitable processing device. The processor 502 can include any suitable number of processing devices, including one. The processor 502 can include or communicate with a memory 504. The memory 504 can store program code that, when executed by the processor 502, causes the processor 502 to perform the operations described herein.

[0063] The memory 504 can include any suitable non-transitory computer-readable medium. The computer-readable medium can include any electronic, optical, magnetic, or other storage device capable of providing a processor with computer-readable program code or other program code. Non-limiting examples of a computer-readable medium can include a magnetic disk, memory chip, optical storage, flash memory, storage class memory, ROM, RAM, an ASIC, magnetic storage, or any other medium from which a computer processor can read and execute program code. The program code may include processor-specific program code generated by a compiler or an interpreter from code written in any suitable computer-programming language. Examples of suitable programming language can include Hadoop, C, C++, C#, Visual Basic, Java, Python, Perl, JavaScript, ActionScript, etc.

[0064] The computing device 500 may also include a number of external or internal devices such as input or output devices. For example, the computing device 500 is illustrated with an US2008229919481Attorney Docket No.096923-1390989 input / output interface 508 that can receive input from input devices or provide output to output devices. A bus 506 can also be included in the computing device 500. The bus 506 can communicatively couple one or more components of the computing device 500.

[0065] The computing device 500 can execute program code 514 that can include risk assessment application 106. The program code 514 for the risk assessment application 106 may be resident in any suitable computer-readable medium and may be executed on any suitable processing device. For example, and as illustrated in FIG. 5, the program code 514 for the risk assessment application 106 can reside in the memory 504 at the computing device 500 along with the program data 516 associated with the program code 514, such as the entity data 120. Executing the risk assessment application 106 can configure the processor 502 to perform at least a portion of the operations described herein.

[0066] In some aspects, the computing device 500 can include one or more output devices. One example of an output device can be or include the network interface device 510 illustrated in FIG. 5. A network interface device 510 can include any device or group of devices suitable for establishing a wired or wireless data connection to one or more data networks described herein. Non-limiting examples of the network interface device 510 can include an Ethernet network adapter, a modem, etc.

[0067] Another example of an output device can include the presentation device 512 depicted in FIG. 5. A presentation device 512 can include any device or group of devices suitable for providing visual, auditory, or other suitable sensory output. Non-limiting examples of the presentation device 512 can include a touchscreen, a monitor, a speaker, a separate mobile computing device, etc. In some aspects, the presentation device 512 can include a remote client- computing device that communicates with the computing device 500 using one or more data networks described herein. In other aspects, the presentation device 512 can be omitted.

[0068] The foregoing description of some examples has been presented only for the purpose of illustration and description and is not intended to be exhaustive or to limit the disclosure to the precise forms disclosed. Numerous modifications and adaptations thereof will be apparent to those skilled in the art without departing from the spirit and scope of the disclosure. US2008229919481

Claims

Attorney Docket No.096923-1390989 CLAIMS What is claimed is:

1. A method comprising: receiving, by a processing device, a request for a risk indicator of a target entity determined from entity data associated with the target entity, the risk indicator indicating a level of risk associated with the target entity based on whether the target entity is associated with a mobile device emulator; generating, by the processing device, the risk indicator by applying the entity data to an emulator detection model trained on a training dataset comprising a corpus of attribute data and interaction data; and providing, by the processing device to a remote computing device, a responsive message comprising at least the risk indicator to control access to an interactive computing environment.

2. The method of claim 1, further comprising: collecting, by the processing device, the entity data over a period of time to generate a sample; and applying the sample to the trained emulator detection model to generate the risk indicator.

3. The method of claim 2, further comprising: receiving, by the processing device, a request for the risk indicator associated with the target entity, wherein the request comprises a requested time period; and applying a first sample collected during the requested time period to the trained emulator detection model to generate the risk indicator.

4. The method of claim 1, wherein the attribute data is associated with a device of the target entity and comprises at least one of: battery health data; a battery charging status; or device manufacturer data. US2008229919481Attorney Docket No.096923-1390989 5. The method of claim 1, wherein the interaction data is associated with data indicative of interactions between a device of the target entity and the target entity, and comprises at least one of: interface interaction data; sensor data; or screen time data.

6. The method of claim 1, wherein the method further comprises: determining, by the processing device, a mobile device emulator threshold, wherein a risk indicator greater than the mobile device emulator threshold indicates the target entity is associated with a mobile device emulator.

7. The method of claim 1, wherein the method further comprises: comparing, by the processing device, the risk indicator with a mobile device emulator threshold; based on the comparison, determining, by the processing device, a likelihood that a device associated with the target entity is a mobile device emulator; and transmitting, to the remote computing device, the likelihood as part of the responsive message.

8. The method of claim 1, wherein the entity data comprises data collected by a software- development kit (SDK) integrated in a host application installed on a device associated with the target entity.

9. The method of claim 1, wherein the entity data is received by the processing device in real- time and wherein the risk indicator is updated based on real-time entity data.

10. The method of claim 1, wherein the method further comprises: training, by the processing device, the emulator detection model to determine the risk indicator from the entity data using a training process, wherein the training process includes operations comprising: receiving, by the processing device from a data repository, the training dataset comprising the corpus of attribute data and interaction data, extracting, by the processing device, a plurality of features from the training dataset, and US2008229919481Attorney Docket No.096923-1390989 training, by the processing device, the emulator detection model on the plurality of features.

11. A system comprising: a processor; and a non-transitory computer-readable medium comprising instructions that are executable by the processor to cause the processor to perform operations comprising: receiving a request for a risk indicator of a target entity determined from entity data associated with the target entity, the risk indicator indicating a level of risk associated with the target entity based on whether the target entity is associated with a mobile device emulator; training an emulator detection model to determine the risk indicator from the entity data using a training process, wherein the training process includes operations comprising: receiving, from a data repository, a training dataset comprising a corpus of attribute data and interaction data, extracting a plurality of features from the training dataset, and training the emulator detection model on the plurality of features; generating the risk indicator by applying the entity data to the trained emulator detection model; and providing, to a remote computing device, a responsive message comprising at least the risk indicator to control access to an interactive computing environment.

12. The system of claim 11, wherein the operations further comprise: collecting the entity data over a period of time to generate a sample; and applying the sample to the trained emulator detection model to generate the risk indicator.

13. The system of claim 12, wherein the operations further comprise: receiving a request for the risk indicator associated with the target entity, wherein the request comprises a requested time period; and applying a first sample collected during the requested time period to the trained emulator detection model to generate the risk indicator. US2008229919481Attorney Docket No.096923-1390989 14. The system of claim 11, wherein the attribute data is associated with a device of the target entity and comprises at least one of: battery health data; a battery charging status; or device manufacturer data.

15. The system of claim 11, wherein the interaction data is associated with data indicative of interactions between a device of the target entity and the target entity, and comprises at least one of: interface interaction data; sensor data; or screen time data.

16. A non-transitory computer-readable storage medium having program code that is executable by a processor device to cause the processing device to perform operations comprising: receiving a request for a risk indicator of a target entity determined from entity data associated with the target entity, the risk indicator indicating a level of risk associated with the target entity based on whether the target entity is associated with a mobile device emulator; generating, by the processing device, the risk indicator by applying the entity data to an emulator detection model trained on a training dataset comprising a corpus of attribute data and interaction data; and providing, to a remote computing device, a responsive message comprising at least the risk indicator to control access to an interactive computing environment.

17. The non-transitory computer-readable storage medium of claim 16, wherein the operations further comprise: collecting, by the processing device, the entity data over a period of time to generate a sample; and applying the sample to the trained emulator detection model to generate the risk indicator.

18. The non-transitory computer-readable storage medium of claim 17, wherein the operations further comprise: receiving a request for the risk indicator associated with the target entity, wherein the request comprises a requested time period; and applying a first sample collected during the requested time period to the trained emulator detection model to generate the risk indicator. US2008229919481Attorney Docket No.096923-1390989 19. The non-transitory computer-readable storage medium of claim 16, wherein the attribute data is associated with a device of the target entity and comprises at least one of: battery health data; a battery charging status; or device manufacturer data.

20. The non-transitory computer-readable storage medium of claim 16, wherein the interaction data is associated with data indicative of interactions between a device of the target entity and the target entity, and comprises at least one of: interface interaction data; sensor data; or screen time data. US2008229919481

Citation Information

Patent Citations

  • System and method for detecting bots based on anomaly detection of javascript or mobile app profile information

    US20200112578A1

  • Emulator detection using user agent and device model learning

    US20230084532A1

  • Identification of computerized bots, and identification of automated cyber-attack modules

    WO2017006268A1