DCT

1:22-cv-00585

Nobots LLC v. Google LLC

Key Events
Amended Complaint
complaint Intelligence

I. Executive Summary and Procedural Information

  • Parties & Counsel:
  • Case Identification: 1:22-cv-00585, W.D. Tex., 03/05/2026
  • Venue Allegations: Plaintiff alleges venue is proper in the Western District of Texas because Google maintains multiple regular and established places of business in the District and has committed acts of infringement there, including offering its accused services to customers located in the District.
  • Core Dispute: Plaintiff alleges that Defendant’s reCAPTCHA and Ad Traffic Quality systems infringe two patents related to methods for distinguishing human users from automated bots by analyzing user interaction data.
  • Technical Context: The technology addresses the field of website and application security, specifically the challenge of blocking malicious automated programs ("bots") without creating excessive friction for legitimate human users.
  • Key Procedural History: Prior to this First Amended Complaint, the Patent Trial and Appeal Board (PTAB) addressed an inter partes review of the '008 Patent. The PTAB issued a conclusion correcting a "conspicuous error" in the language of asserted Claim 18, a construction which the Plaintiff has adopted in this complaint.

Case Timeline

Date Event
2007-11-19 Priority Date for '008 and '014 Patents
2014-12 Google launches reCAPTCHA v2
2017-03-14 U.S. Patent No. 9,595,008 Issues
2017-03 Google launches reCAPTCHA v2 Invisible
2018-10-29 Google launches reCAPTCHA v3
2022-12-15 Patent Application for '014 Patent Published
2023-11-07 U.S. Patent No. 11,810,014 Issues
2023-11-29 PTAB issues conclusion in IPR for '008 Patent
2026-03-05 First Amended Complaint Filed

II. Technology and Patent(s)-in-Suit Analysis

U.S. Patent No. 9,595,008 - “Systems, Methods, Apparatus for Evaluating Status of Computing Device User” (Issued Mar. 14, 2017)

The Invention Explained

  • Problem Addressed: The patent describes prior art "CAPTCHA" tests, such as those requiring users to decipher distorted text, as burdensome for human users and increasingly ineffective against sophisticated bots (Compl. ¶¶33-36). These methods created friction for legitimate users while failing to provide robust security (Compl. ¶36).
  • The Patented Solution: The invention shifts the analysis from an explicit user-side challenge to a server-side assessment (Compl. ¶37). It proposes monitoring data generated by a user's interaction with a website (e.g., mouse movements, keystroke timing) and comparing this "monitored data" against "model data" indicative of typical human behavior to generate a probability or confidence score that the user is human (Compl. ¶38; ’008 Patent, abstract). This process can occur in the background without requiring the user to complete a test, thereby reducing user friction (Compl. ¶38).
  • Technical Importance: This approach represented a move away from explicit challenge-response tests toward passive, behavior-based analysis for bot detection, aiming to improve both security and user experience (Compl. ¶¶39-40).

Key Claims at a Glance

  • The complaint asserts dependent Claim 18, which incorporates independent Claim 1 (Compl. ¶¶58, 60).
  • The essential elements of independent Claim 1 are:
    • A single user of a client computing device requesting data from a server.
    • The server presenting issued data to the client computing device.
    • Monitoring at least some data generated by the user at the client in response to the issued data.
    • Comparing the monitored data to model data relating to human interaction.
    • Generating a value representing a confidence level that the monitored data is a result of human interaction.
  • The complaint notes that the PTAB construed Claim 18 to further require repeating steps (b)-(d) of Claim 1 and comparing the first generated value to the second generated value (Compl. ¶61).

U.S. Patent No. 11,810,014 - “Systems, Methods and Apparatus for Evaluating Status of Computing Device User” (Issued Nov. 7, 2023)

The Invention Explained

  • Problem Addressed: The '014 Patent addresses the same general problem as the '008 Patent: the need for effective, low-friction methods to differentiate human users from bots on websites (Compl. ¶¶26-28).
  • The Patented Solution: The invention describes a non-transitory machine-readable medium with instructions for a two-stage analysis process. First, the system collects and receives "active data" (e.g., user interactions) and "passive data" (e.g., browser information) from a client computer (Compl. ¶115, steps a-b). It performs a "first analysis" by comparing this data with "model data based on human interactions from a prior session with the same website" to generate a first value (Compl. ¶115, step c). If this value meets a predetermined threshold, access is granted. If not, the system provides a CAPTCHA test to the user and performs a "second analysis" on the response to determine access (Compl. ¶115, steps d-i).
  • Technical Importance: This patent claims a system that formalizes an adaptive security model, where a seamless, background check is performed first, and a more explicit challenge is deployed only when the initial assessment indicates a heightened risk (Compl. ¶119).

