Improved captcha test to distinguish humans from computers

Abstract

In view of the foregoing, a more effective and novel CAPTCHAs exhibit two features: first, it should explore other human-computer differences besides intelligence, as the intelligent gap between humans and computers is diminishing and second, the puzzle should stay with whoever requested it, such that it cannot be easily forwarded to a third-party such as a CAPTCHA farm. Systems and methods in accordance with various improved CAPTCHA approaches no longer rely on determining the intelligent differences between a human and a bot. Rather, the improved CAPTCHA approaches leverage physical differences between humans and bots.

Description

Docket: GMU-25-027IMPROVED CAPTCHA TEST TO DISTINGUISH HUMANS FROM COMPUTERSRELATED APPLICATIONS

[0001] This application claims the benefit of provisional application serial number 63 / 722,153 filed November 19, 2024, titled “CAPTCHA Based on DRM-Protected Media,” and provisional application serial number 63 / 831,663 filed June 27, 2025, titled “CAPTCHA Based on DRM-Protected Media,” the entire content of which are hereby incorporated by reference.BACKGROUND

[0002] Completely Automated Public Turing test to tell Computers and Humans Apart, more commonly known as CAPTCHA, is a Turing test that uses various challenges to tell a computer apart from a human based on the subject’s intelligent behavior. CAPTCHA is used to detect and prevent online bots in various situations, such as bulk webpage scraping and fake account registration. However, with the recent advancements in computer vision and artificial intelligence, it has become increasingly debatable whether humans still maintain a significant intelligent advantage over computers in solving CAPTCHA puzzles. Consequently, CAPTCHA puzzles are becoming more complicated and less user-friendly, resulting in both ineffective bot prevention and degraded user experience.BRIEF DESCRIPTION OF THE DRAWINGS

[0003] The accompanying drawings provide visual representations which will be used to describe various representative embodiments more fully and can be used by those skilled in the art to understand better the representative embodiments disclosed and their inherent advantages. In these drawings, like reference numerals identify corresponding or analogous elements.

[0004] FIG. 1 A and FIG. IB provide examples of text-based, CAPTCHA, in accordance with embodiments of the present disclosure.

[0005] FIG. 2 illustrates examples of interaction-based CAPTCHAs, in accordance with embodiments of the present disclosure.Docket: GMU-25-027

[0006] FIG. 3 illustrates an interaction-based CAPTCHAs, in accordance with embodiments of the present disclosure.

[0007] FIG. 4 illustrates example interactions between a web browser and a media / DRM server in a DRM flow, in accordance with embodiments of the present disclosure.

[0008] FIG. 5 illustrates a request made by a user to a web server results in a CAPTCHA server returning a puzzle in a DRM-protected video, in accordance with embodiments of the present disclosure.

[0009] FIG. 6 is an example of NuCAPTCHA, in accordance with embodiments of the present disclosure.

[0010] FIG. 7 is an example result of a time-sensitive puzzle, in accordance with embodiments of the present disclosure.

[0011] FIG. 8 illustrates a communication network with a browser, web server and CAPTCHA server in which time-sensitive puzzles are solved, in accordance with embodiments of the present disclosure.

[0012] FIG. 9 illustrates a communications network with a browser, web server and CAPTCHA server demonstrates message exchanges between the client and the web / CAPTCHA server, without a CAPTCHA farm, in accordance with embodiments of the present disclosure.

[0013] FIG. 10A and FIG. 10B illustrate various message flows associated with a CAPTCHA farm, in accordance with embodiments of the present disclosure.

[0014] FIG. 11 illustrates various message flows associated with an improved CAPTCHA, in accordance with embodiments of the present disclosure.

[0015] FIG. 12 is a flow chart that illustrates method flow, in accordance with embodiments of the present disclosure.

[0016] FIG. 13 illustrates persistent HTTP, in accordance with embodiments of the present disclosure.

[0017] FIG. 14 illustrates various message flows consistent with blocking of a CAPTCHA farm in an improved CAPTCHA, in accordance with embodiments of the present disclosure.DETAILED DESCRIPTION

[0018] In accordance with the various embodiments presented in the disclosure, a number of novel CAPTCHAs, are presented, that do not rely on the intelligence difference between a computer and a human, the metric previously used in CAPTCHAs. Instead, Instead, various embodiments of novel CAPTCHAs block bots by leveraging physical differences betweenDocket: GMU-25-027 computers and humans, i.e., how do they “perceive” a puzzle and how do they react to simple interactive tasks. Furthermore, the novel CAPTCHA embodiments presented herein are able to block the use of CAPTCHA farms, a third-party service that solves CAPTCHA puzzles for bots. These novel CAPTCHA embodiments allows forgoing the use of distorted texts and hard-to-solve puzzles seen in today’s CAPTCHAs, and thus can boost user experience without sacrificing effectiveness on bot prevention.

[0019] While this present disclosure is susceptible of embodiment in many different forms, there is shown in the drawings and will herein be described in detail specific embodiments, with the understanding that the embodiments shown and described herein should be considered as providing examples of the principles of the present disclosure and are not intended to limit the present disclosure to the specific embodiments shown and described. In the description below, like reference numerals are used to describe the same, similar or corresponding parts in the several views of the drawings. For simplicity and clarity of illustration, reference numerals may be repeated among the figures to indicate corresponding or analogous elements.

[0020] CAPTCHA is a program created by Carnegie Mellon University researchers in 2000, with the aim to tell a computer program apart from a human being by letting the subject solve a challenging puzzle that is easy for a human to solve but otherwise difficult for a computer. In today’s Internet, CAPTCHA is widely used to detect and prevent malicious automated programs, more commonly known as the Web robots or simply the bots. Typical activities of Internet bots include:• Bulk scraping a website and extracting useful information, such as products’ prices from e-commerce web- sites, users’ personal information from social medial websites, or human-generated high-quality text content from community platforms (such as Reddit) for large language model training.• Automatically registering fake accounts, to send spam messages or publish spam posts, or to post fake information to influence other users’ opinion.• Conducting dictionary attacks by using bots to enumerate usernames and passwords to a website’s login portal.

[0021] CAPTCHA has been proven as an effective solution to slow down or prevent such malicious bots. In CAPTCHA a web server asks a client to solve a puzzle and will only provide the requested resources if the puzzle is solved correctly. As the puzzles areDocket: GMU-25-027 purposefully designed to be easy for human and hard for bots, those who cannot correctly solve the challenge are likely to be a bot and thus prevented from accessing the resources.

[0022] Bot developers, on the other hand, work hard to solve CAPTCHA puzzles automatically without human intervention. To date, there have been primarily two ways to facilitate such automated puzzle-solving tasks.

[0023] The first approach is to empower the bot to solve the puzzle by itself, which is mostly suitable for pattern recognition-based puzzles. Examples include asking the client to read distorted texts or to identify images that contain a certain object from a set of images. Such puzzles can be solved by using Optical Character Recognition (OCR), or computer vision and pattern recognition techniques. In recent years, however, the effectiveness of such puzzles began to plateau, due to the rapid advancement of Artificial Intelligent (Al) models that are approaching human- level intelligence in terms of pattern recognition capabilities. Consequently, the Turing test is losing its effectiveness in distinguishing between a bot and a human. As a result, CAPTCHA challenges are increasingly becoming intricate and perplexing even for human users, leading to frustration and a decreased user experience.

[0024] The second approach is to forward a puzzle to a dedicated CAPTCHA-solving platform, commonly known as a CAPTCHA farm. A CAPTCHA farm is often a crowdsourcing platform that recruits human workers to solve CAPTCHA puzzles to earn a commission. When being challenged by a CAPTCHA puzzle, the bot can forward the puzzle to the CAPTCHA farm and have it solved by a human worker. Some CAPTCHA vendors attempt to block CAPTCHA farms by checking the client’s IP address, which, however, is not reliable and can be bypassed.

[0025] The current trend on improving CAPTCHA, i.e., increasing the puzzles’ complexity to the extent that it can tell a computer apart from a human, is ominous for at least the following reasons. First, the concept of setting the CAPTCHA itself is tricky; that is, the puzzle must be easy for a human and hard for a bot to solve. As the intelligence gap diminishes between human beings and advanced Al models, the only solution is to keep increasing the puzzle’s complexity that unavoidably and negatively impacts the human user experience. Second, when a puzzle becomes complex enough such that solving becomes infeasible, a bot can always resort to a CAPTCHA farm for help, rendering any further complexity-increase infertile.

[0026] In view of the foregoing, a more effective CAPTCHA should exhibit two features: first, it should explore other human-computer differences besides intelligence, as the intelligent gap between humans and computers is diminishing; and second, the puzzle shouldDocket: GMU-25-027 stay with whoever requested it, such that it cannot be easily forwarded to a third-party such as a CAPTCHA farm.

[0027] Therefore, in accordance with the embodiments presented herein, systems and methods in accordance with various improved CAPTCHA approaches no longer rely on determining the intelligent differences between a human and a bot. Rather, the improved CAPTCHA approaches leverage physical differences between humans and bots. These differences include at least two forms. First, humans and bots “perceive” the content of puzzles differently. Specifically, a human perceives an image by “seeing” its visual appearance as it is displayed on a physical screen. Bots, on the other hand, perceive an image by “reading” its binaries from a computer’s storage, such as the disk, memory, or CPU cache. This observation motivated a solution that displays an image on a screen and is viewable by a human, but the image’s binaries are inaccessible by a bot. To achieve this objective, CAPTCHA is integrated with the DRM (digital rights management) technology, a technology used to protect copyright of online media, especially video. A DRM-protected media is delivered to a web browser encrypted, and can only be decrypted and played by a browser module that is inaccessible by a bot. Second, humans and bots possess different times to react to simple tasks. Although computers are much faster solving complex problems than humans, humans outperform computers on simple tasks that can be solved by human reflection. For instance, when presented with an image that displays several dogs and one cat, it would take a human almost no time to identify and click on the cat, while this intuitive task for a human takes a bot much longer to accomplish, even with advanced, general Al models that are not specifically trained for this task. In accordance with novel CAPTCHAs described herein, a “time-sensitive” puzzle is created and used to tell a computer (bot) apart from a human based on such time-differences.

[0028] Compared with its predecessors, the novel CAPTCHAs presented herein can prevent the use of CAPTCHA farms and also impose much higher requirements on the bot that even wants to access the puzzle; aspects of the various novel CAPTCHA solutions may or may not be combined as will be described. Furthermore, since the novel CAPTCHAs no longer rely on testing the intelligent difference between humans and bots, the puzzle can be much more user-friendly and intuitive to a human.

[0029] Therefore in accordance with various embodiments of the disclosure, a web-based communication system is operable to ensure delivery of media content to humans. The webbased communication system has a web server and a user client including a content decryption module (CDM) and operable to communicate with the web server and with a user.Docket: GMU-25-027In accordance with certain embodiments the user client may be a browser with the CDM. Responsive to a request for media content received by the web server from the user client, the web server delivers to the user client a digital rights management (DRM)-protected media containing a puzzle and solvable by a human, said puzzle viewable by a human when the DRM-protected media is played by the CDM of the user client. At least the web server is operable to perform analysis to determine the status of the user that communicates with the web server as a permissible human user or a non-permissible bot user, said analysis based at least in part on physical solution characteristics of the user in solving the puzzle.

