System and method for enhanced host classification

Abstract

Certain aspects and features of the present disclosure relate to systems and methods for automatically classifying hosts in real time. For example, classifying hosts as robots and subsequently mitigating or blocking traffic from hosts classified as robots may be advantageous in a real-time data exchange system. In a real-time data exchange system, data may be exchanged in real time between a server and a target host as the target host accesses a web page. Disabling data communications between a server and a host operated by a robot script may reduce fraudulent activity. In some implementations, hosts may be automatically classified into various groups based at least in part on data included in a request received from the host.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. Patent Application No. 16 / 246,137, filed on January 11, 2019, entitled “SYSTEMS AND METHODS FOR ENHANCEDHOST CLASSIFICATION,” the contents of which are incorporated herein by reference in their entirety. Technical Field

[0003] The present disclosure generally relates to systems and methods for classifying hosts in a network environment. More particularly, the present disclosure relates to systems and methods for automatically detecting hosts operated by robot scripts in real time to efficiently manage content distribution in a data exchange system. Background Art

[0004] A cloud-based network can facilitate the exchange of communications for a large number of hosts (e.g., computing devices, machines, servers, bots, users, services, systems, databases, etc.). In addition, a cloud-based network typically uses a single exit point for Internet traffic that leaves the cloud-based network. For example, hosts within a cloud-based network can share Internet Protocol (IP) addresses to communicate with servers outside the cloud-based network. From the perspective of an external server, multiple communications received from different hosts within the cloud-based network can appear as if they were sent from a single host.

[0005] In some cases, a robot script can be configured to mimic a human-operated host for the purpose of performing fraudulent activities. However, when multiple hosts share the same IP address, it is technically challenging to detect which hosts are operated by humans and which hosts are operated by robot scripts. For example, multiple hosts will need to be distinguished, and then the server interaction of each unique host will need to be evaluated separately to determine whether the host is operated by a robot script. When a subset of hosts operated by a robot script share the same IP address, the approach usually taken is to block all hosts from the IP address even if the hosts operated by human users also share the same IP address. Certain technologies have been used to distinguish hosts (e.g., device fingerprint analysis), however, these technologies usually result in classification conflicts, in which two different hosts are classified as the same host. In addition, when hosts share IP addresses, it is technically difficult to distinguish unique hosts because IP addresses are usually used to distinguish hosts. In addition to technical challenges, in data exchange systems, robot detection should occur in real time. However, due to the difficulty in using existing metadata to assist robot detection, real-time automatic detection of robot scripts is usually inaccurate. Summary of the invention

[0006] Certain aspects and features of the present disclosure relate to systems and methods for automatically classifying hosts in real time. For example, classifying hosts as robots and subsequently mitigating or blocking traffic from hosts classified as robots can be advantageous in a real-time data exchange system. In a real-time data exchange system, when a target host accesses a web page, data (e.g., content data, such as advertisements) can be exchanged in real time between a server and a target host. Disabling data communications between a server and a host operated by a robot script can reduce fraudulent activity. In some implementations, hosts can be automatically classified into various groups based at least in part on data included in a request received from the host.

[0007] For illustration and as a non-limiting example only, a host may use the same cloud-based network to share an IP address with multiple other hosts. Some hosts may be operated by robot scripts, and other hosts may be operated by human users. However, when communications are received from multiple hosts at an external server, communications from all hosts may appear to be from a single host because the hosts share the same IP address. According to certain embodiments of the present disclosure, communications from multiple hosts may be automatically and accurately classified into various groups, for example, a first group of hosts operated by human users and a second group of hosts operated by robot scripts. For hosts detected to be operated by robot scripts, data communications may be blocked or mitigated to prevent fraudulent activity.

[0008] In some implementations, the host classification system can be implemented in a real-time data exchange system. The real-time data exchange system can be a programmatic data stream of a demand-side platform that controls the distribution of content between a server and a target host that accesses a specific web page. For example, the real-time data exchange system can manage content distribution by receiving a request to access a specific web page from a target host, identifying one or more content objects that can be displayed in a specific web page, retrieving the one or more content objects from a database, and sending the one or more content objects to the target host so that when a specific web page is loaded on the screen of a specific host, the specific web page displays the one or more content objects. However, in the case where the target host is operated by a robot, it is advantageous to mitigate or prevent content distribution to the target host. Therefore, in some implementations, the host classification system can be configured to be located (in a data stream) between the real-time data exchange system and the target host. The host classification system can initially receive a request to access a web page from the host. In some implementations, the request can include a data string. As a non-limiting example, the data string can be or include a hypertext transfer protocol (HTTP) query string, which includes one or more request parameters (e.g., characteristics) associated with the host, data included in a network packet header sent from the host to a web server to request access to a web page, or any other suitable data. Non-limiting examples of request parameters associated with a host may include a timestamp or uptime since the last device restart, an IP address, a user agent, a browser version, a screen size, and other suitable characteristics. When a request is received from a target host, the host classification system may automatically evaluate the data string to detect whether the target host is operated by a robot script or a human user. In some implementations, evaluating the data string may include accessing one or more rules for determining whether the target host is operated by a robot script or a human user. In some implementations, a rule may include a condition indicating that the target host is detected as being operated by a robot script when the condition is met. As a non-limiting example, a rule may include an executable code that, when executed, evaluates how long it has been since the target host was last restarted by evaluating the run time of the target host (e.g., which may be included in the data string as data). For example, if the run time is less than two seconds (e.g., the run time since the target host was last restarted is 1 second), the rule may indicate that the target host is operated by a robot script (because it is impossible for a human user to have a run time of 1 second before sending a request for a web page). As another non-limiting example, a rule may include executable code that, when executed, evaluates metadata associated with a target host to identify how many web pages the target host has requested access to in the past five minutes.If the number of web pages accessed by the target host in the past five minutes is above a time threshold (e.g., more than 10,000 web pages), the rule may indicate that the target host is detected as being operated by a robot.

[0009] At least partially based on the result of evaluating the data string against one or more rules, the host classification system can classify the target host. In some implementations, if the target host is classified as being operated by a robot script, the host classification system can automatically send a signal to the real-time data exchange system. The signal can include data that when received at the real-time data exchange system, causes or indicates the real-time data exchange system to prohibit, prevent or prevent the content distribution of one or more content objects to the target host. In this case, when the web page is loaded on the target host, one or more content objects will not appear on the web page. On the contrary, if one or more rules indicate that the target host is detected as being operated by a human user, the host classification system can send a signal to the real-time data exchange system. However, in this case, the signal includes data that causes or indicates the real-time data exchange system to continue to send one or more content objects to the target host so that when the web page is loaded on the target host, one or more content objects are included in the web page.

[0010] It should be understood that the present disclosure is limited to accessing web pages. Any other data source or network location may be accessed in a request from a target host. For example, a target host may request an interface page of a local application running on the target host. The real-time data exchange system may manage content distribution of one or more content objects that may be displayed on an interface page within a local application.

[0011] In some implementations, the interaction between the real-time data exchange system and the target host can be recorded in, for example, a log record. The log record can include various data, such as a data string associated with a previous request to access one or more web pages. The host classification system can identify one or more hosts that are detected as being operated by a robot script. For example, the host classification system can identify instances in which the host is detected as having a runtime of 1 second, which would indicate that the host is operated by a robot because a human user cannot start a computer and load a web page within 1 second. The host classification system can then use one or more machine learning techniques and / or artificial intelligence techniques to evaluate the collected log records associated with the host detected as a robot to identify patterns between the runtime values ​​of various log records. Machine learning techniques can include, for example, one or more machine learning algorithms, such as an ensemble of multi-label classifiers (e.g., supervised or unsupervised learning), artificial neural networks (including back propagation, Boltzmann machines, etc.), Bayesian statistics (e.g., Bayesian networks or knowledge bases), logical model trees, support vector machines, information fuzzy networks, hidden Markov models, hierarchical clustering (unsupervised), self-organizing maps, clustering techniques, and other suitable machine learning techniques (supervised, semi-supervised or unsupervised). The pattern of the detected runtime can be used to define new rules used by the host classification system in future host classification. As a non-limiting example, the detected pattern can be a pattern associated with an IP address. The pattern can be that the runtimes of 10 hosts associated with the same IP address are always exactly one second apart from each other. In other words, for each requested web page, the runtimes of the 10 hosts associated with the IP address are received simultaneously and include runtimes that are exactly one second apart (e.g., host #1 has a runtime of 1 second, host #2 has a runtime of two seconds, host #3 has a runtime of three seconds, etc.). Even if the runtimes are different from each other (which implies that the host is the only user), the host classification system can still detect these 10 hosts as being operated by a robot script, because it is unlikely that 10 human users access the same web page at the same time and each of them restarts his or her device at one second apart. Therefore, this new runtime pattern can be used to detect future instances of robot traffic at the real-time data exchange system.

[0012] Certain embodiments relate to a system of one or more computers that can be configured to perform specific operations or actions by installing software, firmware, hardware, or a combination thereof on the system that, in operation, causes the system to perform the actions. One or more computer programs can be configured to perform specific operations or actions by including instructions that, when executed by a data processing device, cause the device to perform the actions. One general aspect includes a computer-implemented method, including: receiving a request to retrieve web page data stored at a server, the web page data corresponding to a web page configured to display one or more content objects (e.g., advertisements), the request corresponding to a data string including one or more request parameters (e.g., the data string may be an http string including request parameters such as device runtime, user agent, browser version, IP address, screen size, etc.), each of the one or more request parameters characterizing a client device, and the one or more request parameters including at least the runtime of the client device; extracting the one or more request parameters included in the data string of the request; accessing one or more rules for detecting whether the client device is operated by a robot script or a human, each of the one or more rules including a condition that, when satisfied, indicates that the client device is operated by a robot script; accessing metadata associated with the client device, the metadata representing one or more previous interactions between the client device and the server. The computer-implemented method also includes automatically determining whether to send a particular content object to the client device, the automatic determination being based on a result of evaluating the one or more rules using the runtime of the client device, the one or more request parameters, and / or the metadata associated with the client device. The computer-implemented method further comprises sending the specific content object in response to determining that the specific content object is to be sent to the client device, the sending of the specific content object indicating that the client device is detected as being operated by a human. Other embodiments of this aspect include corresponding computer systems, apparatuses, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the method.

[0013] A general aspect includes a system, including: one or more data processors; and a non-transitory computer-readable storage medium containing instructions, which, when executed on the one or more data processors, cause the one or more data processors to perform operations including. The system also includes receiving a request to retrieve web page data stored at a server, the web page data corresponding to a web page configured to display one or more content objects, the request corresponding to a data string including one or more request parameters, each of the one or more request parameters characterizing a client device, and the one or more request parameters at least including a runtime of the client device. The system also includes extracting the one or more request parameters included in the data string of the request. The system also includes accessing one or more rules for detecting whether the client device is operated by a robot script or a human, each of the one or more rules including a condition that indicates that the client device is operated by a robot script when satisfied. The system also includes accessing metadata associated with the client device, the metadata representing one or more previous interactions between the client device and the server. The system also includes automatically determining whether to send a particular content object to the client device, the automatic determination based on a result of evaluating the one or more rules using the runtime of the client device, the one or more request parameters, and / or metadata associated with the client device. The system also includes sending the specific content object in response to determining that the specific content object is to be sent to the client device, the sending of the specific content object indicating that the client device is detected as being operated by a human. Other embodiments of this aspect include corresponding computer systems, apparatuses, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the method.

[0014] One general aspect includes a computer program product tangibly embodied in a non-transitory machine-readable storage medium, including instructions configured to cause a data processing device to perform operations, the operations including: receiving a request to retrieve web page data stored at a server, the web page data corresponding to a web page configured to display one or more content objects, the request corresponding to a data string including one or more request parameters, each of the one or more request parameters characterizing a client device, and the one or more request parameters including at least a runtime of the client device; extracting the one or more request parameters included in the data string of the request; accessing one or more rules for detecting whether the client device is operated by a robot script or a human, each of the one or more rules including a condition that indicates that the client device is operated by a robot script when satisfied; accessing metadata associated with the client device, the metadata representing one or more previous interactions between the client device and the server. The computer program product also includes automatically determining whether to send a specific content object to the client device, the automatic determination being based on a result of evaluating the one or more rules using the runtime of the client device, the one or more request parameters, and / or the metadata associated with the client device. The computer program product also includes sending the specific content object in response to determining to send the specific content object to the client device, the sending of the specific content object indicating that the client device is detected as being operated by a human. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the method.

[0015] Advantageously, in situations where multiple hosts communicate with a server from a shared IP address, certain embodiments of the present disclosure may be used to identify which of the multiple hosts are unique (e.g., by evaluating the uptime of each host, which may be a reliable indicator for distinguishing between hosts). In addition, the unique hosts and their corresponding interactions with the real-time data exchange system may be evaluated to determine whether each host is operated by a robot. For hosts detected as being operated by a robot, the real-time data exchange system may automatically block content distribution to the detected robot user in conjunction with a request by the robot user to access a web page. Additionally, in situations where multiple hosts share an IP address, but only some of those hosts are operated by robot scripts (e.g., the rest are operated by human users), certain embodiments related to the technical solution for detecting robots are very advantageous. In some implementations, uptime (e.g., the amount of time since the last device restart) may be evaluated, along with additional metadata and one or more rules associated with the host, to detect robot users and prevent their access to content. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] This description refers to the following drawings, in which the same reference numerals in different drawings are intended to indicate the same or similar components.