Key Claims at a Glance

  • The complaint asserts independent Claim 1 and independent Claim 16 (Compl. ¶¶112, 129).
  • The essential elements of independent Claim 1 (a non-transitory machine-readable medium claim) are:
    • Provide data collection data to a client computer to collect active data.
    • Receive the collected active data and passive data from the client.
    • Perform a first analysis of the received data in conjunction with model data from a prior session on the same website.
    • Generate a first analysis value.
    • Allow access if the value meets a first predetermined criteria.
    • If the value fails, provide a CAPTCHA test, receive a response, perform a second analysis, and grant access if a second value meets a second criteria.
  • The complaint does not explicitly reserve the right to assert dependent claims.

III. The Accused Instrumentality

Product Identification

The complaint identifies two primary categories of accused instrumentalities:

  1. Google reCAPTCHA: Including reCAPTCHA v2 (Checkbox and Invisible), reCAPTCHA v3, and reCAPTCHA Enterprise (Compl. ¶56).
  2. Google Ad Traffic Quality: A collection of software-based systems and methods used to detect and filter bot activity related to online advertisements (Compl. ¶¶46, 52).

Functionality and Market Context

  • The reCAPTCHA products are described as security tools that websites and applications integrate to protect against spam and abuse by distinguishing between human and bot users (Compl. ¶62). The complaint alleges these tools work by collecting user interaction data through "event listeners" (e.g., mouse movements, keystrokes) and sending it to Google's servers for risk analysis, which generates a score indicating the likelihood the user is human (Compl. ¶¶67, 70, 75). Figure 9 of the complaint illustrates the initial data request flow between a user's browser, a website server, and Google's server (Compl. ¶63).
  • The Ad Traffic Quality system is alleged to be a bot-detection and filtration system designed to protect Google-managed advertisements from invalid traffic, such as automated clicks from bots (Compl. ¶¶46, 89). This system allegedly analyzes user data in conjunction with model data to identify non-human traffic, thereby ensuring advertisers are not billed for fraudulent clicks (Compl. ¶¶47-48, 95). The complaint alleges this system is foundational to Google's advertising business (Compl. ¶53).

IV. Analysis of Infringement Allegations

'008 Patent Infringement Allegations

Claim Element (from Independent Claim 1) Alleged Infringing Functionality Complaint Citation Patent Citation
a) a single user of a client computing devices requesting data from a server A user's browser makes a request to a website server, which in turn instructs the browser to request the reCAPTCHA JavaScript from Google's server. ¶63 col. 7:50-52
b) the server presenting data issued by the server to the client computing device Google's server responds to the request by sending JavaScript files (e.g., api.js, recaptcha_en.js) to the user's browser. ¶65; ¶66 col. 8:36-44
c) monitoring at least some data generated by the user at the client computing device in response to the issued data The executed JavaScript code adds "event listeners" to the browser to monitor and track user actions like keyboard, mouse, touch, and scroll events. ¶67 col. 8:12-19
d) comparing the monitored data to model data relating to human interaction with or in response to the issued data Data from the event listeners is sent to Google, which applies the data to an algorithm that compares it to model data of human interactions to determine if the user is human or a bot. ¶70; ¶73 col. 7:26-31
e) generating a value that represents a confidence level that the monitored data is a result of human interaction... Google's "risk analysis engine" outputs a score (e.g., between 0.0 and 1.0) representing the confidence that the user is human. ¶75 col. 7:29-32
  • Identified Points of Contention:
    • Scope Questions: A central issue for Claim 18 may be whether the accused systems perform the required "repeating...and comparing the first instance of the value...to the second instance" as construed by the PTAB. The complaint alleges that when a user is deemed suspicious, reCAPTCHA "repeats the analysis" (Compl. ¶78), but the nature and mechanism of this repetition and comparison will be a focal point.
    • Technical Questions: The complaint provides a screenshot from a developer tool showing "mousemove" events being logged (Compl. ¶68, Fig. 15). A key question will be what specific data from these events is transmitted to Google and how it is technically "compared" to "model data" in a way that maps to the patent's claims.

'014 Patent Infringement Allegations