[0030] Further, in accordance with various embodiments of the disclosure a method of ensuring delivery of media content to users is provided. The method includes: responsive to a request for media content initiated by a user client and received by a web server from the user client, delivering to the user client in communication with a user a digital rights management (DRM)-protected media containing a puzzle that is solvable by a human; playing the puzzle by a content decryption module (CDM) of the user client, said puzzle viewable by a human when the DRM-protected media is played; and determining the status of the user as a permissible single entity user or a non-permissible user based upon analyzing at least physical solution characteristics of the user associated with solution activity of the puzzle. Further, the method includes providing the requested media content to the user client when the status of the user is a permissible single entity user that is a permissible human user, and / or not providing the requested media content to the user client when the status of the user is a non-permissible user. The physical solution characteristics of the user are distinguishable from intelligence solution characteristics of the user.

[0031] As described herein with regard to the system and method embodiments, the determination of the status of the user is based upon at least physical differences between computers and humans, distinguishable from intelligence differences between humans and computers, in solving the puzzle. The physical solution characteristics of the user include may be perception of the puzzle by the user and / or reaction time by the user to an interactive task of the puzzle, associated with solution activity by the user of the puzzle. Perception of the puzzle by the user includes delivery of an encrypted media by the web server to a user, the DRM-protected media encrypted and containing the puzzle that is viewable by a human when the DRM-protected media is opened and played by the user client with CDM, but is inaccessible by one or more bots on the system, which may be one or more automated programs. In certain examples, the puzzle is a puzzle image converted into a video clip of the encrypted media that is encrypted using DRM. The video clip may be a single frame, aDocket: GMU-25-027 container containing the puzzle, and / or a voice puzzle and video clip further includes audio. With regard to reaction time by the user to an interactive task is determined by a timesensitive puzzle, the reaction time to the interactive task may be determined by difficulty in solving the time-sensitive puzzle, a length of the DRM-protected media, and / or a determined time limit. The time-sensitive puzzle is operable to be solved within a time limit that is solvable by a human but not solvable by one or more bots on the system. The user may trigger initiation of a timer that tracks the time limit that may be set in view of a human time limit to solve the time-sensitive puzzle and a bot time limit to solve the time-sensitive puzzle. A response by the user to solve the time-sensitive puzzle may include the user selecting, sliding or moving elements within the time-sensitive puzzle to solve the time-sensitive puzzle.

[0032] As will be described with regard to blocking farms or third-party services that solves puzzles for bots, the system may further include a verification server operable to communicate with the web server, at least one of the web server and the CAPTCHA server operable to determine the status of the user by performing analysis based at least in part on physical solution characteristics of the user in solving the puzzle, with one or more of the web server and the verification server blocking sending of the requested media content to the user when the user is determined to be a non-permissible bot user.

[0033] Requesting the media content, solution activity of the puzzle, and transmission of a solution of the puzzle by the user are physical solution characteristics of the user and responsive to verification that the user that requested the media content did not also solve the puzzle provided by the verification server and submit a solution of the puzzle to the web server, the solution is also provided to the verification server. Working together the web server and the verification server determine that the user is a non-permissible bot that is not a single entity and do not provide the requested media content to the user. Alternately, requesting the media content, solution activity of the puzzle, and transmission of a solution of the puzzle by the user are physical solution characteristics of the user and responsive to a determination that the user that requested the media content also solved the puzzle provided to the user by the verification server and submitted a solution of the puzzle to the web server, the solution is also provided to the verification server. The web server and the verification server in cooperative arrangement determine that the user is a single entity that is a permissible human user and provide the requested media content to the single entity user.

[0034] More particularly, a solution-submission action and / or a token-submission action performed by the user are physical solution characteristics of the user. The web server andDocket: GMU-25-027 the verification server in cooperative arrangement verify whether the solution-submission action and the token-submission action are both performed by the user and the user is the single entity user. The solution-submission action and token-submission action may be performed by the single entity user within request / response cycles between the user and the verification server.

[0035] Verification of performance of the solution-submission action by the user may include determination that the user that requested the media content and responsively received the puzzle from the verification server solved the puzzle and submitted the solution to the web server and the verification server. Verification of the solution-submission action by the user may further include the web server limiting the user to a single license request by the user for the puzzle; for example, the web server may delete an encryption key of the puzzle once a key ID of the puzzle has been requested. Verification of the token-submission action by the user may include determination by one or more of the web server and the verification server that a token obtained by the user from the verification server in response to submission of the solution is submitted to the web server by the user.

[0036] Verification of the token-submission action by the client may include determination by one or more of the web server and the verification server that a token obtained by the user from the verification server in response to submission of the solution is submitted to the web server by the user. Verification of the token-submission action by the single entity further may include verification that sequential requests sent by the user to the web server and an entitlement server in cooperative arrangement with the web server arrive at approximately the same time and submission of the token to the web server triggers a subsequent license request to the entitlement server. For example, verification may include verification that a token request sent by the user client, such as a web browser, on behalf of the user to the web server and the subsequent license request sent by the content decryption module (CDM) of the browser to the entitlement server arrive at the web server at approximately the same time, the entitlement server integrated with the web server. The system may further include the entitlement server, where the entitlement server extracts a device ID of the subsequent license request and compares the extracted device ID of the subsequent license request with a device ID of a previous license request, with each device ID unique to a device and not accessible or modifiable by the user, where matching of the extracted device ID of the subsequent license request and the device ID of the previous license request verifies that the subsequent license request and the previous license request were sent by the same device and the user of the user device is a single entity. In certain embodiments, the web server and / or the verificationDocket: GMU-25-027 server prompt the user to attempt playing the puzzle causes and trigger the subsequent license request to the entitlement server.

[0037] Verification of the token-submission action by the single entity may further include verification that sequential requests sent by the user to the web server and an entitlement server in cooperative arrangement with the web server are from the same port and where submission of the token to the web server triggers a subsequent license request to the entitlement server. In such embodiments, the system may further include the entitlement servicer, where the entitlement server and the web server have a same IP address and where the entitlement server communicates with the CDM of the user device on behalf of a license server. The web server and / or the verification server may prompt the user to attempt playing the puzzle causes and trigger the subsequent license request to the entitlement server. The user may receive the token directly from the verification server.

[0038] CAPTCHA and Bypassing Techniques

[0039] As mentioned, CAPTCHA is designed to detect and block Internet bots by letting a user solve a puzzle that was designed to be easy for a human but difficult for a bot to solve. To date, CAPTCHA puzzles have evolved considerably due to advancements in bots’ ability to solve them, leading to a diverse range of puzzles available in the current CAPTCHA market. A few types of CAPTCHA puzzles that are popularly seen on today’s Internet will be introduced.

[0040] CAPTCHA and Bypassing Techniques: Text-based CAPTCHAs

[0041] The text-based CAPTCHA delivered by an image that contains distorted text, where the text is distorted to the extent that it can still be correctly recognized by a human, but the recognition of which is difficult for a bot. As illustrated in FIG. 1A, an early form of a textbased CAPTCHA is depicted. The characters appear relatively undistorted because bots at that time did not possess advanced character-recognition skills. In the past few years, advancements in Al technologies have greatly enhanced computer Optical Character Recognition (OCR) capabilities. Bots can now easily recognize even severely distorted characters, making it increasingly challenging to design text-based CAPTCHAs to effectively confuse automated bots. Today, text-based CAPTCHAs typically use significantly distorted characters integrated with a background composed of confusing colors and patterns. Furthermore, some CAPTCHAs incorporate noise elements designed to hinder Al-driven pattern recognition. FIG. IB shows a few examples of such heavily distorted text-based CAPTCHA puzzles. Text-based CAPTCHA is facing the dilemma where, on the one hand, the puzzle must remain recognizable to humans, and on the other hand, sophisticatedDocket: GMU-25-027Al is rapidly approaching, if not already exceeding, human proficiency in completing these tasks. For example, many off-the-shelf CAPTCHA solvers claim to be able to solve a majority of text-based CAPTCHA puzzles. As a result, it appears that the text- based CAPTCHAs have very limited potential for further improvement.

[0042] CAPTCHA and Bypassing Techniques: Interaction-based CAPTCHAs

[0043] A more advanced CAPTCHA requires the user to interact with the puzzle, with the aim to test two capabilities of the user: recognizing more complex patterns, and interacting with the puzzle (e.g., using mouse-click or drag-and-drop). Interaction-based CAPTCHAs are generally more challenging for bots. A popularly used interaction-based CAPTCHA in the current market is Google’s reCAPTCHAv2, an example of which is shown in FIG. 2A. As shown in this particular example, reCAPTCHA2 displays a 3 x3 array of traffic-related images and asks the user to click on all images containing cars. Another common example of interaction-based CAPTCHA is the “slider-CAPTCHA” where the user is asked to drag and slide a sub-image to a place where a human can easily identify. An example of the slider- CAPTCHA is shown in FIG. 2B. Another example of an interaction-based CAPTCHA is an icon CAPTCHA which asks the visitor to recognize and click on three icons that are embedded in the picture, for instance.

[0044] In recent years, the “checkbox CAPTCHA” has gained in popularity. As an example, consider the Cloud-flare Turnstile. The core concept behind the Checkbox CAPTCHA is the utilization of JavaScript to track the user’s mouse movements as they approach and click the checkbox. Advanced algorithms, often powered by Al, are then used to determine whether the user is a human. Only if this JavaScript cannot reach a definitive conclusion, it will display an interaction-based CAPTCHA, such as the one shown in FIG. 2A, to further test the user. Besides these CAPTCHAs displayed in the drawings, there are many other types that are more complex but not as commonly seen. For example, FIG. 3 shows a “rotate CAPTCHA” designed by Arkose Labs, in which the user is asked to rotate the animal to align with the direction of the hand.

[0045] Although interaction-based CAPTCHAs present a higher level of difficulty, they can still be solved using sophisticated Al technologies. In addition to using Al to solve the puzzle locally, a bot can always employes a CAPTCHA farm to solve puzzles for it.

[0046] CAPTCHA and Bypassing Techniques: Invisible CAPTCHAs

[0047] Google has recently launched reCAPTCHAv3, also known as the “invisible CAPTCHA,” a novel form of CAPTCHA that operates without user interaction. The invisible CAPTCHA remains hidden on the webpage and does not require the user to solve any puzzle.Docket: GMU-25-027Instead, it leverages JavaScript to observe user behavior like mouse movements, typing habits, scrolling patterns, timing, and other interactive signals. Additionally, it evaluates factors such as IP address, browser characteristics, and cookie history. Based on the assessment, reCAPTCHA v3 assigns a score between 0.0 and 1.0, where 0.0 strongly suggests bot activity, while 1.0 indicates otherwise. Some research suggests that browsers with a logged-in Google session tend to achieve higher scores, implying that reCAPTCHAv3 decisions also involves a Google user’s historical activity.