[0017] Figure 1 is a block diagram illustrating an example network environment for device classification according to an embodiment of the present disclosure.

[0018] Figure 2 is a block diagram illustrating another example network environment for device classification according to an embodiment of the present disclosure.

[0019] Figure 3 is a block diagram illustrating yet another example network environment for device classification according to an embodiment of the present disclosure.

[0020] Figure 4 is a flow chart illustrating an example process for device classification according to an embodiment of the present disclosure.

[0021] Figure 5 is a simplified diagram showing a distributed system for implementing one of the embodiments.

[0022] Figure 6 is a simplified block diagram illustrating one or more components of a system environment.

[0023] Figure 7 An exemplary computer system is shown in which various embodiments of the invention may be implemented. DETAILED DESCRIPTION

[0024] In the following description, for the purpose of explanation, specific details are set forth to provide a thorough understanding of the embodiments of the present invention. However, it will be apparent that various embodiments can be practiced without these specific details. The drawings and descriptions are not intended to be limiting.

[0025] Typical host classification (e.g., device fingerprinting) may result in classification conflicts, where two different hosts are incorrectly classified as a single host. According to certain embodiments of enhanced host classification, the interaction between the server and the host can be evaluated by analyzing the data available in the network packet header sent by the host. For example, the data included in the network packet header (e.g., a request to access a web page) may include a running time (e.g., a time value or a trusted third party (TTP) timestamp) indicating how long the device (e.g., a device as a host, such as a user device, a computer, a server, etc.) has been running since the device was last restarted. When evaluating multiple hosts sharing the same IP address, the running time of each host can be a reliable indicator to distinguish unique hosts. In addition, the running time of the host can also be evaluated to determine whether the host is a robot. For example, if the host is requesting access to a web page, but the network packet header and / or HTTP query string received from the host indicates that the running time of the host is one second, the host can be accurately classified as being operated by a robot because a human user cannot restart the computer and load a web page in one second.

[0026] In some implementations of the embodiments described herein, the runtime of a set of hosts may be evaluated to identify which subset of the hosts are detected as being operated by a robot script and which subset of the hosts are detected as being operated by a human user. In addition, in some implementations, a host classification system may be provided in a data flow between a real-time data exchange system (e.g., a real-time bidding programmatic flow of a demand-side platform or ad exchange) and a target host (e.g., a host requesting access to a web page or application interface). The real-time data exchange system may send one or more content objects (e.g., advertisements) to the target host in response to the target host's request to access a web page or application.

[0027] By prohibiting the distribution of content to hosts that are detected as robot scripts that mimic human users, fraudulent activity can be prevented. In some embodiments, the host classification system can evaluate available data in the header of network packets received from the target host to indicate whether the real-time data exchange system should send one or more content objects to the target host. If the host classification system classifies the target host as being operated by a robot script, the host classification system can advantageously prohibit the real-time data exchange system from sending the one or more content objects to the target host in real time when the web page is loaded on the target host. Because the host classification system evaluates available data (e.g., runtime) in the header of network packets received from the target host, the host classification system can make real-time decisions about whether the target host should receive the one or more content objects.

[0028] In some embodiments, the host classification system may receive one or more signals from a target host accessing one or more web pages. When a host is the target of a decision to receive one or more content objects that can be displayed on a web page, the host may be referred to as a target host. One or more signals may include a request to access a specific web page. The request may be represented by one or more network packet headers (e.g., HTTP streams) sent from the target host. In addition, one or more network packet headers may include a trusted third party (TTP) timestamp indicating the most recent time the host was restarted. Certain embodiments of the present disclosure may evaluate a TTP timestamp (also referred to herein as an uptime, which is the difference between the current time and the TTP timestamp representing the amount of time since the last restart) to help identify a unique host (e.g., a machine, a computer device, a server, etc.) behind the same IP address. In the absence of a TTP timestamp, multiple hosts may typically look like a single host because multiple hosts share the same IP address.

[0029] In some cases, the same IP address used by different machines to access the Internet can sometimes be a proxy service, a service that intentionally obfuscates the source of a website's web traffic. In some cases, the same IP address may be used by all computers within an institution, such as a university or library network. In other cases, several hosts, such as laptops and smart TVs, can access the Internet using the same home IP address. However, TTP timestamps can be evaluated to track signals from different hosts accessing the Internet behind the same IP address.

[0030] In some cases, if a group of hosts are behind the same IP address, a first subset of the group of hosts may be operated by human users, and a second subset of the group of hosts may be operated by robot scripts. In these cases, if the IP address is associated with robot traffic (and is therefore blacklisted), all hosts associated with the IP address are typically blocked, resulting in human users being blocked from accessing content. Alternatively, if the IP address is not blocked, all hosts associated with the IP address are distributed content by a real-time data exchange system, thereby causing fraudulent activity by providing content to robots. Therefore, IP addresses alone are not sufficient to mitigate or prevent robot traffic. However, according to certain embodiments of the present disclosure, available data in a network packet header received from a host (e.g., a runtime value included in an HTTP stream) may be evaluated to enable a host classification system to make real-time decisions about whether to send a content object to a given target host. For example, if the runtime value of a given target host is below a certain time threshold, the target host may be detected as being operated by a robot script and is therefore blocked from receiving one or more content objects. As a non-limiting example, a host classification system may sit in the bidding stream of an ad exchange to make real-time decisions on behalf of advertisers about whether to purchase ads for a target web page visitor. Advantageously, rather than blocking content for all hosts behind an IP address associated with bot traffic, or serving content to all hosts behind an IP address associated with bot traffic in order to reach a human user, certain embodiments of the present invention may differentiate between hosts and serve content to each host associated with the same IP address on a per-host basis.

[0031] In some embodiments, the host classification system can access metadata associated with the host. Metadata can be collected for various hosts that access one or more web pages. For example, when a host accesses a web page, the web page (and potential appendages of the web page) can collect metadata associated with the host. For example, the metadata can be collected in a log record, and the log record can contain any data that can be detected from the host's interaction with the web page. Non-limiting examples of metadata that can be collected include the number of times a web page is accessed, the timestamp of each instance of accessing a web page, the web page previously accessed, the number of times the previous web page was accessed, the data included in the network packet header of each instance of accessing a web page, the running time of each instance of accessing a web page, the IP address associated with each host interaction, and any other suitable data.

[0032] Thus, even if a network proxy modifies the runtime included in the network packet header from a host to intentionally obfuscate the true runtime of the host, these modifications may be detected by the host classification system. As a non-limiting example, if the host classification system detects that metadata collected for a particular host indicates that the particular host visited 1,000 web pages within a 5 minute window, and if each visit to the web page is associated with the same runtime, the host classification system may determine that the IP address is associated with the network proxy, and that the network proxy modifies the network packet header to intentionally obfuscate the real-time data exchange system.

[0033] In some embodiments, the host classification system may evaluate network packet headers received from the IP address to determine whether the IP address exhibits runtime continuity. For example, at a given time A, the host classification system may evaluate the runtimes of various network packet headers received from IP address 123 during a time window and determine that IP address 123 is associated with 10 unique hosts (e.g., because there are 10 unique runtimes within the time window). As another example, if at a given later time B, the host classification system again evaluates the runtimes of various network packet headers received from IP address 123 during a different time window, but determines that IP address 123 is associated with 10,000 unique hosts (e.g., because there are 10,000 unique runtimes), the host classification system may determine that IP address 123 is likely to be a network proxy that obfuscates robot traffic. In this example, the 10 unique hosts detected at time A are inconsistent with the 10,000 unique hosts detected at time B, and therefore, the IP address may be detected as being associated with robot traffic.