Claim Element (from Independent Claim 1) Alleged Infringing Functionality Complaint Citation Patent Citation
a) provide data collection data that causes the client computer to collect active data relating to interactions... Google's servers provide JavaScript to the client's browser, which enables the collection of interaction data. ¶117 col. 12:4-7
b) receive at least some of the collected active data...and at least some passive data from the client computer Google receives both active data (e.g., mouse movements) and passive data (e.g., cookies, IP address) from the user's browser. ¶117 col. 12:8-12
c) perform a first analysis comprising analyzing...data in conjunction with model data based on human interactions from a prior session with the same website Google's system calculates a "risk score" using machine learning models that are allegedly trained on data from prior user sessions on the same website to establish context. ¶118 col. 12:13-18
d) generate a first analysis value based on the first analysis, wherein the client computer is allowed to access the protected page...if the first analysis value meets a first analysis predetermined criteria The system generates a score, and if it exceeds a set threshold (e.g., 0.5), the user is deemed human and allowed to proceed without an explicit challenge. ¶76; ¶119 col. 12:19-25
f) provide a CAPTCHA test to the client computer based on the determination that the first analysis value fails to meet the first analysis predetermined criteria If the score is below the threshold, indicating a suspected bot, Google's system presents the user with an additional challenge, such as an image selection test. ¶73; ¶119 col. 12:28-32
  • Identified Points of Contention:
    • Scope Questions: The definition of "model data based on human interactions from a prior session with the same website" will be critical. The dispute may center on whether this requires user-specific historical data or if it can be read to cover aggregate, anonymized interaction data from all previous visitors to a site, as Google's public statements seem to suggest (Compl. ¶74, Fig. 20).
    • Technical Questions: The complaint presents a high-level flowchart of how the reCAPTCHA system works (Compl. ¶117, Fig. 39). An evidentiary question will be whether this high-level model accurately reflects the specific, multi-step conditional logic required by Claim 1 (i.e., generate value -> test against criteria -> if fail, provide CAPTCHA -> analyze response -> grant access).

V. Key Claim Terms for Construction

For the '008 Patent:

  • The Term: "model data relating to human interaction" (Claim 1)
  • Context and Importance: This term is the baseline against which a user's behavior is judged. Its scope determines what kind of comparison is required for infringement. Practitioners may focus on this term because the complaint's theory relies on Google using broad behavioral patterns, while Google might argue for a narrower definition tied to specific biometric data disclosed in the patent.
  • Intrinsic Evidence for Interpretation:
    • Evidence for a Broader Interpretation: The specification defines "model data" broadly as "data indicative of human interaction with a computing environment," which could encompass a wide range of behaviors (US 10,423,885 B2, col. 7:60-62).
    • Evidence for a Narrower Interpretation: The detailed description provides specific examples of model data, such as "pointing device vector movements and/or cadence, key stroke combinations and/or cadence," which could be used to argue the term is limited to such fine-grained biometric inputs (US 10,423,885 B2, col. 8:2-6).

For the '014 Patent:

  • The Term: "a prior session with the same website" (Claim 1)
  • Context and Importance: This term defines the source of the "model data." Its construction is key to determining whether Google's alleged use of aggregate traffic data meets the claim limitation. If "a prior session" is construed to mean a prior session by the same user, it could pose a challenge to the infringement allegation.
  • Intrinsic Evidence for Interpretation:
    • Evidence for a Broader Interpretation: The patent does not explicitly state that the "prior session" must be from the same user. The language "a prior session" could be interpreted to mean any single prior session by any user, or an aggregation of them, to establish a behavioral baseline for the website.
    • Evidence for a Narrower Interpretation: The specification discusses comparing a user's current activity to past activity, which could imply a focus on an individual's own behavioral patterns over time. For example, the specification for the parent patent discusses comparing input data to "previously recorded activity for a given input page that was knowingly created by humans" (US 9,595,008 B1, col. 6:27-30).

VI. Other Allegations

  • Indirect Infringement: The complaint alleges Google induces infringement by providing marketing materials, developer guides, and technical instructions that encourage and teach third-party website operators to implement the accused reCAPTCHA and Ad Traffic Quality methods (Compl. ¶¶85-87; Compl. ¶105-106; Compl. ¶125-127). It also alleges contributory infringement, stating the accused methods are not staple articles of commerce and are especially designed to infringe (Compl. ¶88; Compl. ¶109). A screenshot of Google's developer guide is provided as evidence of inducement (Compl. ¶87, Fig. 25).
  • Willful Infringement: The complaint alleges willful infringement based on Google having actual knowledge of the patents and the infringement allegations no later than the filing of the complaint, and its continued infringement thereafter (Compl. ¶82; Compl. ¶147).

VII. Analyst’s Conclusion: Key Questions for the Case

  1. A central issue will be one of definitional scope: Can the claim term "model data based on human interactions from a prior session with the same website" ('014 Patent) be construed to cover the use of aggregate, anonymized traffic data from all previous visitors, as the complaint appears to allege, or does it require data from a prior session of the specific user being analyzed?
  2. A key evidentiary question will be one of operational proof: Beyond marketing statements and high-level diagrams, what technical evidence demonstrates that Google's complex, black-box systems—particularly the Ad Traffic Quality system—actually perform the specific, sequential steps of monitoring, comparing, value-generating, and iterative re-evaluation as recited in the asserted claims?
  3. The dispute over the '008 Patent will likely focus on functional performance: Does the alleged "repeating" of analysis in the accused reCAPTCHA system constitute the specific method of "comparing the first instance of the value...to the second instance" as required by the PTAB's construction of Claim 18, or is there a functional difference between Google's risk-scoring iteration and the patent's claimed comparative method?
Loading Amended Complaint