[0048] The invisible CAPTCHA, specifically reCAPTCHAv3, faces three major challenges in broad adoption despite its presence on many websites. First, significant privacy concerns have been raised. Second, the system’s reliability is questionable: legitimate users using privacy-reserving browsers or VPNs may be blocked while allowing sophisticated bots that mimic human behavior patterns. Third, CAPTCHA farms have effectively evolved to bypass reCAPTCHAv3 by using real browsers linked to valid Google accounts and adopting humanlike behavioral patterns, thereby making it more challenging to differentiate their actions from those of legitimate users. Due to those reasons, many major websites still prefer visible verification methods such as reCAPTCHAv2 that provide more transparent security feedback and explicit fallback options when automatic verification fails.

[0049] CAPTCHA FarmCAPTCHA farms, further discussed below, are crowdsource platforms that employ human workers, primarily from less developed regions, to solve CAPTCHA puzzles to earn a commission. These farms offer APIs to facilitate bots to send puzzles to the platform, which are then passed on to an online human worker, referred to as the “ farmer The farmer solves the puzzle on behalf of the bot, enabling the bot to be judged as a human by the web server, thus gaining access to the desired online resource. The bot commonly pays the CAPTCHA farm platform based on the number and the type of puzzles solved.

[0050] Bot Threat Model

[0051] Bot Threat Model: Bots Classification

[0052] Due to the diverse web applications in today’s Internet, a bot can serve very different purposes. For example, a bot can crawl a website and scrape useful information, compete with humans to order products such as concert tickets or limited-edition garments, register accounts on social media and post influential fake information, etc. Internet bots may be classified into two categories based on their high-level behavior: the scraper and the spammer.Docket: GMU-25-027

[0053] Scraper. The term scraper is used to describe the type of bots whose objective is to extract information from publicly accessible webpages. For instance, bots that scrape Reddit to obtain high-quality text for LLM training, or e-commerce website for price tracking and comparison. A scraper may be characterized with the following three characters:• Low engagement: Scrapers do not establish long-term sessions with the web server, such as logging in or jumping between pages. Instead, they directly request the web resource of interest (e.g., an HTML page) from the web server since they are publicly accessible.• High frequency / concurrency: Scrapers need to interact with the target website with high frequency and / or concurrency to gather a large volume of information. For example, a scraper may concurrently visit all product pages of an e-commerce website every 10 minutes to closely monitor products’ prices.• Script-based: Due to its low engagement and high frequency / concurrency nature, a scraper is commonly implemented using scripting languages without employing a full-fledged web browser. For example, the Beautiful Soup

[0018] is a popular Python library specifically developed for web crawling. Simpler tasks can even be implemented by directly using Shell command Curl or the Python requests package.

[0054] Spammer. The term spammer is used to describe the type of bots that aim to engage in long-term, complex interactions with the web server. This interaction usually involves running JavaScript and handling cookies. For example, a spammer may register and login to Facebook and interact with other users such as sending messages, liking someone’ post, or befriending other users. A spammer may present properties opposite to those of a scraper, including:• High engagement: spammers need to establish long- term session with the web server, such as registering and logging into an account, and jumping through pages while maintaining a session. An example is the interaction between a spammer and Facebook as described above.• Browser-based: Establishing and maintaining a long- term session with the web server usually involves exchanging cookies and running JavaScript, which are too complex to be handled by scripts. Thus, a more feasible way is to use a full-fledged browser that supports automation. For example, Selenium is an automated browser, which integrates a full-fledged browser (i.e., the web driver) and allows a programmer to useDocket: GMU-25-027 scripts to simulate interactions with a webpage, such as mouse scroll and click, and keyboard keystroke.• Low frequency / con currency: Because the spammers’ objective is to interact with the web server rather than scraping a large amount of data, and also because using a full- fledged web browser consumes more resources than the script-only approach, a spammer does not create a lot of concurrent sessions with the web server.

[0055] Bot Threat Model: Objectives and Strategies

[0056] As used herein, a CAPTCHA provider or vendor may be referred to as the defender, while the bot (Internet bot) is referred to as the attacker, even where a bot’s goal may not constitute a malicious “attack.”

[0057] Attacker. The attacker’s objective is to bypass a CAPTCHA puzzle, that is, to solve the puzzle without human intervention, such that the bot’s automated task can continue without interruption. Admittedly, the word “bypass” may not accurately describes the attacker’s objective, because it implies accessing the requested resources without solving the puzzle. However, “bypass” is commonly used on the Internet to refer to the action of using an automated program to solve the puzzle. An attacker has two options to bypass a CAPTCHA puzzle: Firstly, the attacker can attempt to solve the puzzle locally. For instance, the attacker can use OCR to recognize the characters in a text-based puzzle, or use a ALaided program to solve specific types of interaction-based puzzles. For example, there are many open source libraries on GitHub for such purposes. Alternatively, the attacker can forward the puzzle to a CAPTCHA farm. Note that even though a CAPTCHA farm involves a human into the puzzle-solving loop, the overall CAPTCHA farm operation is still an automated service and thus constitutes solving a puzzle without human intervention.

[0058] Defender. The defender’s objective is to create puzzles that are only solvable by human beings. More practically, the defender may want to create puzzles that are as costly as possible for bots, such as taking longer time and consuming more computing power. The defender is aware of the CAPTCHA farm service and also wants to detect and prevent a bot from using a CAPTCHA farm.

[0059] Digital Rights Management (DRM)

[0060] DRM is the management of legal access to digital content and a brief description of DRM herein focuses on mechanisms that are relevant to the novel CAPTCHA embodiments described herein. Otherwise, Fortinet, “Digital rights management (DRM) — cyber glossary”, https: / / www.fortinet.com / resources / cyberglossary / digital-rights-management-drm.Docket: GMU-25-0272025, accessed: 2025-05-23, and Digital Guardian, “What is digital rights management (drm)? (the definitive guide).” https: / / www.digitalguardian.com / blog / what-digital-rights- management, Apr. 2022, Accessed: 2025-05-23, may be referenced for more general DRM disclosure and are herein incorporated in this disclosure.

[0061] DRM is a technology meant to protect proprietary on-line media (especially videos) from piracy. It ensures that a user, who has the privilege to watch a video, is unable to share or download the video unless such actions are explicitly allowed. In brief, DRM technology delivers encrypted video to a web browser and ensures that only users with proper privileges can decrypt and play it. Three main solutions in the DRM market today include Widevine by Google, FairPlay by Apple, and PlayReady by Microsoft. There are other solutions that are not as widely adopted and include the WisePlay DRM developed by HuaWei. Although differing in implementation details, these three solutions share similar characters with respect to the CAPTCHA design.

[0062] Example interactions between a web browser and a media / DRM server are depicted by the flow chart demonstrated in the DRM flowchart of FIG. 4. At a high level, three components are involved in this interaction: media server, web browser and the content decryption module (CDM), and the entitlement server and license server.

[0063] The Media Server encrypts a video using a chosen symmetric algorithm, most commonly AES 128, for example. The encryption will also generate a manifest file that includes essential information, such as the URL of the encrypted video, the key ID associated with the encryption key, and the URL of the license server. After encryption, the encryption key and key ID are sent to and kept by the license server. When the encrypted video is requested, the media server will first return the manifest file to the client.

[0064] The Web Browser and the Content Decryption Module (CDM): The CDM is a closed-source, proprietary module that is integrated into a web browser by the browser’s manufacture, and a DRM-protected video can be played in a browser only if the browser integrates the specific type of CDM. For example, Chrome, Firefox, and Edge integrate Google’s Widevine CDM, and thus are capable of playing videos protected with the Widevine specification. It is noted and contemplated herein that the CDM may be any decryption function module and need not be tied to a specific browser module.

[0065] A DRM-capable media player, such as the Shaka player, is required to play DRM- protected video. The media player reads the manifest file and passes the key ID and license server’s URL to the CDM module, which will then send a license request directly to the license server. The license request contains much information, such as the key ID used byDocket: GMU-25-027 the license server to locate the key and a Device ID that is unique to each device. The message exchange between the CDM and the license server is end-to-end encrypted, whose content is inaccessible to the bot or anyone else because the CDM is a closed-source module. A license containing the encryption key will be delivered directly to the CDM by the license server, and the CDM will decrypt the video and play it in the browser. The complete process, including license request and response, and video decryption and playback, is handled by the CDM and therefore the bot cannot access either the key or the decrypted video.

[0066] Entitlement and license server: The function of the license server is to interact with a browser’s CDM and provide the license that contains the encryption key. User authentication and authorization tasks may be handled by the license server directly, or these functions can be delegated to an entitlement server as part of the architecture. In this setup, the entitlement server acts as a proxy to the license server, receiving license requests from browsers and determining whether to forward these requests to the license server. In this arrangement, the functions are separated: the entitlement server looks at user properties such as IP, user privilege, etc., and decides if a user should be granted with a license and the license server only issues the license. In some cases, the entitlement server does not need to exist and the license server can handle both functions. And in these cases, the license server will handle the functions described in this disclosure.

[0067] Note that the entitlement server is unable to decrypt and inspect the content of license request either, and can only authenticates and authorizes users based on characters such as the user’s IP address or cookie values. Optionally, the entitlement server can forward the license request to the license server and ask the license server to return the Device ID contained in the license request, thus authentication and authorization can also be made based on the Device ID. If a user is authorized, the entitlement server will forward the encrypted license request to the license server and relay the license back to the user.

[0068] The entitlement server and the license server do not need to be collocated. In practice, the media server and the license server are commonly owned by two separate businesses, where a content provider encrypts all its videos using the API provided by the DRM provider. The encrypted video are hosted on the content provider’s media server, while the encryption keys are kept on the license server hosted by the DRM provider. In such a case, the media provider usually also deploys the entitlement server to authenticate and authorize their users, and only the authorized user’s license requests will be forwarded to the license server.Docket: GMU-25-027

[0069] In view of the above, it can be seen that a DRM-protected video is an encrypted video clip that can only be decrypted and played by the CDM in supporting browsers. Therefore, a bot is unable to access the content of a DRM-protected video until this video is decrypted and played by the CDM in a browser.

[0070] A First Novel CAPTCHA: Preventing Scrappers

[0071] Recall that the characteristics of the scraper include: low engagement, high frequency / concurrency, and script-based. An effective countermeasure against scrapers may target either of these characters. In fact, many related works that address the first two factors. For example, the concept Proof of Work (PoF) aims at prolonging the engagement by letting the web server give the user a relatively expensive task, such as finding a nonce whose hash values follows a specific pattern, and asking the requester to return the solution before the requested content is provided. Such work will be negligible for a normal user who browses webpages infrequently, but will become nontrivial for large volume scrapers. Rate limiting is another common method to deal with high frequency, which limits the number of requests from a certain IP address. Although a bot may use proxies to avoid a single IP being heavily used, many bot-defending companies, such as Cloudflare and Datadome, for example, leverage Al- based solutions to detect and block such malicious bots.

[0072] To date, there has been no countermeasure attempting to prevent scrapers targeting the third characteristic, i.e., a scraper that is script-based. A mere solution, if used at all, is to discern the type of client by inspecting the User- Agent request header, which can, however, be easily forged.

[0073] A First Novel CAPTCHA: Design

[0074] The first novel CAPTCHA uses DRM-protected video to deliver a puzzle, such as a puzzle image, to be solved. This seemingly straightforward approach is effective because, as previously described, a DRM-protected video is encrypted and can only be decrypted and played by the CDM module built into a browser. In other words, a script-based bot does not have the ability to decrypt the video, let alone inspect its content.