[0034] The host classification system can generate a score for each target host that accesses a web page. In addition, the host classification system can evaluate the score to determine whether to send a content object to the target host. The score can be calculated independently for each host associated with the same IP address. In some embodiments, the score can be generated based at least in part on the IP address, the running time of the target host, and / or a combination thereof. The IP address combined with the running time of the target can correspond to the fingerprint of the target host. In some embodiments, the score can represent the extent to which the host may be operated by a human user. Generating a score (e.g., a human user score) for a client device can include evaluating one or more rules, one or more request parameters, and / or metadata associated with the client device using the running time of the client device. In addition, the human user score can represent the extent to which the client device is detected as being operated by a human. In addition to other data, the human user score can be evaluated to determine whether to send a specific content object to the client device. As a non-limiting example, the score can be generated as a conversion value, so that the more metadata indicating that the host is likely to be operated by a human, the higher the score, and the less metadata indicating that the host is likely to be operated by a human, the lower the score (vice versa, so that the lower the score, the higher the possibility that the user is likely to be human).

[0035] It should be understood that the present disclosure is not limited to real-time robot detection. In some embodiments, an offline learner can evaluate data collected from target hosts for each IP address to identify patterns associated with hosts that are classified as robots for a given IP address. As a non-limiting example, patterns associated with hosts classified as robots may include the host loading a web page once a minute using the IP address, loading once a minute for 10 consecutive days, the host accessing 12 websites simultaneously within one second, or the host loading web pages in English, Turkish, and Japanese within a short period of time (e.g., one to five seconds). The above example patterns will be associated with hosts operated by robot scripts because human users cannot browse the Internet using these patterns. The runtime of each interaction can be used to distinguish hosts so as to eliminate false negatives and false positives in robot classification.

[0036] In some embodiments, one or more rules may be defined to detect robots. The rules are represented by data indicating conditions. In some embodiments, the conditions of the rules may be used to evaluate metadata associated with the target host. If the metadata meets the conditions, the rule may indicate that the target host is operated by a robot script (or a human user). As a non-limiting example, a rule may be defined to evaluate the number of web pages accessed by the target host within a time window (e.g., a rolling five-minute window) and the runtime of each web page request. For example, if the metadata associated with the target host indicates that the number of web pages accessed is large (e.g., indicating that the host is likely to be operated by a robot script because the number of web pages accessed is large, such as 25 web pages within a five-minute window), but if the runtime of each request is above a time threshold (e.g., indicating that the host is likely to be operated by a human because the host has a long runtime), the host classification system may classify the host as being operated by a human. In addition, if the number of web pages accessed within the rolling time window is small (e.g., indicating that the host is likely to be operated by a human), but if the run time per request is below a time threshold (e.g., indicating that the host is likely to be operated by a robot script, because in some cases, very short run times are unlikely unless a robot is operating the host), then the host classification system may classify the host as being operated by a robot script. It should be understood that the above rules and corresponding conditions are exemplary, and thus the present disclosure is not limited thereto. Any combination of run time and time thresholds of accessed web pages may be defined to detect hosts operated by robots and / or humans.

[0037] In some embodiments, the host classification system can identify a group of hosts representing examples of hosts that are detected as being operated by a robot script. The host classification system can then use, for example, one or more machine learning techniques to evaluate the characteristics associated with the identified group of hosts. As a non-limiting example, the host classification system can identify that 100 hosts have each requested access to 10,000 or more web pages in the past five minute window. Since the number of web pages accessed in a short period of time is extremely large (for example, 10,000 web pages accessed may exceed the threshold associated with detecting robots), the host classification system can determine that the 100 hosts are operated by a robot script. In addition, the host classification system can retrieve metadata associated with the group of 100 hosts. Then, the host classification system can use one or more machine learning techniques to evaluate the metadata associated with the 100 hosts. In some embodiments, the machine learning algorithms or techniques used for the context model may include an ensemble of multi-label classifiers (e.g., supervised learning), artificial neural networks (including back propagation, Boltzmann machines, etc.), Bayesian statistics (e.g., Bayesian networks or knowledge bases), logical model trees, support vector machines, information fuzzy networks, hidden Markov models, hierarchical clustering (unsupervised), self-organizing maps, clustering techniques, and other suitable machine learning techniques (supervised, semi-supervised or unsupervised learning). For example, the host classification system may execute one or more machine learning algorithms (e.g., such as clustering techniques) to evaluate the runtime included in the network packet header for each of the 10,000 web pages accessed within a five-minute window to identify patterns in the runtime of hosts operated by robots. For example, the runtimes included in web page requests from a group of robots may be spaced apart in time at constant increments, such as 5 seconds apart. The host classification system may then define rules for evaluating the runtimes of the group of hosts, and if the host classification system detects that a group of hosts corresponds to runtimes that are each 5 seconds apart from each other, the host classification system may determine that the group of hosts is likely to be operated by a robot.

[0038] As a non-limiting example, if 10 or more web pages are detected to be accessed from the same IP address within one second, it can be determined that the source of these web page requests is a robot. However, advantageously, according to certain embodiments of the present disclosure, the host classification system can avoid false positives of detected robots by evaluating the runtime associated with the 10 requests. For example, 10 or more different human users who may operate a device may request 10 or more web pages from a cloud-based network configured with one exit point (e.g., all traffic leaving a single exit point will share the same IP address) within one second. In an organization with thousands of employees, there may be 10 or more employees accessing the same web page at the same time. In this example, the 10 or more web page requests associated with the same IP address are not actually from a robot. The host classification system can avoid such false positives by evaluating the runtime included in the network packet header of each of the 10 or more web page requests. For example, if the host classification system detects a diversity of run times (e.g., all 10 run times are different from each other and there is no detectable pattern between the 10 run times), the host classification system can determine that the 10 or more web pages are sent by a host operated by a human user, thereby avoiding false positive detection of a robot. On the contrary, if the host classification system detects that the run time of each of the 10 or more web pages is exactly the same, the host classification system can determine that the source of the 10 or more web page requests is a host operated by a robot script.

[0039] In some embodiments, data available in the network packet header representing each request to access a web page can be recorded in a log. Logging requests to access a web page can cause one or more characteristics of the host issuing the request and / or the requested web page to be recorded. Non-limiting examples of characteristics that can be recorded in a log message include the IP address of the request, the user agent, how long the web page was accessed, the device uptime, the screen size, whether the host is using a physical monitor, and other suitable characteristics.

[0040] In some embodiments, metadata may be associated with a host. For example, metadata may be collected from a host over time and stored in one or more databases accessible to a host classification system. Examples of metadata for a host may include data collected from interactions between one or more web servers or application servers and the host (e.g., data available from network packet headers of all web pages received from a particular host, such as elapsed time, may be stored as metadata), the host's browsing history, characteristics of the browsing session (e.g., how long the host stayed on each web page, which content objects (such as advertisements) were viewed and / or selected by the host), and other suitable metadata.

[0041] In some implementations, the host classification system can detect the same robot over time, even if the host has been rebooted. For example, the host classification system can create a link between a newly detected robot (which has a shorter runtime due to a recent device reboot) and a previously detected robot to indicate that the two detected robots are the same robot. Each host can be associated with certain metadata collected over time from the host's interactions with a web server or application server (e.g., the host's web page requests). The metadata can include certain characteristics of the host, such as the host's IP address, web pages previously visited by the host, the runtime of the host's web page requests, the user agent, and other suitable metadata. The host classification system can evaluate the detected robots (e.g., detected over a period of time) and identify (e.g., using a similarity score or confidence threshold) two or more detected robots with similar metadata, even if the two detected robots are associated with different runtimes. If the metadata of one robot corresponds to the metadata of another robot, but if the runtimes of the two robots are different, the robots may have been rebooted. In some implementations, to perform the linking between detected robots, the host classification system can perform one or more clustering techniques on the runtimes of hosts using a particular IP address. Clustering can result in identifying unique runtimes, which are then associated with unique devices.

[0042] It should be appreciated that detecting a newly reset host (e.g., detecting a host with a short uptime (such as two seconds)) allows the host classification system to determine whether to link metadata previously associated with the host (e.g., metadata collected from previous interactions with known hosts) with newly collected metadata about the host (e.g., metadata collected during a current browsing session with the host). Linking metadata previously associated with the host with newly collected metadata about the host indicates host continuity. For example, each time the host classification system detects a host with a short uptime (e.g., four seconds), the host classification can determine whether to use the most recently collected metadata about the host to evaluate existing metadata about the host to link the detected host with one or more known hosts (e.g., hosts detected as being operated by a human), or whether to classify the detected host as a bot. Advantageously, detection of a host with a low uptime value can enable the host classification system to determine whether the short uptime is due to a legitimate device reset by a human user, or whether to classify the host as a bot. If the host classification system determines that the evaluation low uptime is due to a reasonable reset by a human user, the host classification system may link identification metadata previously associated with the host with metadata currently or recently collected about the host during the current browsing session so that the host is not classified as a robot, but rather the host is linked to a host previously known to be operated by a human user.

[0043] It should be understood that the detection of the host may include generating a unique identifier (e.g., a device fingerprint) to uniquely represent the host. Generating a unique identifier for the host may include extracting one or more timestamps embedded in one or more network packets received from the host. The timestamps embedded in one or more network packets may be evaluated by the host classification system to infer the "device uptime" (also referred to herein as "uptime") of the host. For example, the "device uptime" may represent the amount of time that has passed since the last reboot of the host. In some examples, the unique identifier potentially generated using at least in part (one or more) embedded timestamps may be stored in a first-party cookie in a separate website domain. Advantageously, the "device uptime" of the host can be used to individually identify multiple hosts that share the same IP address (e.g., due to the natural randomness of rebooting hosts in a network). In addition, the "device uptime" can be used in a first-party cookie cache to generate a unique identifier, although a host power-off event will reset the "device uptime" and otherwise result in a reset of the unique identifier. Certain metadata (e.g., IP address, browser version, uptime, etc.) may be generated or extracted based on interaction with the host. In some embodiments, processing multiple metadata inputs to generate a unique identifier may involve a double hashing technique that combines 1) a cryptographic hash that can uniquely identify hosts associated with different metadata, and 2) a locally sensitive hash that can intentionally result in matching / similar identifiers for inputs where a small amount of metadata is different (such as a "device uptime" reset caused by a reboot of the host). When two hosts have unique cryptographic hash values, but have the same locally sensitive hash, a second step may be performed to determine whether the two unique cryptographic hash values ​​represent the same host, such as a single host that has undergone a change in the input metadata. As a non-limiting example, if only the "device uptime" has changed, the new uptime should be less than the time since the host was last detected by the web server or host classification system. If a host that matches the original uptime is detected again by the web server or host classification system, the host classification system can infer that the smaller uptime represents a new host and that the host with the original uptime has not actually been rebooted. Similar techniques can be used to match hosts with IP address changes when the host accesses a new network, because hosts often log in to the same network regularly (e.g., work, home, etc.). Finally, persisting these hashes to storage within the first-party domain accessible to the host classification system enables the host classification system to store metadata and combine identifiers across metadata changes, even if the metadata changes are too significant for the above matching techniques. For example, an "alias" table can be stored locally within the host, as well as within the host classification system.In some embodiments, data stored in the host-side storage device can be encrypted so that the host classification system can access the stored metadata and enable the host classification to securely generate unique identifiers for individual hosts despite changes in metadata associated with the host, as described above.