[0075] To use a DRM-protected video to carry the puzzle image, a regular puzzle image, such as an image containing a set of characters, is first converted into a single-frame video clip, and this video clip is then encrypted using DRM technology. Even just this approach of the first novel CAPTCHA design effectively eliminates the physical capability of a scraper to access the puzzle. Human users, on the other hand, only need demonstrate their physical supremacy, rather than intelligence supremacy, over the bot. Thus, the puzzleDocket: GMU-25-027 does not need to be confusing at all, and a non-distorted text on a plain background is sufficient to tell a human apart from a scraper, in this example embodiment.

[0076] A First Novel CAPTCHA: Discussion

[0077] By using DRM-protected video to deliver the puzzle image, the first novel CAPTCHA effectively prevents scrapers from accessing the puzzle. In order to bypass the first novel CAPTCHA, a scraper has the following two possible moves. The first possible move is for the scraper to evolve itself into a spammer, that is, to use a full-fledged browser to play the video and then make screenshots of the video to access its content. This is addressed below in the discussion of the second novel CAPTCHA. Second, a scraper could forward the puzzle to a CAPTCHA farm. Since farmers solve CAPTCHA puzzles using a browser, they can play this video and solve the puzzle. How to counter this is discussed in below in the third novel CAPTCHA to block CAPTCHA farms.

[0078] As described above, a script-based scraper is unable to solve a first novel CAPTCHA puzzle because it requires a CDM and thus a full-fledged browser to decrypt the video and display the puzzle. To solve the puzzle, a scraper needs to evolve to a spammer and use a web browser to decrypt and play the puzzle video, which significantly increases the required resources of a bot. Meanwhile, it is worth mentioning that automated browsers, such as Selenium, have a “headless” mode that can render web pages in the background, meaning it is not necessary for a bot to have a graphical interface to play the video and make screenshots. This is addressed in the second novel CAPTCHA approach that defends against spammers.

[0079] Reference is made to FIG. 5 in which is a request made by a user to a web server results in a CAPTCHA server returning a puzzle in a DRM-protected video. The puzzle itself may or may not be DRM-protected as will be discussed further. To a human (non-bot) user, the puzzle displays in the monitor and is solvable by the user. The same puzzle, however, may be inaccessible by a bot, as indicated in the drawing.

[0080] With regard to DRM, many CAPTCHA provides an audio alternative to accommodate visually impaired users who have difficulty solving a normal puzzle. A voice track can be integrated with the DRM-protected video, and thus the voice puzzle is also encrypted and cannot be “previewed” by a bot. A voice puzzle is not as versatile as a visual puzzle and thus may not maintain the same security level as we have discussed above. However, since voice puzzles are less commonly used, a bot activity may be identified by tracking the voice puzzle usage pattern. For example, a sudden increase in the volume of the voice puzzle may indicate potential bots.Docket: GMU-25-027

[0081] A Second Novel CAPTCHA: Preventing Spammers

[0082] Recall that a spammer is a type of bot that uses an automated browser to interact with the web server. Therefore, a spammer can play and take screenshots of the DRM- protected video, and then use OCR or other techniques to inspect the content and solve the puzzle, making the first novel CAPTCHA approach ineffective. To fight against spammers, DRM technology in its entirety is leveraged to introduce puzzles based on video clips, i.e., moving pictures, for example.

[0083] A Second Novel CAPTCHA: Video-based CAPTCHA

[0084] Using video clips to deliver CAPTCHA puzzles emerged in the early 2010s. An example is a NuCAPTCHA puzzle, a video clip in which a piece of text keeps floating and changing shape over a diverse background. However, NuCAPTCHA and all other animationbased CAPTCHAs suffer from OCR-based attacks similar to regular text-based CAPTCHAs. To break a video-based puzzle, a bot need only take one extra step to disassemble the video / GIF into discrete frames, thereby allowing the bot to use regular techniques to read those frames and solve the puzzle.

[0085] Using DRM-protected video, on the other hand, is a qualitative leap that makes the second novel CAPTCHA different from other video-based CAPTCHAs, because a DRM- protected video is encrypted and thus cannot be directly analyzed by the bot. In order to access the video’s content, the only solution for a bot is to record the screen and then analyze the recordings, which consumes even more computing resources.

[0086] Motivated by the fact that a bot cannot “preview” the video content until it is being played, in accordance with the second novel CAPTCHA, a special puzzle, the time-sensitive puzzle, is effective to block spammers. Design considerations of the time-sensitive puzzle follows.

[0087] A Second Novel CAPTCHA: Time-sensitive Puzzles

[0088] Although a computer can solve complex problems much faster than a human being, humans can actually outperform computers on tasks that are simple enough and can be accomplished by human instinct or intuition. Using the image shown in FIG. 6 as an example, suppose that the task is simply to click on the person’s feet. This task is so intuitive and can be completed by a human in negligible time. In contrast, it takes a long haul for a computer’s “reflection arc”: a computer (bot) must analyze the complete image and use advanced algorithms to recognize the person’s feet, and then calculate the coordinates and simulate a mouse-click at the correct location. One may argue that once trained using sufficient datasets, an Al model may recognize a particular object much faster than aDocket: GMU-25-027 human, however, it is effortless to switch the target to the person’s head, hand, body, etc., rendering any particular pre-trained Al model ineffective.

[0089] Human perception, particularly in the visual domain, operates with remarkable speed, enabling the human to rapidly understand and interact with complex environments. Seminal research has demonstrated that the human brain can process and categorize complex visual stimuli, such as identifying animals in natural scenes, in as little as 150 milliseconds, as indicated by neural markers. Further studies have shown that even the meaning of visual stimuli can be extracted from images presented for extremely brief durations, with individuals identifying images seen for as little as 13 milliseconds. This rapid processing is also evident in motor responses; for instance, humans can initiate accurate saccadic eye movements towards targets in natural scenes based on visual processing that occurs within approximately 100-120 milliseconds. These findings underscore the brain’s extraordinary efficiency in making sense of visual input on very short timescales.

[0090] Based on the observations listed above, time-sensitive puzzles in accordance with the second novel CAPTCHA are designed to be solved within a time limit. The puzzle is designed to be simple enough that it can be instantly solved by human instinct but will take a bot a discernibly longer time to solve (such as a few seconds). This time-difference is exploited by strategically setting the time limit. For example, a variety of approaches may be used, such as setting the time limit to be a mid-point of these two puzzle-solving times.

[0091] A very intuitive example is to create a 5-second video, where a black dot appears at a random location on a white background at a random time, and the user is asked to click on the dot once the dot appears. The coordinate of the click, as well as the time when the click happens, will be immediately transmitted to the CAPTCHA server to validate its correctness. The DRM video can be preloaded to the browser but the license request holds until the user is ready to solve the puzzle. For example, the user can be asked to click a button to trigger the license request. Since the license request and response take a fraction of second to complete, it is reasonable to let the CAPTCHA server start its timer when the license request is received, and reject a solution if it is received after 5 seconds, i.e., when the video play back is finished.

[0092] The description above is a simple example of the time-sensitive puzzle, where the difficultness, video length, and time limit can all be practically fine-tuned. For example, the above example, i.e., a black dot on a white background, can be easily solved in a fraction of seconds by an Al model with proper training; however, the video clip merely acts as a container and can be filled with any content with highly diverse challenges. For example,Docket: GMU-25-027 instead of showing a black dot on a white background, the puzzle can change, e.g., to ask the user to click on a butterfly that appears in a bush of flowers or to click on the left eye of a cat when it appears in the video. Such changes makes negligible differences for a human as long as the object of the puzzle falls within a human’s common sense. However, without sufficiently labeled training set to train a model, such tasks may not even be solvable by an Al model at all. For instance, consider providing the cat image in FIG. 7, obtained from Wikipedia, to five popular general purpose Al models, including Google Gemini, ChatGPT 4o, Claude Sonnet 4, DeepSeek, and Meta Llama-4 and asked them to find the coordinate of the left eye of the cat. Gemini and DeepSeek directly refused this request, stating that its capabilities are limited to understanding the content of the image and providing general information, and does not have the ability to perform precise pixel-level analysis. The other three models, although accepting this job, all gave incorrect solutions. For example, ChatGTP claims to have successfully finished the task in 0.49 seconds, but the solution was completely wrong; its identified location of the left eye is highlighted by the red circle in the lower left comer of FIG. 7. ChatGPT also offered the Python code to accomplish this task locally, inspection of which revealed the use of cv2.HoughCircles() function to detect circular features and make the assumption that circles were the eye. Solving this task using any local models was not attempted, as such task is doomed to fail in view of no labeled data to train these models.

[0093] Moreover, in addition to asking the user to click on something, the time-sensitive puzzle can be given in many other different forms. For instance, a slider-puzzle, in which the background is displayed using DRM-protected video, can be used. Or, the user can be asked to move their mouse to follow a moving object in the video and track the user’s mouse moving trajectory. In summary, a time-sensitive puzzle can take any form as long as it is simple enough for a human to accomplish within negligible time but will cost a discemibly longer time and resources for a bot to solve.

[0094] In accordance with the teachings of the second novel CAPTCHA approach, it can be seen that in order to defeat spammers, physical differences between humans and bots, that is, the time they use to react to simple tasks, is exploited. Although there is no doubt that bots are much faster at solving complex tasks, for a simple task such as seeing and immediately reacting to a picture, a human still bears the advantage.

[0095] Intuitively, humans are good at making quick judgmental decisions that follow “common sense,” e.g., big versus small, left versus right, black versus white, etc., and aggregating these puzzles together does not hinder a human from making their decisionsDocket: GMU-25-027 more quickly. For instance, a puzzle can be designed as displaying a group of cats and asking the user to click “the left eye of the smaller white cat.” From the Al’s perspective, however, this disassembles into three separate tasks (i.e., the left eye, the smaller cat, and the white cat) and each may require significant calculation. The comparison of decision-making time between humans and Al models, as well as designing effective puzzles is used to reliably tell humans apart from computers.

[0096] Furthermore, the time-sensitive puzzle can also be applied to non-encrypted static images and unencrypted videos, although with potentially reduced effectiveness and user experience. For example, a 2-step puzzle can be designed as follows. In the first step, text is used to tell the user that they will be presented with an image / video and they are asked to identify and click on a specific object. When the user is ready to engage and solve the puzzle, they will indicate their readiness, e.g., by clicking a button, and only by this time will an image or a video clip be delivered to the browser, and the server starts the timer. In order to be recognized as a human, the user must correctly identify and click the object within a limited time, such as 5 seconds. This approach can technically achieve the same objective but may not be as effective as the DRM-video based approach for the following reasons.

[0097] A non-encrypted video is accessible by the bot immediately upon reaching the browser, granting it an extended period to solve the puzzle. While a static image must present all information simultaneously, a video has the capability to reveal this information progressively. For instance, if the challenge involves identifying a cat among a collection of animals, a video can show these animals sequentially, unlike an image where all animals appear at once, potentially increasing the time a human user requires to fully comprehend the content of the image, therefore potentially reducing the time difference between a human and a bot. On the other hand, a DRM-protected video forces a bot to start watching the video at the same time and with the same pace as a human, eliminating its possibility to “cheat.” Furthermore, as will be explained below, only the DRM-protected puzzle can be used in the third novel CAPTCHA to block CAPTCHA farms. To summarize, when a puzzle reaches a level of complexity where solving it locally becomes impractical or too costly, a bot might turn to a CAPTCHA farm as a final option. In the following section, the third novel CAPTCHA and its ability to identify and prevent the use of CAPTCHA farms is presented.

[0098] Referring to FIG. 8, a communication network with a browser, web server and CAPTCHA server in which the time-sensitive puzzles of the second novel CAPTCHA approach is illustrated.

[0099] A Third Novel CAPTCHA: Preventing CAPTCHA FarmsDocket: GMU-25-027

[0100] Referring now to FIG. 9, a communications network with a browser, web server and CAPTCHA server demonstrates, from a high-level, there are essentially four message exchanges between the client and the web / CAPTCHA server. In Step 1, the client, such as a browser, requests web resources from the web server. The web server does not respond with the requested resource, but instead responds with a set of parameters that the client can use to retrieve a CAPTCHA puzzle from the CAPTCHA server. These parameters may include a sitekey that is used by the CAPTCHA server to identify the specific website, and a JavaScript that interacts with the CAPTCHA server and constructs the puzzle in the browser.

[0101] In Step 2, the client contacts the CAPTCHA server with the sitekey and any other essential parameters (not depicted in the figure for brevity), and the CAPTCHA server will respond with a puzzle to display in the browser.

[0102] In Step 3, the client solves the puzzle and submits the solution to the CAPTCHA server. The CAPTCHA server makes a decision about whether the client is a human or a bot based on the solution, and returns a token that is associated with this decision.

[0103] In Step 4, the client sends the token to the web server, which then passes this token to the CAPTCHA server. The CAPTCHA server informs the web server whether the client associated to this token is human. If confirmed as human, the web server grants the client access to the requested resources.

[0104] FIGs. 10A and 10B illustrate two scenarios in which a CAPTCHA farm is involved, depending on the particular puzzle type. In FIG. 10A, a farmer pulls and solves a puzzle directly from the CAPTCHA server and obtains a token, and then passes this token to the client. In FIG. 10B, a farmer receives a puzzle forwarded by the client and returns the solution, and the client will submit the solution and get the token. In both cases, the CAPTCHA server will regard the user as a human because the puzzle was solved by the farmer, who is a real human. Consequently, when the web server validates the token with the CAPTCHA server, the latter will inform the web server that the token is associated with a human, even though it is actually submitted by the bot.

[0105] A Third Novel CAPTCHA: CAPTCHA Farm Detection and Blocking

[0106] Comparing the message flows in FIG. 9 and FIGs. 10A, 10B, it is clear that to completely block a CAPTCHA farm, it is crucial to ensure all four message exchanges occur solely between the initial client and the web / CAPTCHA server, without the involvement of any third parties.

[0107] In the scenario depicted in FIG. 10A, the farmer is the one who interacts with the CAPTCHA server to pull the puzzle and submit the solution in exchange for a token, whileDocket: GMU-25-027 the browser is the one who submits the token to the web server. Therefore, the web server and the CAPTCHA server will see different IP addresses of the client who obtained the token from the CAPTCHA server, and who submitted the token to the web server. Leveraging this fact, some CAPTCHA vendors prevent CAPTCHA farms by asking the web server to submit a remotelP parameter, the IP address of the client who submitted the token to the web server, to the CAPTCHA server when validating the token. The CAPTCHA server may detect the possible usage of a CAPTCHA farm when the remotelP differs from the IP of the client that received the token.

[0108] However, this remotelP parameter is not strictly enforced by CAPTCHA vendors. While we are unable to find specific reasons for why the remotelP is not enforced, the reasons may be as follows. In most cases, the web server and the CAPTCHA server belong to two separate stakeholders and may be hosted on networks with vastly different architectures, which may cause the two servers to see different IP addresses even though they are actually communicating with the same client. For example, a web server may be placed behind a reverse proxy or a load balancer that intercepts requests and responses. In this case, the web server is unable to see the IP of the original client unless the proxy / load balancer is configured to inform the web server of such information. Further, often the token received by the browser from the CAPTCHA server is not immediately forwarded to the web server. Consider a scenario involving user login. Typically, the user will enter his username and password and then solve the puzzle. The token will be delivered to the browser once the puzzle is solved, which will be submitted, alone with the entered username and password, when the user clicks the “log in” button. However, such a submission may not take place immediately after the token is received. For example, after the puzzle is solved and token received by the browser, the user may have been distracted by other tasks and does not click the “log in” until a few minutes later. Regular CAPTCHAs are designed to accommodate such cases. For example, Google re-CAPTCHA and Cloudflare Turnstile allow their tokens to stay valid for 2 and 5 minutes, respectively. During such a long time, the client’s IP address may have legitimately changed. For instance, the IP address of a mobile device can change frequently if its user is in transit. Alternatively, the user might use a proxy or VPN service that regularly alters the egress IP address.

[0109] Furthermore, relying on comparing the IP address to detect and block CAPTCHA farms is not a reliable solution, as it can be bypassed by letting the bot and the farmer share the same proxy. For example, 2CAPTCHA provides APIs to let a bot pass proxy information to a farmer. Therefore, to practically detect and block a CAPTCHA farm, a finer-grainedDocket: GMU-25-027 solution is necessary to ensure that these requests are not only sent from the same IP, but also from the same client. However, detecting different clients behind a proxy is a non-trivial task. Existing approaches mainly focus on browser fingerprinting, where the web server uses client information, such as request headers, to tell if two requests are sent by the same client. Browser fingerprinting is not reliable since a browser’s request headers are controlled by the user. 2CAPTCHA also provides APIs to let a bot forward all its request headers to a farmer such that a farmer can mimic the bot’s client.[001 10] A Third Novel CAPTCHA: Design[001 1 1 ] As shown in FIGs. 10A and 10B, to effectively prevent a CAPTCHA farm, all activities, including pulling, solving, and submitting the solution of the puzzle, and obtaining and submitting the token, are carried out by the same client. Essentially, this observation results in the following two premises:• The client who requested the puzzle from the CAPTCHA server must be the same one who solves the puzzle and submits the solution. This is referenced herein as the solution-submission action.• The client who submitted the solution to, and obtain the token from, the CAPTCHA server must be the same one who submits the token to the web server. This is referenced herein as the token-submission action.[001 12] Note that the solution-submission and token-grant may be within one request / response cycle between the client and the CAPTCHA server, as shown in Step 3 in FIG. 9. Therefore, the client that submitted the solution must be the same one that receives the token directly from the CAPTCHA server. As explained above, checking the client’s IP addresses can only enforce the second premise to a certain extent; that is, the client that obtained the token and the one that submitted the token are using the same IP address. And this mechanism becomes ineffective when both clients share the same proxy.[001 13] The third novel CAPTCHA, on the other hand, is able to enforce both premises even when a proxy is present. The message flow chart of the third novel CAPTCHA is presented in FIG. 11, with example, detailed mechanisms described below. Note that many non-critical message exchanges are intentionally simplified or removed in order to highlight the most essential processes.[001 14] A Third Novel CAPTCHA: Enforcing the Solution-Submission Premise.[001 15] The first premise of the solution-submission action is enforced by using the DRM- protected and time-sensitive puzzle as explained before in connection with the second novelDocket: GMU-25-027CAPTCHA. Specifically, the approach limits the license of a puzzle so that it can only be pulled once. For example, the encryption key of a particular puzzle is deleted once its corresponding key ID has been requested. Doing this ensures that the encrypted video can only be played once in one browser. To forward the puzzle to someone else, the only solution would be for the first browser to make a recording of the DRM-protected video and forward it to the third party. However, leveraging the concept of the time-sensitive puzzle, we set the time limit to be the length of the video. As a result, by the time a third-party receives the video recording, it means the video has finished playing and thus no solution will be accepted any longer by the CAPTCHA server. Essentially, the implementation is a puzzle that is unforwardable: the puzzle can only be solved by the client who pulled it from the CAPTCHA server.[001 16] A Third Novel CAPTCHA; Enforcing the Token-Submission Action.[001 17] The second premise of the token-submission action is enforced by leveraging another feature of the DRM technology, that is, a Device ID is included in each license request, which is unique to each device and cannot be accessed or modified by the client. In order to do that, the following changes are made to the system:[001 18] First, the entitlement server will be integrated into the web server. Ideally, the entitlement server will be converted to an endpoint that is collocated with the web service. For example, ifthe web server has the domain example.com, the entitlement service can be set at example.com / entitlement. This is to ensure requests sent by the same client to the web server and the entitlement server will take approximately the same time, as will be elaborated shortly in the following.[001 19] Second, on the client side, when it is time for the client to submit the token to the web server, the client is asked to make a second attempt to play the DRM-protected video, which will trigger a second license request to the entitlement server. This can be achieved with JavaScript.

[0120] As shown in Step 4 in FIG. 11, when the token is to be submitted, two requests will take place simultaneously. The first is the token submission sent by the browser to the web server, and the second is the license request sent by the CDM to the entitlement server. Since the CDM is integrated with the browser and the entitlement server is integrated with the web server, both requests will physically be sent from the browser to the web server, and thus will arrive at the web server almost simultaneously. Conversely, coordinating two clients on distinct machines to send requests that would reach the same web server simultaneously is almost impossible. Essentially, the time interval between the arrival of theDocket: GMU-25-027 two requests becomes a valid oracle to tell if both requests are actually sent from the same client. Note that the actual threshold of such interval should be set based on practical trial and will differ based on specific web server configurations. However, in any normal case, It would be quite unexpected for two sequential requests from the same client to the same web server to have a time difference exceeding 1 second.

[0121] Meanwhile, when the second license request is received by the entitlement service, it will extract the Device ID and compared it with the one contained in the first license request that was sent in Step 2 of FIG. 11. Note that the second license request is merely for the purpose of letting the entitlement service check the Device ID of the client, and therefore the license does not need to be returned to the browser.

[0122] In light of the foregoing, essentially the following three facts are relevant:• The second license request and the token are sent by the same client because both requests reached the web server simultaneously.• The second and the first license requests are sent by the same client because both requests contain the same Device ID.• The client who sent the first request must have solved the puzzle by itself because the DRM-protected and time-sensitive puzzle cannnot be forwarded to a third party.Based on these three facts, it is not difficult to deduce that it is the same client who pulled and solved the puzzle, submitted the solution and received the token, and submitted the token. On the other hand, if the entitlement server sees two different Device IDs, or the token submission request and the second license request reached the web server with a time interval larger than a threshold, it is a strong indication that a CAPTCHA farm is involved.

[0123] It has been demonstrated that the third novel version of CAPTCHA can not only defend against scrapers and spammers, but also detect and block the use of a CAPTCHA farm. It is noteworthy that FIG. 11 only demonstrates one possible implementation.Alternatively, the entitlement server does not need to be collocated with the web server. For instance, it can be collocated with the CAPTCHA server instead. In this case, the token submission request and the second license request will be sent to two different servers, leading to an unavoidable difference in their arrival time. However, as long as the logic is deterministic (for example, the web server always immediately forwards the token to the CAPTCHA server) and the communication between the web and the CAPTCHA server is stable, such time difference can be practically determined and, therefore, be offset for the time interval calculation.Docket: GMU-25-027