[0044] Figure 1 An example network environment 100 for detecting hosts operated by robot scripts to manage content distribution in real time is shown. In some embodiments, the network environment 100 may include a user device 110, a web server 120, a host classification system 130, and a data exchange platform 150. Although the user device 110 is shown as a mobile phone, it should be understood that the user device 110 can be any host that accesses the web server 120. The user device 110 can be operated by a human or a robot script configured to mimic a human user. In addition, the user device 110 can send a request to access a web page stored at the web server 120 (via one or more wired or wireless networks). For example, a user may be operating a mobile browser on the user device 110, and the user can enter a web page address into the mobile browser, causing the request to be sent to the web server 120. The web page associated with the web page address can include any content, including but not limited to one or more content objects (e.g., advertisements). In some embodiments, the content object can be stored at a data source independent of the web server 120 (e.g., at a third-party data source or server). The content object web server 120 can be a server that hosts the web page requested by the user device 110. It should be understood that the present disclosure is not limited to requesting access to a web page. For example, an application server hosting a local or web application can be used instead of the web server 120. In this example, robot detection will occur for hosts requesting access to an application hosted by the application server.

[0045] The host classification system 130 may include one or more servers or processors configured to execute executable code. The host classification system 130 may also include a memory to store data, such as executable code, results of executed functions included in the executable code, data retrieved from other data sources, etc. The executable code, when executed, may perform any method, algorithm, function, process, or technique described herein (e.g., Figure 4 In some implementations, host classification system 130 may determine in real time whether data exchange platform 150 should send a content object to a host accessing a particular web page.

[0046] When the user device 110 requests access to the web server 120, the web server 120 may relay or forward the network packet header received from the user device 110 to the host classification system 130 to determine whether the user device 110 is likely to be operated by a human user or a robot script. Then, the host classification system 130 may evaluate whether the user device 110 is operated by a human or a robot script based at least in part on the available data in the network packet header (e.g., the running time and IP address of the user device 110). For example, the host classification system 130 may compare the running time included in the network packet header received from the user device 110 with a threshold to determine whether the running time represents an actual value. For example, a running time of one second is unlikely to exist in a network packet header from a human-operated host because it is impossible to restart a computer and load a browser using a web page within one second. In some embodiments, the host classification system 130 may access an internal or external data source 140 (which may be any number of data sources) to retrieve metadata associated with the user device 110. Metadata (as described in more detail herein) may represent previous interactions between the user device 110 and the web server 120. For example, the metadata may include available data from a network packet header of a previous web page request sent from the user device 110 to the web server 120. In addition, the metadata may include one or more identifying information (e.g., IP address, uptime, device characteristics, cookie data, etc.) that can be used to identify the user device 110. The host classification system 130 may evaluate the metadata associated with the user device and / or the data available in the network packet header received from the user device 110 to determine whether the user device is operated by a human or a robot. For example, the host classification system may determine whether the uptime value included in the network packet header from the user device 110 is below a threshold (e.g., a short threshold of one second). If the uptime value is below the threshold, the host classification system 130 may determine that the user device 110 is likely to be operated by a robot script, while if the user device 110 is above a different threshold (e.g., a long threshold of 15 minutes), the host classification system 130 may determine that the user device 110 is likely to be operated by a human. When the host classification system 130 determines that the user device 110 is operated by a robot script, the host classification system 130 may send a signal to the data exchange platform 150, which causes the data exchange platform 150 to prohibit sending one or more content objects to the web server 120. However, when the host classification system 130 determines that the user device is operated by a human, the host classification system 130 may send a signal to the data exchange platform 150, which causes the data exchange platform 150 to send one or more content objects to the web server 120, so that when the web page is loaded on the user device 110, the web page will include the one or more content objects.

[0047] The data exchange platform 150 may include one or more servers or processors configured to execute executable code. The data exchange platform 150 may also include a memory to store data, such as executable code, results of functions executed in the executable code, data retrieved from other data sources, etc. The executable code, when executed, may perform any of the methods, algorithms, functions, processes, or techniques described herein, or any portion thereof. In some embodiments, the data exchange platform 150 may send one or more content objects to the web server 120 whenever a host requests access to a web page hosted by the web server 120. The data exchange platform 150 may retrieve one or more content objects from the content object data source 160. However, since the content objects are intended for hosts operated by human users, the host classification system 130 may instruct the data exchange platform 150 to prohibit sending content objects to hosts detected as being operated by robot scripts.

[0048] Figure 2 An example network environment 200 for detecting hosts operated by robot scripts to manage content distribution in real time is shown. The host classification system 130 can detect that the user device 110 is requesting access to a web page (e.g., hosted by the web server 120). For example, the signal 220 can notify the host classification system 130 that the user device 110 is requesting access to the web page. In addition, in some embodiments, the signal 220 can include metadata associated with the user device 110. In some embodiments, the signal 220 can include an identifier of the user device 110, which can be used to query one or more databases storing metadata associated with the user device 110. For example, the signal 220 can include data available in one or more network packet headers sent from the user device 110 to the web server hosting the requested web page. Similarly, the host classification system 130 can detect that the host 210 is requesting access to the web page. For example, the signal 230 can notify the host classification system 130 that the host 210 is requesting access to the web page. In addition, in some embodiments, the signal 230 can include metadata associated with the host 210. In some implementations, signal 230 may include an identifier of host 210 that may be used to query one or more databases storing metadata associated with host 210. For example, signal 230 may include data available in one or more network packet headers sent from host 210 to a web server hosting the requested web page.

[0049] The host classification system 130 may evaluate the metadata included in the signal 220 to determine whether the user device 110 is likely to be operated by a robot script. For example, the host classification system 130 may evaluate the runtime (e.g., a timestamp indicating the time when the user device 110 was last restarted) to determine whether the user device 110 is operated by a robot script. As a non-limiting example, if the runtime included in one or more network packet headers from the user device 110 indicates that the user device 110 was last restarted one second ago, the host classification system 130 may determine that the user device 110 is likely to be operated by a robot script. In this example, the host classification system 130 may retrieve (e.g., from an internal or external data source 140) one or more rules for detecting robots and compare the runtime to the one or more rules. For example, the rule may include a condition representing a threshold time (such as a threshold runtime of one second) that is too fast for a human user to complete. In other words, for a human user, restarting the host (e.g., user device 110) and starting to load a web page on a browser within a timestamp of one second of the restart will be too fast to complete. Thus, the host classification system 130 may detect that a host with a device that has a latency below one second may be operated by a robot script.

[0050] In some embodiments, the host classification 240 may be data output by the host classification system 130 after evaluating one or more network packet headers and / or metadata associated with the user device 110 and the host 210. The host classification 240 may be sent to the data exchange platform 150 as a notification of a robot detection result. For example, the host classification 240 may include data indicating that the host 210 is detected as a robot or the user device 110 is detected as being operated by a human. In some embodiments, the host classification 240 may be a signal with instructions to enable or disable the sending of content objects to a host that is requesting access to a web page. For example, if the host classification system 130 detects that the host 210 is being operated by a robot script, the host classification 240 may be a signal sent to the data exchange platform 150 such that the signal includes instructions to disable the sending of content objects to the host 210 (associated with the host 210's request to access a web page). Therefore, when the host 210 loads the web page, the web page will not include data representing one or more content objects.

[0051] Figure 33 is a block diagram showing a network environment 300 for classifying a host according to an embodiment of the present disclosure. The network environment 300 may include a web server 120, a host classification system 130, and a data exchange platform 150. The data exchange platform may communicate with the web server 120 and / or the host classification system 130 through one or more networks. When the host communicates with the web server 120 to request access to a web page, the web server 120 communicates with the data exchange platform 150 to request that one or more content objects be displayed on the web page. As a non-limiting example, the web server 120 may request one or more advertisements from the data exchange platform 150 so that the web server 120 may cause the one or more advertisements to be displayed on a web page loaded on the host browser. Advertisers may be charged a fee for each instance in which an advertisement is displayed on a web page, and therefore, it is advantageous to prevent advertisements from being displayed on web pages accessed by robots. The content object 310 may be data (e.g., image data, video data, and / or audio data) that may be presented on a web page, such as an advertisement.

[0052] In some implementations, host classification system 130 is located in the communication flow between web server 120 and data exchange platform 150. Host classification system 130 can detect whether a host is operated by a robot based at least in part on one or more request parameters (e.g., characteristics or data items) included in a network packet header received from the host. Host classification system 130 can instruct data exchange platform 150 to enable or disable sending a content object to the host for display on a web page.

[0053] like Figure 3 As shown in the example of , user device 110 may request access to a web page hosted by web server 120. User device 110 may send one or more network packet headers to web server 120 requesting access to the web page. When receiving the one or more network packet headers from user device 110, web server 120 may send or relay the one or more network packet headers to host classification system 130 for robot detection. The one or more network packet headers from user device 110 may include data associated with user device 110 and / or a request from user device 110. For example, the one or more network packet headers may include, but are not limited to, the running time of user device 110 (e.g., a timestamp indicating the last time when user device 110 was restarted), the operating system running on user device 110, the screen size, browser version, IP address connected to user device 110, and other suitable examples. Similarly, host 210 may request access to a web page hosted by web server 120. Web server 120 may also send or relay one or more network packet headers from host 210 to host classification system 130 for robot detection.

[0054] The host classification system 130 can evaluate the network packet header from the user device 110 to determine whether the data exchange platform 150 should send the content object 310 to the web server 120 for display on the web page requested by the user device 110. For example, the host classification system 130 can determine that the available data in the network packet header from the user device 110 indicates that the user device 110 is likely to be operated by a human user. In this example, one or more network packet headers may include the operating time of the user device 110. The host classification system 130 can apply one or more rules to the available data in the network packet header from the user device 110 to determine that the user device 110 is likely to be operated by a human. For example, the rule may include a threshold time for comparison with the operating time of the user device 110. The operating time of the host exceeding the threshold time may indicate the possibility that the host is operated by a human (e.g., because the operating time is long enough). Therefore, at the result 320, the host classification can determine (in real time based on the network packet header) that the user device 110 is likely to be operated by a human. Thus, when a web page is loaded on a browser of a user device 110, data exchange platform 150 may send content object 310 to web server 120 for display on the web page.

[0055] Similarly, host classification system 130 may evaluate network packet headers from host 210 to determine whether data exchange platform 150 should send content object 310 to web server 120 for display on a web page requested by host 210. For example, host classification system 130 may determine that available data in network packet headers from host 210 indicates that host 210 is likely to be operated by a robot script. In this example, one or more network packet headers may include an uptime of host 210. Host classification system 130 may apply one or more rules to available data in network packet headers from host 210 to determine that host 210 is likely to be operated by a robot script. For example, similar to the above example, a rule may include a threshold time for comparison with the uptime of host 210. The uptime of the host being below the threshold time may indicate the possibility that the host is operated by a robot script (e.g., because the uptime is too short to be practical, such as a one-second threshold). Therefore, at result 330, data exchange platform 150 may prohibit content object 310 from being sent to web server 120. Therefore, when the web page is loaded on the browser of the host 210, the web page will not display the content object 310. The present disclosure is not limited to the evaluation of the runtime value of the host, and therefore, it should be understood that any data can be used for robot detection performed by the host classification system 130.

[0056] Figure 44 is a flow chart illustrating a process for detecting robots in real time. Process 400 may be performed in full or at least in part by any of a host (e.g., user device 110), a web server (e.g., web server 120), a host classification system (e.g., host classification system 130), and a data exchange platform (e.g., data exchange platform 150). In addition, process 400 may be performed to detect hosts operated by robots in real time based on available data in network packet headers (e.g., without downloading any code (such as JavaScript) on the host's browser to generate a signal for robot detection). Process 400 may be used to generate a robot detection result used by the data exchange platform to determine whether to send one or more content objects to the host for display on a web page.

[0057] Process 400 begins at block 410, where a web page request is received from a host. The web page request may be a request generated by a browser running on the host. For example, in response to receiving an input corresponding to a web page address at a browser, the browser may generate a web page request that is sent to a corresponding web server. At block 420, one or more request parameters may be extracted from the available data in the web page request. Non-limiting examples of request parameters may include data elements in a data string (e.g., an HTTP query string), host characteristics included in one or more network packet headers, such as an IP address, device runtime, device type (e.g., mobile or desktop), user agent, and any other suitable data. At block 430, one or more rules may be accessed for detecting robots. For example, a rule may include a condition that, once satisfied, indicates that the host is operated by a robot. According to an embodiment, satisfying the condition may also indicate that the host is operated by a human. At block 440, metadata associated with the host may be accessed. For example, metadata representing previously recorded interactions between a host and one or more web servers may be stored at a database and subsequently retrieved during host classification or robot detection.

[0058] At box 450, the host classification system may evaluate available data in one or more network packet headers, accessed rules, and / or retrieved metadata to determine whether the host is likely to be operated by a robot script. If the host classification system determines that the host is likely to be a robot, process 400 proceeds to box 470, where the data exchange platform prohibits sending the content object to the host or web server. Conversely, if the host classification system determines that the host is likely to be operated by a human, process 400 proceeds to box 460, where the data exchange platform sends the content object to the host or web server so that when the web page is loaded on the host, the web page will contain the content object. It should be understood that according to certain embodiments described herein, one or more steps of process 400 may be selectively performed and / or Figure 4 The order of the steps in can be rearranged while still performing robot detection.

[0059] Figure 5 A simplified diagram of a distributed system 500 for implementing one of the embodiments is depicted. In the illustrated embodiment, the distributed system 500 includes one or more client computing devices 502, 504, 506, and 508 configured to execute and operate client applications, such as web browsers, proprietary clients (e.g., Oracle Forms), etc., over a network(s) 510. A server 512 can be communicatively coupled to the remote client computing devices 502, 504, 506, and 508 via the network 510.

[0060] In various embodiments, server 512 may be adapted to run one or more services or software applications provided by one or more components of the system. In some embodiments, these services may be provided to users of client computing devices 502, 504, 506, and / or 508 as web-based services or cloud services or under a software as a service (SaaS) model. Users operating client computing devices 502, 504, 506, and / or 508 may then interact with server 512 using one or more client applications to utilize the services provided by these components.

[0061] In the configuration depicted in the figure, software components 518, 520, and 522 of system 500 are shown as being implemented on server 512. In other embodiments, one or more components of system 500 and / or the services provided by these components may also be implemented by one or more of client computing devices 502, 504, 506, and / or 508. Users operating client computing devices can then use the services provided by these components using one or more client applications. These components may be implemented in hardware, firmware, software, or a combination thereof. It should be understood that various different system configurations that may be different from distributed system 500 are possible. Therefore, the embodiment shown in the figure is an example of a distributed system for implementing an embodiment system and is not intended to be limiting.

[0062] Client computing devices 502, 504, 506, and / or 508 may be portable handheld devices (e.g., Cellular phone, computing tablets, personal digital assistants (PDAs), or wearable devices (e.g., Google head mounted display) that runs a computer such as Microsoft Windows and / or multiple mobile operating systems (such as iOS, Windows Phone, Android, BlackBerry 10, Palm OS, etc.) and enable Internet, email, short message service (SMS), or other communication protocols. The client computing device may be a general-purpose personal computer, including, for example, running various versions of Microsoft Apple The client computing device can be a personal computer and / or laptop computer running a variety of commercial or any workstation computer running any of the UNIX-like operating systems, including but not limited to various GNU / Linux operating systems, such as, for example, Google Chrome OS. Alternatively or additionally, client computing devices 502, 504, 506, and 508 may be any other electronic device, such as a thin client computer, an Internet-enabled gaming system (e.g., with or without A Microsoft Xbox gaming console (such as a gestural input device) and / or a personal messaging device capable of communicating via network(s) 510.

[0063] Although exemplary distributed system 500 is shown with four client computing devices, any number of client computing devices may be supported. Other devices, such as devices with sensors, etc., may interact with server 512 .

[0064] The network(s) 510 in the distributed system 500 may be any type of network familiar to those skilled in the art that can support data communications using any of a variety of commercial protocols, including but not limited to TCP / IP (Transmission Control Protocol / Internet Protocol), SNA (Systems Network Architecture), IPX (Internet Packet Exchange), AppleTalk, etc. By way of example only, the network(s) 510 may be a local area network (LAN), such as a LAN based on Ethernet, Token Ring, and / or the like. The network(s) 510 may be a wide area network and the Internet. It may include virtual networks, including but not limited to virtual private networks (VPNs), intranets, extranets, public switched telephone networks (PSTNs), infrared networks, wireless networks (e.g., any protocol in the Institute of Electrical and Electronics (IEEE) 802.11 protocol suite, and / or any other wireless protocol operating under the IEEE 802.11 protocol); and / or any combination of these networks and / or other networks.

[0065] Server 512 may include one or more general-purpose computers, dedicated server computers (for example, including PC (personal computer) servers, Server 512 may be a server, a mid-size server, a mainframe computer, a rack server, etc.), a server farm, a server cluster, or any other suitable arrangement and / or combination. In various embodiments, server 512 may be suitable for running one or more services or software applications described in the foregoing disclosure. For example, server 512 may correspond to a server for performing the above-mentioned processing according to an embodiment of the present disclosure.

[0066] Server 512 can run an operating system, including any of the operating systems discussed above, as well as any commercially available server operating system. Server 512 can also run any of a variety of additional server applications and / or middle-tier applications, including HTTP (Hypertext Transfer Protocol) servers, FTP (File Transfer Protocol) servers, CGI (Common Gateway Interface) servers, Servers, database servers, etc. Exemplary database servers include, but are not limited to, database servers commercially available from Oracle, Microsoft, Sybase, IBM (International Business Machines), etc.

[0067] In some implementations, server 512 may include one or more applications to analyze and integrate data feeds and / or event updates received from users of client computing devices 502, 504, 506, and 508. For example, data feeds and / or event updates may include, but are not limited to feed, Server 512 may include one or more applications to display data feeds and / or real-time events via one or more display devices of client computing devices 502, 504, 506, and 508.

[0068] Distributed system 500 may also include one or more databases 514 and 516. Databases 514 and 516 may reside in a variety of locations. For example, one or more of databases 514 and 516 may reside on a non-transitory storage medium local to server 512 (and / or residing in server 512). Alternatively, databases 514 and 516 may be remote from server 512 and communicate with server 512 via a network-based or dedicated connection. In one set of embodiments, databases 514 and 516 may reside in a storage area network (SAN). Similarly, any necessary files for performing functions attributed to server 512 may be stored locally on server 512 and / or remotely as appropriate. In one set of embodiments, databases 514 and 516 may include a relational database, such as a database provided by Oracle, which is suitable for storing, updating and retrieving data in response to commands in SQL format.

[0069] Figure 6 6 is a simplified block diagram of one or more components of a system environment 600 according to an embodiment of the present disclosure, through which services provided by one or more components of the embodiment system may be provided as cloud services. In the illustrated embodiment, the system environment 600 includes one or more client computing devices 604, 606, and 608, which a user may use to interact with a cloud infrastructure system 602 that provides cloud services. The client computing device may be configured to operate a client application, such as a web browser, a proprietary client application (e.g., Oracle Forms), or some other application, which a user of the client computing device may use to interact with the cloud infrastructure system 602 to use the services provided by the cloud infrastructure system 602.

[0070] It should be understood that the cloud infrastructure system 602 depicted in the figure can have other components than those depicted. In addition, the embodiment shown in the figure is only one example of a cloud infrastructure system that can be combined with embodiments of the present invention. In some other embodiments, the cloud infrastructure system 602 can have more or fewer components than shown in the figure, can combine two or more components, or can have a different configuration or arrangement of components.

[0071] Client computing devices 604 , 606 , and 608 may be similar devices to those described above with respect to 502 , 504 , 506 , and 508 .

[0072] Although the exemplary system environment 600 is shown with three client computing devices, any number of client computing devices may be supported. Other devices (such as devices with sensors, etc.) may interact with the cloud infrastructure system 602 .

[0073] Network(s) 610 can facilitate data communications and exchanges between clients 604, 606, and 608 and cloud infrastructure system 602. Each network can be any type of network familiar to those skilled in the art that can support data communications using any of a variety of commercial protocols, including the commercial protocols described above for network(s) 510.

[0074] Cloud infrastructure system 602 may include one or more computers and / or servers, which may include the computers and / or servers described above with respect to server 512 .

[0075] In certain embodiments, the services provided by the cloud infrastructure system may include a large number of services available on demand to users of the cloud infrastructure system, such as online data storage and backup solutions, web-based email services, hosted office suites and document collaboration services, database processing, managed technical support services, etc. The services provided by the cloud infrastructure system can be dynamically scaled to meet the needs of its users. The specific instantiation of the services provided by the cloud infrastructure system is referred to as a "service instance" in this article. Generally, any service available to users from a cloud service provider's system via a communication network (such as the Internet) is referred to as a "cloud service." Typically, in a public cloud environment, the servers and systems that make up the cloud service provider system are different from the customer's own on-premises servers and systems. For example, a cloud service provider's system can host applications, and users can order and use applications on demand via a communication network such as the Internet.

[0076] In some examples, services in a computer network cloud infrastructure may include protected computer network access to storage devices, hosted databases, hosted web servers, software applications, or other services provided by a cloud provider to users, or as otherwise known in the art. For example, a service may include password-protected access to remote storage devices on the cloud over the Internet. As another example, a service may include a hosted relational database based on a web service and a scripting language middleware engine for web developers. As another example, a service may include access to an email software application hosted on a cloud provider's website.

[0077] In some embodiments, the cloud infrastructure system 602 may include a set of application, middleware and database service products distributed to customers in a self-service, subscription-based, elastically scalable, reliable, highly available and secure manner. An example of such a cloud infrastructure system is the Oracle public cloud provided by the present assignee.

[0078] In various embodiments, the cloud infrastructure system 602 may be adapted to automatically provision, manage, and track customer subscriptions to services provided by the cloud infrastructure system 602. The cloud infrastructure system 602 may provide cloud services via different deployment models. For example, services may be provided under a public cloud model, in which the cloud infrastructure system 602 is owned by an organization that sells cloud services (e.g., owned by Oracle) and the services are available to the general public or to enterprises in different industries. As another example, services may be provided under a private cloud model, in which the cloud infrastructure system 602 operates only for a single organization and may provide services to one or more entities within the organization. Cloud services may also be provided under a community cloud model, in which the cloud infrastructure system 602 and the services provided by the cloud infrastructure system 602 are shared by several organizations in a related community. Cloud services may also be provided under a hybrid cloud model, which is a combination of two or more different models.

[0079] In some embodiments, the services provided by cloud infrastructure system 802 may include one or more services provided under a software as a service (SaaS) category, a platform as a service (PaaS) category, an infrastructure as a service (IaaS) category, or other service categories including hybrid services. A customer may order one or more services provided by cloud infrastructure system 602 via a subscription order. Cloud infrastructure system 602 then performs processing to provide the services in the customer's subscription order.

[0080] In some embodiments, the services provided by the cloud infrastructure system 602 may include, but are not limited to, application services, platform services, and infrastructure services. In some examples, application services may be provided by the cloud infrastructure system via a SaaS platform. The SaaS platform may be configured to provide cloud services belonging to the SaaS category. For example, a SaaS platform may provide the ability to build and deliver a set of on-demand applications on an integrated development and deployment platform. The SaaS platform may manage and control the underlying software and infrastructure used to provide SaaS services. By utilizing the services provided by the SaaS platform, customers can utilize applications executed on the cloud infrastructure system. Customers can obtain application services without the need for customers to purchase separate licenses and support. A variety of different SaaS services may be provided. Examples include, but are not limited to, services that provide solutions for sales performance management, enterprise integration, and flexibility to large organizations.

[0081] In some embodiments, platform services can be provided by a cloud infrastructure system via a PaaS platform. The PaaS platform can be configured to provide cloud services belonging to the PaaS category. Examples of platform services may include, but are not limited to, services that enable organizations (such as Oracle) to integrate existing applications on a shared, public architecture, and the ability to build new applications that utilize the shared services provided by the platform. The PaaS platform can manage and control the underlying software and infrastructure used to provide PaaS services. Customers can obtain PaaS services provided by a cloud infrastructure system without the need for customers to purchase separate licenses and support. Examples of platform services include, but are not limited to, Oracle Java Cloud Service (JCS), Oracle Database Cloud Service (DBCS) and others.

[0082] By utilizing the services provided by the PaaS platform, customers can adopt programming languages ​​and tools supported by the cloud infrastructure system, and can also control the deployed services. In some embodiments, the platform services provided by the cloud infrastructure system may include database cloud services, middleware cloud services (e.g., Oracle Fusion middleware services), and Java cloud services. In one embodiment, the database cloud service may support a shared service deployment model that enables organizations to pool database resources and provide database as a service to customers in the form of a database cloud. In the cloud infrastructure system, the middleware cloud service can provide customers with a platform to develop and deploy various cloud applications, and the Java cloud service can provide customers with a platform to deploy Java applications.

[0083] A variety of different infrastructure services can be provided by IaaS platforms in cloud infrastructure systems. Infrastructure services facilitate the management and control of underlying computing resources (such as storage, networks, and other basic computing resources) by customers who utilize services provided by SaaS platforms and PaaS platforms.

[0084] In some embodiments, the cloud infrastructure system 602 may also include infrastructure resources 630 for providing resources for providing various services to customers of the cloud infrastructure system. In one embodiment, the infrastructure resources 630 may include a pre-integrated and optimized combination of hardware (such as servers, storage devices, and network resources) to perform the services provided by the PaaS platform and the SaaS platform.

[0085] In some embodiments, resources in cloud infrastructure system 602 can be shared by multiple users and dynamically reallocated as needed. Additionally, resources can be allocated to users in different time zones. For example, cloud infrastructure system 630 can enable a first group of users in a first time zone to utilize resources of the cloud infrastructure system for a specified number of hours, and then enable the same resources to be reallocated to another group of users in a different time zone, thereby maximizing utilization of the resources.

[0086] In certain embodiments, a plurality of internal shared services 632 may be provided that are shared by different components or modules of the cloud infrastructure system 602 and services provided by the cloud infrastructure system 602. These internal shared services may include, but are not limited to, security and identity services, integration services, enterprise repository services, enterprise manager services, virus scanning and whitelisting services, high availability, backup and recovery services, services for enabling cloud support, email services, notification services, file transfer services, and the like.

[0087] In some embodiments, the cloud infrastructure system 602 can provide comprehensive management of cloud services (e.g., SaaS, PaaS, and IaaS services) in the cloud infrastructure system. In one embodiment, cloud management functions may include the ability to provision, manage, and track customer subscriptions received by the cloud infrastructure system 602, among other things.

[0088] In one embodiment, as depicted in the figure, cloud management functionality may be provided by one or more modules such as order management module 620, order orchestration module 622, order provisioning module 624, order management and monitoring module 626, and identity management module 628. These modules may include or be provided using one or more computers and / or servers, which may be general purpose computers, dedicated server computers, server farms, server clusters, or any other suitable arrangement and / or combination.

[0089] In exemplary operation 634, a customer using a client device such as client device 604, 606, or 608 may interact with cloud infrastructure system 602 by requesting one or more services provided by cloud infrastructure system 602 and placing an order to subscribe to one or more services provided by cloud infrastructure system 602. In certain embodiments, the customer may access a cloud user interface (UI) (cloud UI 612, cloud UI 614, and / or cloud UI 616) and place a subscription order via these UIs. Order information received by cloud infrastructure system 602 in response to a customer placing an order may include information identifying the customer and one or more services provided by cloud infrastructure system 602 that the customer intends to subscribe to.

[0090] After a customer has placed an order, order information is received via cloud UIs 612 , 614 , and / or 616 .

[0091] At operation 636, the order is stored in order database 618. Order database 618 may be one of several databases operated by cloud infrastructure system 618 and in conjunction with other system elements.

[0092] At operation 638, the order information is forwarded to order management module 620. In some cases, order management module 620 may be configured to perform billing and accounting functions related to the order, such as validating the order and, upon validation, booking the order.

[0093] At operation 640, information about the order is transmitted to order orchestration module 622. Order orchestration module 622 can use the order information to orchestrate the provision of services and resources for the order placed by the customer. In some cases, order orchestration module 622 can orchestrate the provision of resources to support the subscribed services using the services of order provisioning module 624.

[0094] In certain embodiments, order orchestration module 622 enables management of processes associated with each order and applies logic to determine whether an order should continue to be provisioned. At operation 642, upon receiving an order for a new subscription, order orchestration module 622 sends a request to order provisioning module 624 to allocate resources and configure those resources required to satisfy the subscription order. Order provisioning module 624 enables allocation of resources for services ordered by a customer. Order provisioning module 624 provides a level of abstraction between the cloud services provided by cloud infrastructure system 600 and the physical implementation layer for provisioning resources for providing the requested services. Order orchestration module 622 can therefore be isolated from implementation details such as whether services and resources are actually provisioned on the fly or pre-provisioned and allocated / assigned only upon request.

[0095] At operation 644 , once the services and resources are provisioned, notification of the provided services may be sent by the order provisioning module 624 of the cloud infrastructure system 602 to the customer on the customer device 604 , 606 , and / or 608 .

[0096] At operation 646, the customer's subscription order may be managed and tracked by the order management and monitoring module 626. In some cases, the order management and monitoring module 626 may be configured to collect usage statistics for the services in the subscription order, such as the amount of storage used, the amount of data transferred, the number of users, and the amount of system uptime and system downtime.

[0097] In certain embodiments, cloud infrastructure system 600 may include identity management module 628. Identity management module 628 may be configured to provide identity services, such as access management and authorization services in cloud infrastructure system 600. In some embodiments, identity management module 628 may control information about clients who wish to utilize services provided by cloud infrastructure system 602. Such information may include information authenticating the identities of such clients and information describing which actions those clients are authorized to perform with respect to various system resources (e.g., files, directories, applications, communication ports, memory segments, etc.). Identity management module 628 may also include management of descriptive information about each client and how and by whom the descriptive information may be accessed and modified.

[0098] Figure 7 An exemplary computer system 700 in which various embodiments of the present invention may be implemented is shown. System 700 may be used to implement any of the computer systems described above. As shown, computer system 700 includes a processing unit 704 that communicates with a plurality of peripheral subsystems via a bus subsystem 702. These peripheral subsystems may include a processing acceleration unit 706, an I / O subsystem 708, a storage subsystem 718, and a communication subsystem 724. Storage subsystem 718 includes a tangible computer readable storage medium 722 and a system memory 710.

[0099] The bus subsystem 702 provides a mechanism for allowing the various components and subsystems of the computer system 700 to communicate with each other as expected. Although the bus subsystem 702 is schematically shown as a single bus, alternative embodiments of the bus subsystem can utilize multiple buses. The bus subsystem 702 can be any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. For example, such an architecture can include an industry standard architecture (ISA) bus, a microchannel architecture (MCA) bus, an enhanced ISA (EISA) bus, a video electronics standard association (VESA) local bus, and a peripheral component interconnect (PCI) bus that can be implemented as a mezzanine bus manufactured according to the IEEE P1386.1 standard.

[0100] The processing unit 704, which may be implemented as one or more integrated circuits (e.g., conventional microprocessors or microcontrollers), controls the operation of the computer system 700. One or more processors may be included in the processing unit 704. These processors may include single-core or multi-core processors. In certain embodiments, the processing unit 704 may be implemented as one or more independent processing units 732 and / or 734, each of which includes a single-core or multi-core processor. In other embodiments, the processing unit 704 may also be implemented as a quad-core processing unit formed by integrating two dual-core processors into a single chip.

[0101] In various embodiments, the processing unit 704 can execute a variety of programs in response to program code and can maintain multiple concurrently executed programs or processes. At any given time, some or all of the program code to be executed may reside in (one or more) processors 704 and / or storage subsystem 718. Through appropriate programming, (one or more) processors 704 can provide the various functions described above. The computer system 700 may additionally include a processing acceleration unit 706, which may include a digital signal processor (DSP), a special processor, etc.

[0102] I / O subsystem 708 may include user interface input devices and user interface output devices. User interface input devices may include keyboards, pointing devices such as mice or trackballs, touch pads or touch screens incorporated into displays, scroll wheels, click wheels, dials, buttons, switches, keypads, audio input devices with voice command recognition systems, microphones, and other types of input devices. User interface input devices may include, for example, motion sensing and / or gesture recognition devices, such as natural user interfaces that enable users to control input devices using gestures and verbal commands (such as Microsoft 360 game controller) and interact with input devices Microsoft Motion sensors. User interface input devices may also include eye gesture recognition devices such as Google Blink detector, which detects eye activity from the user (e.g., a "wink" when taking a picture and / or making a menu selection) and converts the eye gesture to an input device (e.g., Google ) input. Additionally, the user interface input device may include a device that enables a user to communicate with a speech recognition system (e.g., Navigator) for interacting with a voice recognition sensing device.

[0103] The user interface input device may also include, but is not limited to, a three-dimensional (3D) mouse, a joystick or pointing stick, a game controller, and a graphics tablet, and audio / visual devices, such as speakers, digital cameras, digital video cameras, portable media players, webcams, image scanners, fingerprint scanners, barcode reader 3D scanners, 3D printers, laser rangefinders, and eye tracking devices. Additionally, the user interface input device may include, for example, a medical imaging input device, such as computer tomography, magnetic resonance imaging, position emission tomography, medical ultrasound equipment. The user interface input device may also include, for example, an audio input device, such as a MIDI keyboard, a digital musical instrument, etc.

[0104] The user interface output device may include a display subsystem, indicator lights, or non-visual displays such as audio output devices, etc. The display subsystem may be a cathode ray tube (CRT), a flat panel device such as a liquid crystal display (LCD) or plasma display, a projection device, a touch screen, etc. In general, the use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from the computer system 700 to a user or other computer. For example, the user interface output device may include, but is not limited to, a variety of display devices that transmit text, graphics, and audio / video information in a visual manner, such as monitors, printers, speakers, headphones, car navigation systems, plotters, voice output devices, and modems.

[0105] Computer system 700 may include storage subsystem 718, including software elements shown as currently located within system memory 710. System memory 710 may store program instructions loadable and executable on processing unit 704, as well as data generated during execution of these programs.

[0106] Depending on the configuration and type of computer system 700, system memory 710 may be volatile (such as random access memory (RAM)) and / or non-volatile (such as read-only memory (ROM), flash memory, etc.). RAM typically contains data and / or program modules that are immediately accessible to and / or currently being operated and executed by processing unit 704. In some embodiments, system memory 710 may include a variety of different types of memory, such as static random access memory (SRAM) or dynamic random access memory (DRAM). In some embodiments, a basic input / output system (BIOS) containing basic routines that help transfer information between elements within computer system 700 (such as during startup) may typically be stored in ROM. By way of example, and not limitation, system memory 710 also illustrates application programs 712 that may include client applications, web browsers, middle-tier applications, relational database management systems (RDBMS), etc., program data 714, and an operating system 716. By way of example, operating system 716 may include various versions of Microsoft Apple and / or Linux operating system, various commercial or UNIX-like operating systems (including but not limited to various GNU / Linux operating systems, Google OS, etc.) and / or mobile operating systems such as iOS, Phone, OS, 10OS and OS operating system.

[0107] The storage subsystem 718 may also provide a tangible computer-readable storage medium for storing basic programming and data structures that provide the functionality of some embodiments. Software (programs, code modules, instructions) that provide the above-mentioned functionality when executed by the processor may be stored in the storage subsystem 718. These software modules or instructions may be executed by the processing unit 704. The storage subsystem 718 may also provide a repository for storing data used in accordance with the present invention.

[0108] The storage subsystem 700 may also include a computer-readable storage media reader 720, which may be further connected to a computer-readable storage medium 722. The computer-readable storage medium 722, together with the system memory 710, and optionally in combination with the system memory 710, may comprehensively represent remote, local, fixed and / or removable storage devices and storage media for temporarily and / or more permanently containing, storing, transmitting, and retrieving computer-readable information.

[0109] The computer-readable storage medium 722 containing the code or portions of the code may also include any suitable media known or used in the art, including storage media and communication media, such as, but not limited to, volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing and / or sending information. This may include tangible computer-readable storage media, such as RAM, ROM, electronically erasable programmable ROM (EEPROM), flash memory or other storage technology, CD-ROM, digital versatile disk (DVD) or other optical storage device, cassette, magnetic tape, magnetic disk storage device or other magnetic storage device or other tangible computer-readable medium. This may also include intangible computer-readable media such as data signals, data transmissions, or any other media that can be used to send the desired information and can be accessed by the computing system 700.

[0110] For example, computer-readable storage media 722 may include a hard disk drive that reads from or writes to non-removable nonvolatile magnetic media, a disk drive that reads from or writes to a removable nonvolatile disk, and a removable nonvolatile optical disk such as a CD ROM, a DVD, and a DVD. Computer readable storage media 722 may include, but is not limited to, optical disks (discs) or other optical media or optical disk drives that read or write to removable non-volatile optical disks or other optical media. The computer readable storage medium 722 may include a solid-state drive (SSD) based on non-volatile memory (such as SSD based on flash memory, enterprise flash drive, solid-state ROM, etc.), a volatile memory-based SSD (such as SSD based on solid-state RAM, dynamic RAM, static RAM, DRAM), a magnetoresistive RAM (MRAM) SSD, and a hybrid SSD using a combination of DRAM and flash-based SSD. The disk drive and its associated computer-readable media may provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data for the computer system 700.

[0111] The communication subsystem 724 provides an interface to other computer systems and networks. The communication subsystem 724 is used as an interface for receiving data from the computer system 700 and sending data to other systems. For example, the communication subsystem 924 can enable the computer system 700 to be connected to one or more devices via the Internet. In some embodiments, the communication subsystem 724 may include a radio frequency (RF) transceiver component, a global positioning system (GPS) receiver component and / or other components for accessing a wireless voice and / or data network (e.g., using cellular phone technology, advanced data network technologies such as 3G, 4G or EDGE (Enhanced Data Rate for Global Evolution), WiFi (IEEE1202.11 series standards, or other mobile communication technologies, or any combination thereof). In some embodiments, in addition to or in place of a wireless interface, the communication subsystem 724 may provide a wired network connection (e.g., Ethernet).

[0112] In some embodiments, communication subsystem 724 may also receive incoming communications in the form of structured and / or unstructured data feeds 726 , event streams 728 , event updates 730 , and the like on behalf of one or more users who may use computer system 700 .

[0113] For example, the communication subsystem 724 may be configured to receive data feeds 726 in real time from users of social networks and / or other communication services, such as feed, Updates, web feeds such as Rich Site Summary (RSS) feeds, and / or real-time updates from one or more third-party information sources.

[0114] Additionally, the communication subsystem 724 may also be configured to receive data in the form of a continuous data stream, which may include an event stream 728 of real-time events and / or event updates 730, which may be continuous or unbounded in nature without a clear end. Examples of applications that generate continuous data may include, for example, sensor data applications, financial quote machines, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automobile traffic monitoring, etc.

[0115] The communication subsystem 724 may also be configured to output structured and / or unstructured data feeds 726 , event streams 728 , event updates 730 , etc. to one or more databases that may be in computer communication with one or more streaming data source computers coupled to the computer system 700 .

[0116] Computer system 700 may be one of various types, including a handheld portable device (e.g., Cellular phone, computing tablets, PDAs), wearable devices (e.g., Google head mounted displays), PCs, workstations, mainframes, kiosks, server racks, or any other data processing system.

[0117] Due to the ever-changing nature of computers and networks, the description of the computer system 700 depicted in the figure is intended only as a specific example. Many other configurations with more or fewer components than the system depicted in the figure are possible. For example, custom hardware can also be used and / or specific elements can be implemented in hardware, firmware, software (including applets), or a combination. In addition, connections to other computing devices such as network input / output devices can be adopted. Based on the disclosure and teachings provided herein, those of ordinary skill in the art will understand other ways and / or methods of implementing various embodiments.

[0118] In the above description, aspects of the present invention are described with reference to specific embodiments of the present invention, but those skilled in the art will recognize that the present invention is not limited thereto. The various features and aspects of the above invention may be used alone or in combination. In addition, embodiments may be utilized in any number of environments and applications beyond those described herein without departing from the broader spirit and scope of this specification. Therefore, the description and drawings are to be considered illustrative rather than restrictive.

Claims

1. A computer-implemented method comprising: receiving a request to retrieve web page data stored at a server, the web page data corresponding to a web page configured to display one or more content objects, the request corresponding to a data string including one or more request parameters, each of the one or more request parameters characterizing a client device, and the one or more request parameters including at least an uptime of the client device, wherein the uptime of the client device represents an amount of time that has elapsed since a last reboot of the client device; extracting the one or more request parameters included in the data string of the request; accessing one or more rules for detecting whether the client device is operated by a robot script or a human, each of the one or more rules including a condition that, when satisfied, indicates that the client device is operated by a robot script; accessing metadata associated with the client device, the metadata representing one or more previous interactions between the client device and the server; automatically determining whether to send a particular content object to the client device, the automatic determination being based on a result of evaluating the one or more rules using the runtime of the client device, the one or more request parameters, and / or the metadata associated with the client device; as well as In response to determining to send the specific content object to the client device, the specific content object is sent, the sending of the specific content object indicating that the client device is detected as being operated by a human.

2. A computer-implemented method as described in claim 1, wherein a rule among the one or more rules evaluates the running time of the client device against a defined time threshold, wherein when the running time of the client device is lower than the defined time threshold, the client device is detected as being operated by a robot script, and wherein when the running time of the client device is equal to or greater than the defined time threshold, the client device is detected as being operated by a human.

3. The computer-implemented method of claim 2, further comprising: When the client device is detected as being operated by a robot script, determining to prohibit sending the specific content object to the client device; as well as When the client device is detected as being operated by a human, it is determined to send the specific content object to the client device.

4. The computer-implemented method of claim 1 , further comprising: determining that the runtime of the client device is below a time threshold, wherein runtimes below the time threshold are associated with client devices operated by a robot script, and wherein runtimes above the time threshold are associated with client devices operated by a human user; evaluating the metadata associated with the client device, wherein the evaluating comprises: identifying a previous request to retrieve the web page data, wherein the previous request was previously received from the client device; identifying a previous run time associated with the client device, wherein the previous run time is included in a previous data string corresponding to the previous request; and determining that the previous run time associated with the client device is equal to or greater than the time threshold; and Determining to send the specific content object to the client device despite the runtime of the client device being below the time threshold is based at least in part on a result of evaluating the metadata associated with the client device.

5. The computer-implemented method of claim 1 , further comprising: identifying a plurality of additional requests to retrieve the webpage data, each additional request in the plurality of additional requests being associated with a runtime of an additional client device; performing one or more clustering techniques on the plurality of additional requests, the performing of the one or more clustering techniques identifying a number of unique runtimes associated with the plurality of additional requests; as well as The number of unique run times is determined to correspond to a number of unique client devices sending the plurality of additional requests.

6. The computer-implemented method of claim 1 , further comprising: identifying a set of additional requests to retrieve the webpage data, each additional request in the set of additional requests being associated with an additional runtime of an additional client device; identifying a subset of the set of additional requests, each additional request in the subset of additional requests corresponding to an additional runtime below a time threshold, the additional runtime below the time threshold indicating that a corresponding additional client device is detected as being operated by a robot script; evaluating the subset of additional requests using one or more machine learning techniques, the evaluation of the subset of additional requests resulting in detection of one or more patterns associated with runtime of additional client devices associated with the robot script; as well as Additional rules are automatically generated for inclusion in the one or more rules for detecting client devices operated by a robot script.

7. The computer-implemented method of claim 1 , further comprising: generating a human user score for the client device, the human user score being based at least in part on the results of evaluating the one or more rules using the runtime of the client device, the one or more request parameters, and / or the metadata associated with the client device, the human user score representing a degree to which the client device is detected as being operated by a human; as well as A determination is made whether to send the particular content object to the client device based at least in part on the generated human user score.

8. A system for classifying hosts in a network environment, comprising: one or more data processors; as well as A non-transitory computer-readable storage medium containing instructions that, when executed on the one or more data processors, cause the one or more data processors to perform operations comprising: receiving a request to retrieve web page data stored at a server, the web page data corresponding to a web page configured to display one or more content objects, the request corresponding to a data string including one or more request parameters, each of the one or more request parameters characterizing a client device, and the one or more request parameters including at least an uptime of the client device, wherein the uptime of the client device represents an amount of time that has elapsed since a last reboot of the client device; extracting the one or more request parameters included in the data string of the request; accessing one or more rules for detecting whether the client device is operated by a robot script or a human, each of the one or more rules including a condition that, when satisfied, indicates that the client device is operated by a robot script; accessing metadata associated with the client device, the metadata representing one or more previous interactions between the client device and the server; automatically determining whether to send a particular content object to the client device, the automatic determination being based on a result of evaluating the one or more rules using the runtime of the client device, the one or more request parameters, and / or the metadata associated with the client device; and In response to determining to send the specific content object to the client device, the specific content object is sent, the sending of the specific content object indicating that the client device is detected as being operated by a human.

9. A system as described in claim 8, wherein a rule among the one or more rules evaluates the running time of the client device against a defined time threshold, wherein when the running time of the client device is lower than the defined time threshold, the client device is detected as being operated by a robot script, and wherein when the running time of the client device is equal to or greater than the defined time threshold, the client device is detected as being operated by a human.

10. The system of claim 9, further comprising: When the client device is detected as being operated by a robot script, determining to prohibit sending the specific content object to the client device; as well as When the client device is detected as being operated by a human, it is determined to send the specific content object to the client device.

11. The system of claim 8, wherein the operations further comprise: determining that the runtime of the client device is below a time threshold, wherein runtimes below the time threshold are associated with client devices operated by a robot script, and wherein runtimes above the time threshold are associated with client devices operated by a human user; evaluating the metadata associated with the client device, wherein the evaluating comprises: identifying a previous request to retrieve the web page data, wherein the previous request was previously received from the client device; identifying a previous run time associated with the client device, wherein the previous run time is included in a previous data string corresponding to the previous request; and determining that the previous run time associated with the client device is equal to or greater than the time threshold; and Determining to send the specific content object to the client device despite the runtime of the client device being below the time threshold is based at least in part on a result of evaluating the metadata associated with the client device.

12. The system of claim 8, wherein the operations further comprise: identifying a plurality of additional requests to retrieve the webpage data, each additional request in the plurality of additional requests being associated with a runtime of an additional client device; performing one or more clustering techniques on the plurality of additional requests, the performing of the one or more clustering techniques identifying a number of unique runtimes associated with the plurality of additional requests; as well as The number of unique run times is determined to correspond to a number of unique client devices sending the plurality of additional requests.

13. The system of claim 8, wherein the operations further comprise: identifying a set of additional requests to retrieve the webpage data, each additional request in the set of additional requests being associated with an additional runtime of an additional client device; identifying a subset of the set of additional requests, each additional request in the subset of additional requests corresponding to an additional runtime below a time threshold, the additional runtime below the time threshold indicating that a corresponding additional client device is detected as being operated by a robot script; evaluating the subset of additional requests using one or more machine learning techniques, the evaluation of the subset of additional requests resulting in detection of one or more patterns associated with runtime of additional client devices associated with the robot script; as well as Additional rules are automatically generated for inclusion in the one or more rules for detecting client devices operated by a robot script.

14. The system of claim 8, wherein the operations further comprise: generating a human user score for the client device, the human user score being based at least in part on the results of evaluating the one or more rules using the runtime of the client device, the one or more request parameters, and / or the metadata associated with the client device, the human user score representing a degree to which the client device is detected as being operated by a human; as well as A determination is made whether to send the particular content object to the client device based at least in part on the generated human user score.

15. A computer program product tangibly embodied in a non-transitory machine-readable storage medium, comprising instructions configured to cause a data processing apparatus to perform operations comprising: receiving a request to retrieve web page data stored at a server, the web page data corresponding to a web page configured to display one or more content objects, the request corresponding to a data string including one or more request parameters, each of the one or more request parameters characterizing a client device, and the one or more request parameters including at least an uptime of the client device, wherein the uptime of the client device represents an amount of time that has elapsed since a last reboot of the client device; extracting the one or more request parameters included in the data string of the request; accessing one or more rules for detecting whether the client device is operated by a robot script or a human, each of the one or more rules including a condition that, when satisfied, indicates that the client device is operated by a robot script; accessing metadata associated with the client device, the metadata representing one or more previous interactions between the client device and the server; automatically determining whether to send a particular content object to the client device, the automatic determination being based on a result of evaluating the one or more rules using the runtime of the client device, the one or more request parameters, and / or the metadata associated with the client device; as well as In response to determining to send the specific content object to the client device, the specific content object is sent, the sending of the specific content object indicating that the client device is detected as being operated by a human.

16. A computer program product as described in claim 15, wherein a rule among the one or more rules evaluates the running time of the client device against a defined time threshold, wherein when the running time of the client device is lower than the defined time threshold, the client device is detected as being operated by a robot script, and wherein when the running time of the client device is equal to or greater than the defined time threshold, the client device is detected as being operated by a human.

17. The computer program product of claim 16, wherein the operations further comprise: When the client device is detected as being operated by a robot script, determining to prohibit sending the specific content object to the client device; as well as When the client device is detected as being operated by a human, it is determined to send the specific content object to the client device.

18. The computer program product of claim 15, wherein the operations further comprise: determining that the runtime of the client device is below a time threshold, wherein runtimes below the time threshold are associated with client devices operated by a robot script, and wherein runtimes above the time threshold are associated with client devices operated by a human user; evaluating the metadata associated with the client device, wherein the evaluating comprises: identifying a previous request to retrieve the web page data, wherein the previous request was previously received from the client device; identifying a previous run time associated with the client device, wherein the previous run time is included in a previous data string corresponding to the previous request; and determining that the previous run time associated with the client device is equal to or greater than the time threshold; and Determining to send the specific content object to the client device despite the runtime of the client device being below the time threshold is based at least in part on a result of evaluating the metadata associated with the client device.

19. The computer program product of claim 15, wherein the operations further comprise: identifying a plurality of additional requests to retrieve the webpage data, each additional request in the plurality of additional requests being associated with a runtime of an additional client device; performing one or more clustering techniques on the plurality of additional requests, the performing of the one or more clustering techniques identifying a number of unique runtimes associated with the plurality of additional requests; as well as The number of unique run times is determined to correspond to a number of unique client devices sending the plurality of additional requests.

20. The computer program product of claim 15, wherein the operations further comprise: identifying a set of additional requests to retrieve the webpage data, each additional request in the set of additional requests being associated with an additional runtime of an additional client device; identifying a subset of the set of additional requests, each additional request in the subset of additional requests corresponding to an additional runtime below a time threshold, the additional runtime below the time threshold indicating that a corresponding additional client device is detected as being operated by a robot script; evaluating the subset of additional requests using one or more machine learning techniques, the evaluating the subset of additional requests resulting in detecting one or more patterns associated with runtime of additional client devices associated with the robot script; as well as Additional rules are automatically generated for inclusion in the one or more rules for detecting client devices operated by a robot script.

Images