[0124] Referring now to FIG. 12, flow 1200 illustrates a method of ensuring delivery of media content to users. At block 1210, responsive to a request for media content initiated by a user client and received by a web server from the user client, deliver to the user client a digital rights management (DRM)-protected media containing a puzzle that is solvable by a human. As noted above, the puzzle itself may or may not be DRM-protected as well. At block 1220, the puzzle is played by a content decryption module (CDM) of the user client, the puzzle viewable by a human when the drm-protected media is played. At block 1230, the status of the user is determined as a permissible single entity user or a non-permissible user based upon analyzing physical solution characteristics of the user associated with puzzle solution activity. Finally, one or more actions are taken, depending on the status of the user. At block 1240 the requested media content is provided to the user client when the status of the user is a permissible single entity user that is a permissible human user and conversely, the requested media content is not provided to the user client when the status of the user is a non-permissible user.

[0125] A Fourth Novel CAPTCHA: CAPTCHA Farm Detection and Blocking

[0126] A Fourth Novel CAPTCHA: Persistent HTTP

[0127] HTTP uses TCP as its transport layer protocol. For HTTP 1.0 and earlier versions, one TCP connection only affords one HTTP request-response session. For example, if the client wants to issue 10 HTTP requests, even to the same web server, the client would have to open 10 separate TCP sessions with the server to carry these 10 HTTP requests. This design has became inefficient as Web applications are becoming more popular and related technologies are complicated.

[0128] The concept of persistent HTTP was introduced in HTTP 1.1 to allow the client and the server to exchange multiple HTTP messages over one TCP session. To do this, the client and server will include a “Connection: keep-alive” header to inform each other the intention to keep the TCP session open.

[0129] The persistent HTTP works slightly differently when a proxy is introduced between the client and the web server. The term “proxy” is commonly used to refer to both HTTP proxy and HTTP tunnel. An HTTP proxy acts as a man-in-the-middle, which actively receives, and forwards, messages exchanged between the browser and the server. If HTTPS is used, a proxy establishes two separate TLS sessions with the client and the server. In such case, because the browser wants to visit the domain hosted on the web server, but the certificate received from the TLS handshake is actually from the proxy, a modern browser will refuse to connect because it does not recognize the certificate provided by the proxy.Docket: GMU-25-027

[0130] An HTTP tunnel, on the other hand, acts as a bridge that still establishes two separate TCP sessions with the browser and the server, but allows a single TLS session to be established between the client and the server. Proxy services available online, such as Zenrows and Oxylabx.io, are actually tunnels. Following convention, the terms “proxy” and “proxy server” are used to refer to the server that provides the HTTP tunnel service.

[0131] According to htps: / / datatracker.ietf.org / doc / html / rfc7231 #section-4.3,6, to initiate a tunnel with the web server through a proxy server, the browser will send a HTTP CONNECT request to the proxy server, with the Host header value being the targeted domain and port number, for example:CONNECT server. example. com:443 HTTP / 1.1Host: server.example.com:443

[0132] The proxy server will respond with a 2xx status code to the browser indicating the tunnel has been established. From then on, the browser will send all data to the proxy server using CONNECT method and the proxy server will blindly forward packets in both directions.

[0133] The persistent HTTP and the proxy server's behavior provide a valid oracle for a web server to tell if it is communicating with the same client even though the server's view is blocked by a proxy. Referring to FIG. 13, there are shown two clients behind a proxy, and client 1 initiated an HTTPS session with the web server in this example. Since the client and the server intend to keep the HTTP session alive, they both will maintain the TCP session with the proxy. Therefore, all the messages relayed by the proxy server will be sent to the web server using the same TCP port number as long as the TCP session between the proxy and the web server is kept alive. From the server side, it will be seen that these HTTPS requests are always from the same IP address and from the same TCP port number. Meanwhile, if client 2 wants to send requests to the web server through the same proxy server, the proxy server will open a separate TCP session with the web server, resulting in client 2's requests being sent to the web server from a different port number. Essentially, the web server can tell if the requests are sent by different clients behind a proxy by inspecting the TCP port number used by the proxy server.

[0134] A Fourth Novel CAPTCHA: Detection and Blocking of CAPTCHA Farms

[0135] Referring now to FIG. 14, note that some message flows are intentionally simplified and skipped, in order to highlight more important details; the details of simplified and skipped messages are depicted in previous figures.

[0136] To effectively block a CAPTCHA farm, the fourth novel CAPTCHA approaches ensures that it is the same client who pulled the puzzle from the CAPTCHA server, solved theDocket: GMU-25-027 puzzle, submitted the solution to the CAPTCHA server, received the token from the CAPTCHA server, and submitted the token to the web server. Essentially, this is based upon the following two premises, previously descried as the solution-submission and tokensubmission actions, respectively:• The client who requested the puzzle from the CAPTCHA server must be the same one who solves the puzzle and submits the solution; and• The client who submitted the solution to and obtained the token from the CAPTCHA server must be the same one who submits the token to the web server.

[0137] As explained above, checking the client's IP address can only enforce the second premise, under the condition where the bot and the farmer are not sharing a HTTP proxy.

[0138] In accordance with the fourth novel CAPTCHA, the first premise of solutionsubmission is enforced by using the DMR-protected and a time-sensitive puzzle, discussed previously. Specifically, the limitation is that the license of a puzzle can only be pulled once; for example, the key is deleted once its corresponding key ID has been requested once. By doing this ensures that the encrypted video itself cannot be forward to and played in a second browser. Furthermore, the limitation that the solution of a puzzle must be submitted by the end of the video is introduced; therefore, it would be very difficult for a bot to record the video and send the recording to someone else. This approach essentially ensures that those who have requested the license to play the puzzle must solve this puzzle themselves.

[0139] The second premise of token-submission is enforced by leveraging both the DRM- protected puzzle as well as the persistent HTTP, described above. The following changes are introduced:• Integration of the entitlement server as an endpoint that is collocated with the web server, such that the web server and the entitlement server have the same IP address. For example, if the website has the domain example.com, the entitlement service can be given a path example.com / entitlement. Note that the entitlement server is a proxy server that interacts with the CDM on behalf of the license server, which can make decisions if a license request should be honored. If yes, the entitlement server will forward the license request to the license server and forward the license back to the CDM.• On the client side, the client is required to make a second attempt to play the DRM- protected video the same time when it submits the token to the web server, which can be implemented using JavaScript or other programming languages.Docket: GMU-25-027

[0140] As shown in step 4 in FIG. 14, two requests will take place simultaneously: the request sent by the browser to the web server and the request sent by the CDM to the entitlement server. Since the CDM is a module integrated with the browser and the entitlement server is integrated with the web server, both requests will share the same TCP session due to persistent HTTP. Therefore, on the web server side, it will observe both requests coming from the same port, regardless of whether a proxy is used or not.

[0141] Upon receiving the license request, the entitlement server will check the Device ID contained within, and compare it with the Device ID in the first license request.

[0142] This fourth novel CAPTCHA therefore has the following three characteristics:• The second license request and the token are sent by the same client because both requests are from the same port number.• The second and the first license request are sent by the same client because both requests contain the same Device ID.• The client who sent the first request must solve the puzzle by itself.

[0143] Based on the above, it is deduced that it is the same client who pulled the puzzle, submitted the solution and received the token, and submitted the token. Also note that the second license request is merely for the purpose of letting the entitlement server to check the identity of the client, and thus a license does not need to be returned to the client.

[0144] It is also worth noting that, in a less strict case, it is not necessary to leverage the persistent HTTP. As explained above, the purpose of using persistent HTTP, i.e., checking the port number of the second license request and the token submission request, is to ensure that both requests are indeed sent from the same client. Instead of checking and comparing the port number of both requests, the fourth CAPCHA checks the time interval when the two requests arrive at the web server as shown in FIG. 14. Because these two requests are triggered by a single event, and are both sent to the same web server, they should arrive at the web server almost simultaneously, and thus the arrival time interval should be at the millisecond level. It is almost impossible to coordinate two clients to send two requests that can arrive at the web server within such a short interval. Therefore, in the case in which both requests arrive within a short time limit, such as 1 second, it is safe to regard both requests are sent from the same client. On the other hand, if the time interval is too large, such as 5 seconds, it is a strong indication that something is wrong, and the web server should not accept the token submission.

[0145] Improved bot defense structures and methods have been described that address weaknesses of current CAPTCHA systems. Specifically, novel CAPTCHA approaches, whenDocket: GMU-25-027 applied under various settings, can effectively counter scrapers, spammers, and even CAPTCHA farms and is a valuable resource in combating bots and enhancing website security on today’s Internet. These various approaches of novel CAPTCHA can be used singly or in combination as described above.

[0146] As recited in this disclosure, various embodiments provide a novel method and system to ensure deliver of media content to actual users, not bots, in a communications network such as the Internet.

[0147] The following embodiments are combinable.

[0148] Therefore, in one embodiment of the disclosure, an example web-based communication system operable to ensure delivery of media content to humans is provided. The web-based communication system has a web server and a user client including a content decryption module (CDM) and operable to communicate with the web server and with a user, where responsive to a request for media content received by the web server from the user client, the web server delivers to the user client a digital rights management (DRM)-protected media containing a puzzle and solvable by a human, said puzzle viewable by a human when the DRM-protected media is played by the CDM of the user client, and where at least the web server is operable to perform analysis to determine the status of the user that communicates with the web server as a permissible human user or a non-permissible bot user, said analysis based at least in part on physical solution characteristics of the user in solving the puzzle.

[0149] In one embodiment of the disclosure, an example method of ensuring delivery of media content to users is provided, including: responsive to a request for media content initiated by a user client and received by a web server from the user client, delivering to the user client in communication with a user a digital rights management (DRM)-protected media containing a puzzle that is solvable by a human; playing the puzzle by a content decryption module (CDM) of the user client, said puzzle viewable by a human when the DRM-protected media is played; and determining the status of the user as a permissible single entity user or a non-permissible user based upon analyzing at least physical solution characteristics of the user associated with solution activity of the puzzle. Further, the method includes providing the requested media content to the user client when the status of the user is a permissible single entity user that is a permissible human user, and / or not providing the requested media content to the user client when the status of the user is a non-permissible user.

[0150] In another embodiment, user client is a browser with the CDM.Docket: GMU-25-027

[0151] In another embodiment of the system, determination of the status of the user is based upon at least physical differences between computers and humans, distinguishable from intelligence differences between humans and computers, in solving the puzzle.

[0152] In another embodiment, the physical solution characteristics of the user include one or more of perception of the puzzle by the user and reaction time by the user to an interactive task of the puzzle, the perception of the puzzle and the reaction time by the user are physical solution characteristics of the user associated with solution activity by the user of the puzzle.

[0153] In another embodiment, perception of the puzzle by the user includes delivery of an encrypted media by the web server to a user, the DRM-protected media encrypted and containing the puzzle that is viewable by a human when the DRM-protected media is opened and played by the user client with CDM, but is inaccessible by one or more bots on the system.

[0154] In another embodiment, the puzzle is a puzzle image converted into a video clip of the encrypted media that is encrypted using DRM.

[0155] In another embodiment, the video clip is a single frame.

[0156] In another embodiment, the video clip is a container containing the puzzle.

[0157] In another embodiment, the puzzle is a voice puzzle and video clip further includes audio.

[0158] In another embodiment, the bots on the system are automated programs.

[0159] In another embodiment, reaction time by the user to an interactive task is determined by a time-sensitive puzzle, with the reaction time to the interactive task determined by one or more of difficulty in solving the time-sensitive puzzle, a length of the DRM-protected media, and a determined time limit.

[0160] In another embodiment, the time-sensitive puzzle is DRM-protected media.

[0161] In another embodiment, the time-sensitive puzzle blocks spammers.

[0162] In another embodiment, the time-sensitive puzzle is operable to be solved within a time limit that is solvable by a human but not solvable by bots on the system.

[0163] In another embodiment, the user triggers initiation of a timer that tracks the time limit.

[0164] In another embodiment, a response by the user to solve the time-sensitive puzzle includes one or more of the user selecting, sliding or moving elements within the timesensitive puzzle to solve the time-sensitive puzzle.

[0165] In another embodiment, the time limit is determined in view of a human time limit to solve the time-sensitive puzzle and a bot time limit to solve the time-sensitive puzzle.Docket: GMU-25-027

[0166] In another embodiment, a verification server is operable to communicate with the web server, at least one of the web server and the CAPTCHA server operable to determine the status of the user by performing analysis based at least in part on physical solution characteristics of the user in solving the puzzle, with one or more of the web server and the verification server blocking sending of the requested media content to the user when the user is determined to be a non-permissible bot user.

[0167] In another embodiment, requesting the media content, solution activity of the puzzle, and / or transmission of a solution of the puzzle by the user are physical solution characteristics of the user and responsive to verification that the user that requested the media content did not also solve the puzzle provided by the verification server and submit a solution of the puzzle to the web server, said solution also provided to the verification server, the web server and the verification server in cooperative arrangement determine that the user is a non- permissible bot that is not a single entity and do not provide the requested media content to the user.

[0168] In another embodiment, requesting the media content, solution activity of the puzzle, and transmission of a solution of the puzzle by the user are physical solution characteristics of the user and responsive to a determination that the user that requested the media content also solved the puzzle provided to the user by the verification server and submitted a solution of the puzzle to the web server, the solution is also provided to the verification server; the web server and the verification server in cooperative arrangement determine that the user is a single entity that is a permissible human user and provide the requested media content to the single entity user.

[0169] In another embodiment, a solution-submission action and a token-submission action performed by the user are physical solution characteristics of the user, where the web server and the verification server in cooperative arrangement verify whether the solutionsubmission action and the token-submission action are both performed by the user and the user is the single entity user.

[0170] In another embodiment, the solution-submission action and the token-submission action are performed by the single entity user within request / response cycles between the user and the verification server.

[0171] In another embodiment, verification of performance of the solution-submission action by the user includes determination that the user that requested the media content and responsively received the puzzle from the verification server solved the puzzle and submitted the solution to the web server and the verification server.Docket: GMU-25-027

[0172] In another embodiment, verification of the solution-submission action by the user further includes the web server limiting the user to a single license request by the user for the puzzle.

[0173] In another embodiment, the web server deletes an encryption key of the puzzle once a key ID of the puzzle has been requested.

[0174] In another embodiment, verification of the token-submission action by the user includes determination by one or more of the web server and the verification server that a token obtained by the user from the verification server in response to submission of the solution is submitted to the web server by the user.

[0175] In another embodiment, verification of the token-submission action by the client includes determination by one or more of the web server and the verification server that a token obtained by the user from the verification server in response to submission of the solution is submitted to the web server by the user.

[0176] In another embodiment, verification of the token-submission action by the single entity further includes verification that sequential requests sent by the user to the web server and an entitlement server in cooperative arrangement with the web server arrive at approximately the same time and where submission of the token to the web server triggers a subsequent license request to the entitlement server.

[0177] In another embodiment, verification further includes verification that a token request sent by the user client on behalf of the user to the web server and the subsequent license request sent by the content decryption module (CDM) of the browser to the entitlement server arrive at the web server at approximately the same time, the entitlement server integrated with the web server.

[0178] In another embodiment, further including the entitlement server that extracts a device ID of the subsequent license request and compares the extracted device ID of the subsequent license request with a device ID of a previous license request, with each device ID unique to a device and not accessible or modifiable by the user, where matching of the extracted device ID of the subsequent license request and the device ID of the previous license request verifies that the subsequent license request and the previous license request were sent by the same device and the user of the user device is a single entity.

[0179] In another embodiment, the web server and verification server prompt the user to attempt playing the puzzle causes and trigger the subsequent license request to the entitlement server.Docket: GMU-25-027

[0180] In another embodiment, verification of the token-submission action by the single entity further includes verification that sequential requests sent by the user to the web server and an entitlement server in cooperative arrangement with the web server are from the same port and where submission of the token to the web server triggers a subsequent license request to the entitlement server.

[0181] In another embodiment, further including the entitlement server, where the entitlement server and the web server have a same IP address and where the entitlement server communicates with the CDM of the user device on behalf of a license server.

[0182] In another embodiment, the web server and / or verification server prompt the user to attempt playing the puzzle causes and trigger the subsequent license request to the entitlement server.

[0183] In another embodiment, the user received the token directly from the verification server.

[0184] Embodiments are operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, and / or configurations that may be suitable for use with various embodiments include, but are not limited to, embedded computing systems, personal computers, server computers, mobile devices, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, medical device, network PCs, minicomputers, mainframe computers, cloud services, telephonic systems, distributed computing environments that include any of the above systems or devices, and the like.

[0185] Embodiments may be described in the general context of computer executable instructions, such as program modules, being executed by computing capable devices. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Some embodiments may be designed to be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local

[0186] While implementations of the disclosure are susceptible to embodiment in many different forms, there is shown in the drawings and will herein be described in detail specific embodiments, with the understanding that the present disclosure is to be considered as an example of the principles of the disclosure and not intended to limit the disclosure to theDocket: GMU-25-027 specific embodiments shown and described. In the description above, like reference numerals may be used to describe the same, similar or corresponding parts in the several views of the drawings.

[0187] In this document, relational terms such as first and second, top and bottom, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. The terms “comprises,” “comprising,” “includes,” “including,” “has,” “having,” or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element preceded by “comprises . . .a” does not, without more constraints, preclude the existence of additional identical elements in the process, method, article, or apparatus that comprises the element.

[0188] Reference throughout this document to “one embodiment,” “certain embodiments,” “an embodiment,” “implementation(s),” “aspect(s),” or similar terms means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Thus, the appearances of such phrases or in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments without limitation.

[0189] The term “or” as used herein is to be interpreted as an inclusive or meaning any one or any combination. Therefore, “A, B or C” means “any of the following: A; B; C; A and B; A and C; B and C; A, B and C.” An exception to this definition will occur only when a combination of elements, functions, steps or acts are in some way inherently mutually exclusive. Also, grammatical conjunctions are intended to express any and all disjunctive and conjunctive combinations of conjoined clauses, sentences, words, and the like, unless otherwise stated or clear from the context. Thus, the term “or” should generally be understood to mean “and / or” and so forth. References to items in the singular should be understood to include items in the plural, and vice versa, unless explicitly stated otherwise or clear from the text.

[0190] Recitation of ranges of values herein are not intended to be limiting, referring instead individually to any and all values falling within the range, unless otherwise indicated, and each separate value within such a range is incorporated into the specification as if it were individually recited herein. The words “about,” “approximately,” or the like, whenDocket: GMU-25-027 accompanying a numerical value, are to be construed as indicating a deviation as would be appreciated by one of ordinary skill in the art to operate satisfactorily for an intended purpose. Ranges of values and / or numeric values are provided herein as examples only, and do not constitute a limitation on the scope of the described embodiments. The use of any and all examples, or exemplary language (“e.g.,” “such as,” “for example,” or the like) provided herein, is intended merely to better illuminate the embodiments and does not pose a limitation on the scope of the embodiments. No language in the specification should be construed as indicating any unclaimed element as essential to the practice of the embodiments.

[0191] For simplicity and clarity of illustration, reference numerals may be repeated among the figures to indicate corresponding or analogous elements. Numerous details are set forth to provide an understanding of the embodiments described herein. The embodiments may be practiced without these details. In other instances, well-known methods, procedures, and components have not been described in detail to avoid obscuring the embodiments described. The description is not to be considered as limited to the scope of the embodiments described herein.

[0192] In the following description, it is understood that terms such as “first,” “second,” “top,” “bottom,” “up,” “down,” “above,” “below,” and the like, are words of convenience and are not to be construed as limiting terms. Also, the terms apparatus, device, system, etc. may be used interchangeably in this text.

[0193] The many features and advantages of the disclosure are apparent from the detailed specification, and, thus, it is intended by the appended claims to cover all such features and advantages of the disclosure which fall within the scope of the disclosure. Further, since numerous modifications and variations will readily occur to those skilled in the art, it is not desired to limit the disclosure to the exact construction and operation illustrated and described, and, accordingly, all suitable modifications and equivalents may be resorted to that fall within the scope of the disclosure.

Claims

Docket: GMU-25-027WHAT IS CLAIMED IS:

1. A web-based communication system operable to ensure delivery of media content to humans, comprising: a web server; and a user client including a content decryption module (CDM) and operable to communicate with the web server and with a user, where responsive to a request for media content received by the web server from the user client, the web server delivers to the user client a digital rights management (DRM)-protected media containing a puzzle and solvable by a human, said puzzle viewable by a human when the DRM-protected media is played by the CDM of the user client, and where at least the web server is operable to perform analysis to determine the status of the user that communicates with the web server as a permissible human user or a non-permissible bot user, said analysis based at least in part on physical solution characteristics of the user in solving the puzzle.

2. The system of claim 1, where the user client is a browser with the CDM.

3. The system of claim 1, where said determination of the status of the user is based upon at least physical differences between computers and humans, distinguishable from intelligence differences between humans and computers, in solving the puzzle.

4. The system of claim 1, where the physical solution characteristics of the user are distinguishable from intelligence solution characteristics of the user.

5. The system of claim 1, where the physical solution characteristics of the user include one or more of perception of the puzzle by the user and reaction time by the user to anDocket: GMU-25-027 interactive task of the puzzle, the perception of the puzzle and the reaction time by the user are physical solution characteristics of the user associated with solution activity by the user of the puzzle.

6. The system of claim 5, where perception of the puzzle by the user includes delivery of an encrypted media by the web server to a user, the DRM-protected media encrypted and containing the puzzle that is viewable by a human when the DRM-protected media is opened and played by the user client with CDM, but is inaccessible by one or more bots on the system.

7. The system of claim 6, where the puzzle is a puzzle image converted into a video clip of the encrypted media that is encrypted using DRM.

8. The system of claim 7, where the video clip is at least one of a single frame and a container containing the puzzle.

9. The system of claim 8, where the puzzle is a voice puzzle and video clip further includes audio.

10. The system of claim 9, where the one or more bots on the system are one or more automated programs.

11. The system of claim 5, where reaction time by the user to an interactive task is determined by a time-sensitive puzzle, with the reaction time to the interactive task determined by one or more of difficulty in solving the time-sensitive puzzle, a length of the DRM-protected media, and a determined time limit.

12. The system of claim 11, where the time-sensitive puzzle is DRM-protected media.

13. The system of claim 11, where the time-sensitive puzzle blocks spammers.Docket: GMU-25-02714. The system of claim 11, where the time-sensitive puzzle is operable to be solved within a time limit that is solvable by a human but not solvable by one or more bots on the system.

15. The system of claim 14, where the user triggers initiation of a timer that tracks the time limit.

16. The system of claim 14, where a response by the user to solve the time-sensitive puzzle includes one or more of the user selecting, sliding or moving elements within the timesensitive puzzle to solve the time-sensitive puzzle.

17. The system of claim 14, where the time limit is determined in view of a human time limit to solve the time-sensitive puzzle and a bot time limit to solve the time-sensitive puzzle.

18. The system of claim 1, where the system further includes a verification server operable to communicate with the web server, at least one of the web server and the CAPTCHA server operable to determine the status of the user by performing analysis based at least in part on physical solution characteristics of the user in solving the puzzle, with one or more of the web server and the verification server blocking sending of the requested media content to the user when the user is determined to be a non-permissible bot user.

19. The system of claim 18, where one or more of requesting the media content, solution activity of the puzzle, and transmission of a solution of the puzzle by the user are physical solution characteristics of the user and responsive to verification that the user that requested the media content did not also solve the puzzle provided by the verification server and submit a solution of the puzzle to the web server, said solution also provided to the verification server, the web server and the verification server in cooperative arrangement determine thatDocket: GMU-25-027 the user is a non-permissible bot that is not a single entity and do not provide the requested media content to the user.

20. The system of claim 18, where one or more of requesting the media content, solution activity of the puzzle, and transmission of a solution of the puzzle by the user are physical solution characteristics of the user and responsive to a determination that the user that requested the media content also solved the puzzle provided to the user by the verification server and submitted a solution of the puzzle to the web server, said solution also provided to the verification server, the web server and the verification server in cooperative arrangement determine that the user is a single entity that is a permissible human user and provide the requested media content to the single entity user.

21. The system of claim 18, where one or more of a solution-submission action and a token-submission action performed by the user are physical solution characteristics of the user and where the web server and the verification server in cooperative arrangement verify whether the solution-submission action and the token-submission action are both performed by the user and the user is the single entity user.

22. The system of claim 21, where said solution-submission action and said tokensubmission action are performed by the single entity user within request / response cycles between the user and the verification server.

23. The system of claim 21, where said verification of performance of the solutionsubmission action by the user includes determination that the user that requested the media content and responsively received the puzzle from the verification server solved the puzzle and submitted the solution to the web server and the verification server.Docket: GMU-25-02724. The system of claim 23, said verification of the solution-submission action by the user further includes the web server limiting the user to a single license request by the user for the puzzle.

25. The system of claim 24, further where the web server deletes an encryption key of the puzzle once a key ID of the puzzle has been requested.

26. The system of claim 23, said verification of the token-submission action by the user includes determination by one or more of the web server and the verification server that a token obtained by the user from the verification server in response to submission of the solution is submitted to the web server by the user.

27. The system of claim 21, where said verification of the token-submission action by the client includes determination by one or more of the web server and the verification server that a token obtained by the user from the verification server in response to submission of the solution is submitted to the web server by the user.

28. The system of claim 27, where said verification of the token-submission action by the single entity further includes verification that sequential requests sent by the user to the web server and an entitlement server in cooperative arrangement with the web server arrive at approximately the same time and where submission of the token to the web server triggers a subsequent license request to the entitlement server.

29. The system of claim 28, where said verification further includes verification that a token request sent by the user client on behalf of the user to the web server and the subsequent license request sent by the content decryption module (CDM) of the browser to the entitlement server arrive at the web server at approximately the same time, the entitlement server integrated with the web server.Docket: GMU-25-02730. The system of claim 29, where the user client is a web browser.

31. The system of claim 28, further including the entitlement server, where the entitlement server extracts a device ID of the subsequent license request and compares the extracted device ID of the subsequent license request with a device ID of a previous license request, with each device ID unique to a device and not accessible or modifiable by the user, where matching of the extracted device ID of the subsequent license request and the device ID of the previous license request verifies that the subsequent license request and the previous license request were sent by the same device and the user of the user device is a single entity.

32. The system of claim 31, where the user client is a web browser.

33. The system of claim 28, where one or more of the web server and verification server prompt the user to attempt playing the puzzle causes and trigger the subsequent license request to the entitlement server.

34. The system of claim 27, where said verification of the token-submission action by the single entity further includes verification that sequential requests sent by the user to the web server and an entitlement server in cooperative arrangement with the web server are from the same port and where submission of the token to the web server triggers a subsequent license request to the entitlement server.

35. The system of claim 34, further including the entitlement server, where the entitlement server and the web server have a same IP address and where the entitlement server communicates with the CDM of the user device on behalf of a license server.Docket: GMU-25-02736. The system of claim 34, where one or more of the web server and verification server prompt the user to attempt playing the puzzle causes and trigger the subsequent license request to the entitlement server.

37. The system of claim 27, further where the user received the token directly from the verification server.Docket: GMU-25-02738. A method of ensuring delivery of media content to users, comprising: responsive to a request for media content initiated by a user client and received by a web server from the user client, delivering to the user client in communication with a user a digital rights management (DRM)-protected media containing a puzzle that is solvable by a human; playing the puzzle by a content decryption module (CDM) of the user client, said puzzle viewable by a human when the DRM-protected media is played; determining the status of the user as a permissible single entity user or a non-permissible user based upon analyzing at least physical solution characteristics of the user associated with solution activity of the puzzle; and performing one or more of: providing the requested media content to the user client when the status of the user is a permissible single entity user that is a permissible human user, and not providing the requested media content to the user client when the status of the user is a non-permissible user.

39. The method of claim 38, where analyzing at least physical solution characteristics of the user includes one or more of determining perception of the puzzle and determining reaction time to an interactive task, the perception of the puzzle and the reaction time by the user are physical solution characteristics of the user associated with solution activity by the user of the puzzle.

40. The method of claim 39, where determining perception of the puzzle includes delivering an encrypted media to a user client that can be decrypted and played only when the user client has the CDM, the encrypted media having a human-solvable puzzle.Docket: GMU-25-02741. The method of claim 40, including delivering the human-solvable puzzle to the user client via a DRM-protected video.

42. The method of claim 41, further comprising generating the DRM-protected video including converting a puzzle image into a single frame video clip and encrypting the single frame video clip using DRM.

43. The method of claim 41, where the DRM-protected video is encrypted and the CDM module is of a browser operable to decrypt and play the DRM-protected video.

44. The method of claim 41, where the human-solvable puzzle is one or more of a puzzle image carried within the DRM-protected video and a voice puzzle with the DRM-protected video further including audio.

45. The method of claim 39, where determining reaction time to an interactive task is determined by one or more of difficulty in solving a time-sensitive puzzle, a DRM-protected media, and a determined time limit.

46. The method of claim 45, where the time-sensitive puzzle blocks spammers.

47. The method of claim 45, where the time-sensitive puzzle is operable to be solved by a human within a time limit that is solvable by a human but not solvable by one or more bots.

48. The method of claim 47, where the user triggers initiation of a timer that tracks the time limit.

49. The method of claim 47, where a response by the client to solve the time-sensitive puzzle includes one or more of the user typing, selecting, sliding, rotating, or moving elements within the time-sensitive puzzle to solve the time-sensitive puzzle.Docket: GMU-25-02750. The method of claim 47, where the time limit is determined in view of a human time limit to solve the time-sensitive puzzle and a hot time limit to solve the time-sensitive puzzle.

51. The method of claim 38, where one or more of requesting the media content, solution activity of the puzzle, and transmission of a solution of the puzzle by the user are physical solution characteristics of the user and responsive to verification that the user that requested the media content did not also solve the puzzle and submit a solution of the puzzle to the web server, the web server and the verification server in cooperative arrangement determining that the user is a non-permissible bot that is not a single entity user and not providing the requested media content to the user52. The method of claim 38, where one or more of requesting the media content, solution activity of the puzzle, and transmission of a solution of the puzzle by the user are physical solution characteristics of the user and responsive to a verification that a user that requested the media content also solved the puzzle provided and submitted a solution of the puzzle, the web server and the verification server in cooperative arrangement determining that the user is a single entity user that is a permissible human user and providing the requested media content to the single entity user.

53. The method of claim 38, where one or more of a solution-submission action and a token-submission action performed by the user are physical solution characteristics of the user and further comprising verifying whether a solution-submission action and a tokensubmission action are performed by the user and the user is the single entity user.

54. The method of claim 53, where said verifying the solution-submission action and the token-submission action are performed by the single entity user within request / response cycles between the single entity and a verification server.Docket: GMU-25-02755. The method of claim 53, said verifying the solution-submission action by the single entity user includes determining that the user requested the DRM-protected puzzle from the verification server, solved the DRM-protected puzzle and submitted the solution to one or more of the verification server and the web server.

56. The method of claim 55, said verifying the solution-submission action by the single entity user further includes limiting the license to request the DRM-protected puzzle to a single request by the user.

57. The method of claim 56, further comprising deleting an encryption key of the DRM- protected puzzle once a key ID of the DRM-protected puzzle has been requested.

58. The method of claim 55, said verifying the token-submission action by the single entity user includes determining that a token obtained by the user from the verification server in response to submission of the solution is submitted to the web server by the user.

59. The method of claim 53, said verifying the token-submission action by the single entity user includes determining that a token obtained by the user from the verification server in response to submission of the solution is submitted to a web server by the user.

60. The method of claim 59, said verifying the token-submission action by the single entity user further includes verifying that sequential requests sent by the user to the web server and an entitlement server arrive at approximately the same time and when the user submits the token to the web server triggering a subsequent license request to the entitlement server.

61. The method of claim 60, further including verifying that a token request sent by a user client to the web server and the subsequent license request sent by a content decryptionDocket: GMU-25-027 module (CDM) of the user client to the entitlement server arrive at the web server at approximately the same time, the entitlement server integrated with the web server.

62. The method of claim 60, further comprising the entitlement server extracting a device ID of the subsequent license request and comparing the extracted device ID of the subsequent license request with a device ID of a previous license request, each device ID unique to each device and not accessible or modifiable by the user, where matching of the extracted device ID and the device ID of a previous license request verified that the subsequent license request and the previous license request were sent by the same device.

63. The method of claim 60, where prompting the user to attempt playing the DRM- protected puzzle causes said triggering the subsequent license request to the entitlement server.

64. The method of claim 59, said verifying the token-submission action by the single entity further includes verification that sequential requests sent by the user to the web server and an entitlement server in cooperative arrangement with the web server are from the same port and where submission of the token to the web server triggers a subsequent license request to the entitlement server.

65. The method of claim 64, further where the entitlement server and the web server share an IP address and where the entitlement server communicates with the CDM of the user client on behalf of a license server.

66. The method of claim 64, where one or more of the web server and the verification server prompt the user to attempt playing the puzzle causes and trigger the subsequent license request to the entitlement server.Docket: GMU-25-02767. The method of claim 59, determining that the user received the token directly from the verification server.

Images