US 11810014

Here's a concise summary of US patent 11810014:

US Patent 11810014

• Title: Systems, methods and apparatus for evaluating status of computing device user
• Assignee: Nobots LLC
• Inventor: Timothy P. Heikell
• Filing Date: August 5, 2022 (Application number US17/882,082)
• Issue Date: November 7, 2023
• Abstract: The patent describes methods, systems, and apparatus, such as a non-transitory machine-readable medium, for determining whether a human or an automated computer program ("bot") is operating a client computer interacting with a server. This involves receiving active data (interactions with a website) and passive data (from the client computer), analyzing this data in conjunction with model data based on prior human interactions with the same website to generate a first analysis value. If this first analysis value does not meet predetermined criteria, a request for further data (e.g., a CAPTCHA test) is provided to the client computer.

Plain-Language Overview of Independent Claims:

• Independent Claim 1: This claim covers a non-transitory machine-readable medium (e.g., software) that helps determine if a human or a bot is using a computer to access a protected webpage. It works by:

  1. Collecting "active data" (user interactions like mouse movements, keystrokes) and "passive data" (like browser cookies, IP address) from the client computer.
  2. Performing a first analysis by comparing this collected data with "model data" which represents how humans typically interact with that website.
  3. Generating a "first analysis value" based on this comparison.
  4. If this first value indicates a high likelihood of human operation (meets predetermined criteria), the user is granted access to the protected page without needing to complete a CAPTCHA test.
  5. However, if the first value suggests it might be a bot (fails the criteria), the system provides a CAPTCHA test to the user.
  6. After the user responds to the CAPTCHA, a "second analysis" is performed to check the accuracy of that response.
  7. Finally, a "second analysis value" is generated, and access is granted if this second value meets its own predetermined criteria.

• Independent Claim 16: This claim also covers a non-transitory machine-readable medium that determines if a human or a bot is interacting with a server. Its operations include:

  1. Providing data collection instructions to gather active and passive data from the client computer (active data relates to interactions with the server's website).
  2. Receiving this active and passive data.
  3. Analyzing this data, in conjunction with model data based on prior human interactions with the same website, to generate a "first analysis value."
  4. If this first analysis value indicates a potential bot (fails to meet a predetermined criteria), the system then requests further data from the client computer.

• Independent Claim 22: This claim also pertains to a non-transitory machine-readable medium for judging human or bot interaction with a server. It details a multi-level analysis approach:

  1. Providing instructions that enable remote monitoring of client computer interactions with the server's website.
  2. Receiving this monitored data, which includes both active and passive data from the client.
  3. Analyzing this monitored data in two levels to detect human or bot activity:
     • First Level Analysis: Initially checking the monitored data for any general indication of human operation.
     • Second Level Analysis: If the first level analysis doesn't meet its predetermined criteria (suggesting it might be a bot), a more in-depth second level analysis is performed. This involves comparing the monitored data with previously recorded human interaction data from the same website.
  4. Providing a "second-level analysis value" if this second-level analysis meets its predetermined criteria (indicating human activity).

CAFC 2026 Dockets:
As of April 26, 2026, a search of CAFC 2026 dockets for US patent 11810014 did not yield any specific litigation directly referencing this patent number. General CAFC activity and case summaries for 2026 were found, but none explicitly mentioned US11810014.

As of April 26, 2026, there is known litigation involving US Patent 11810014. The litigation is detailed below.

Case Name: Nobots LLC v. Google LLC

• Plaintiff(s): Nobots LLC
• Defendant(s): Google LLC
• Jurisdiction: [U.S. District Court for the Western District of Texas, Austin Division](/courts/western-district-of-texas-austin). There was also an appeal to the U.S. Court of Appeals for the Federal Circuit.
• Case Number: 1:2022cv00585 (District Court)
• Filing Date: December 13, 2021 (District Court complaint filed)
• Outcome/Current Status:
  • Nobots LLC initially sued Google LLC for infringement of U.S. Patent Nos. 9,595,008 and 10,423,885.
  • Google successfully petitioned the Patent Trial and Appeal Board (PTAB) to institute an inter partes review (IPR) of all twenty claims of the '008 patent. The PTAB found most claims unpatentable, but upheld claims 18 and 19.
  • Google appealed the PTAB's upholding of claim 19 to the Federal Circuit.
  • On November 20, 2025, the Federal Circuit reversed the PTAB's decision regarding claim 19, finding the Board's claim construction of "acquiring interest data" to be erroneous, and thus, claim 19 was found unpatentable.
  • The district court case was stayed pending the resolution of the PTAB proceedings. On March 4, 2024, the court denied Nobots LLC's motion to lift the stay.

It is important to note that while US11810014B2 is the patent in question, the litigation records predominantly refer to its parent patent, US Patent No. 9,595,008 (the "'008 patent"), and US Patent No. 10,423,885 (the "'885 patent"). US11810014B2 is a continuation of these earlier applications, sharing the same priority date. The core of the litigation appears to revolve around the inventiveness of detecting bots using "active" and "passive" data, which is central to the family of patents.

Proceedings overview

There is currently one AIA trial proceeding on file for US patent 11810014, which is active and pending institution. This indicates an early stage of challenge against the patent.

IPR2026-00429 — Google LLC v. Nobots LLC

• Type: Inter Partes Review
• Filed: 2026-07-29
• Status: Pending (The petition has been filed and is awaiting a decision on institution by the PTAB.)
• Judge panel: The judge panel for this proceeding has not yet been publicly assigned.
• Petition grounds: The petition grounds, including specific claims challenged, prior art references, and statutory bases (§ 102 / § 103 / § 112), are not yet publicly available as the proceeding is in its initial stages.
• Institution decision: A decision on institution has not yet been issued. The PTAB typically has six months from the filing date of the petition to decide whether to institute an Inter Partes Review. Therefore, an institution decision is anticipated around January 29, 2027.
• Final Written Decision: A Final Written Decision has not been issued, as the proceeding has not yet reached the institution phase.
• Settlement / termination: No settlement or termination has been recorded for this early-stage proceeding.
• Appeal: No appeal has occurred, as no Final Written Decision has been issued.
• Defensive value: This proceeding is in its very early stages. Until an institution decision is made, the full scope of Google's challenge and its potential impact on the patent's claims remains unknown. Currently, it signals a pending challenge, but no claims have been invalidated or sustained through this IPR process yet.

Strategic summary

As of today, July 30, 2026, all claims of US patent 11810014 are UNTESTED in the context of a PTAB Final Written Decision. The sole proceeding, IPR2026-00429, was filed very recently and is currently pending institution. This means there are no canceled or sustained claims yet stemming from AIA trial proceedings directly on this specific patent.

Regarding the estoppel landscape, since IPR2026-00429 has not yet been instituted or reached a Final Written Decision, no estoppel under § 315(e)(2) has been established. If the IPR is instituted and proceeds to a Final Written Decision, Google LLC (as the petitioner) and its privies would be estopped from asserting invalidity grounds that were raised or reasonably could have been raised in the IPR against any claims determined to be patentable. However, until then, all prior art grounds remain available for potential future challenges by non-parties or by Google for claims not addressed or not yet subject to estoppel.

The fact that Google LLC, a party involved in prior litigation concerning parent patents (US 9,595,008 and US 10,423,885), has filed this IPR on US11810014 indicates a continued defensive strategy against Nobots LLC's patent family. This suggests Google is systematically challenging the validity of these related patents.

Recommended next steps

The IPR2026-00429 proceeding is in its preliminary phase. The key upcoming milestone is the institution decision, which is anticipated around January 29, 2027. Monitoring this decision is critical, as it will determine which (if any) claims proceed to trial. If the IPR is instituted, further milestones will include the Patent Owner Response, Petitioner Reply, potential oral hearing, and the Final Written Decision, which is typically due within one year of institution. The official details and status can be tracked on the USPTO PTAB E2E system.

Inventors

• Timothy P. Heikell (Employer at time of filing: Nobots LLC, based on current assignee information).

Original assignee

The original assignee on the issued patent is Nobots LLC. Based on the litigation summary, Nobots LLC appears to be a licensing entity, asserting patents rather than shipping products embodying the claims. Its primary line of business appears to be patent assertion. Its current status is operating, as it is actively involved in litigation and PTAB proceedings.

Assignment timeline

• 2022-12-29 (executed) / recorded 2022-12-29 — Reel 062251/0438
  • Conveyance: ASSIGNMENT OF ASSIGNORS INTEREST
  • Assignor: HEIKELL, TIMOTHY P.
  • Assignee: NOBOTS LLC
  • Correspondent: NOT LISTED.
  • Context: Inventor assigned interest to Nobots LLC, the named assignee on the patent.

Timeline diagram

timeline
    title Ownership of US 11810014
    2007 : Priority Date (Nov 19)
    2022 : Application filed by Nobots LLC (Aug 5)
         : Inventor assigns to Nobots LLC (Dec 29)
    2023 : Patent granted to Nobots LLC (Nov 7)
    2026 : IPR filed by Google (Jul 29)

NPE / troll-pattern signals

1. Shell-entity transfer — Not present. The patent was assigned directly from the inventor to Nobots LLC, which is the entity currently asserting the patent. There's no recorded transfer from an operating company to a shell entity.
2. Known asserter in the chain — Present. Nobots LLC is the current assignee and has been actively involved in litigation against Google LLC, as detailed in the litigation summary. While not explicitly listed on RPX or Unified Patents in the provided text, its litigation activity strongly indicates an assertion-focused entity.
3. Repeat correspondent across the chain — Unclear. The assignment record for reel 062251/0438 does not list a correspondent.
4. Cascading transfers — Not present. Only one assignment from the inventor to Nobots LLC is recorded.
5. Pre-litigation transfer — Unclear. The patent was granted on November 7, 2023, and the IPR was filed on July 29, 2026. The initial litigation involving parent patents was filed in December 2021. The assignment to Nobots LLC from the inventor was recorded on December 29, 2022, after the parent patent litigation began, but before this specific patent was granted. However, since the current patent is a continuation of the earlier ones involved in litigation, the transfer to Nobots LLC could be considered pre-assertion for the overall patent family.
6. Bankruptcy fire-sale — Not present. No evidence of bankruptcy proceedings.
7. Privateering — Not present. No information suggests an operating company transferred the patent to Nobots LLC to assert against competitors on its behalf.
8. Defensive aggregator (anti-NPE) — Not present. The patent is currently held by Nobots LLC, an asserting entity, not a defensive aggregator.

Verdict

NPE — high confidence

The confidence is high due to Nobots LLC being the current assignee, its active role as a plaintiff in litigation against Google LLC involving related patents, and the direct assignment from the inventor to this asserting entity. This pattern is consistent with that of a Non-Practicing Entity.

See the USPTO Assignment Center search page for verification: https://assignmentcenter.uspto.gov/

I'll research the specific patent and its cited prior art. Let me start with verification searches.

Let me research the remaining key cited references.

Prior-Art Analysis: US 11,810,014 B2

A. Target patent — verification

Confirmed against the Google Patents record at https://patents.google.com/patent/US11810014/en (retrieved 2026‑09‑22) and cross‑checked against the CAFC/PTAB appellate record in Google LLC v. Nobots LLC, No. 24‑1432 (Fed. Cir. Nov. 20, 2025) (https://cases.justia.com/federal/appellate-courts/cafc/24-1432/24-1432-2025-11-20.pdf).

⚠️ Identifier discipline note: I have interpreted "11810014" literally and report only results for that number. Note that much of the publicly available litigation/PTAB material concerns the family parents — US 9,595,008 (the "’008 patent"), US 10,423,885 (the "’885 patent"), and US 11,775,853. Those are not 11,810,014 and must not be conflated; I flag where conclusions about the ’008 do not automatically transfer.

---

B. Two methodological caveats before the reference-by-reference analysis

Caveat 1 — The citation list is not homogeneous to this patent. US 11,810,014 is a continuation (16/578,823 ← 15/457,099 ← 12/313,502 ← 61/003,743). The Google Patents record for the ’014 patent displays its reference list in two different places with two different totals: "Citations (94)" in the upper table and "Patent Citations (107)" lower down, plus "Non-Patent Citations (135)." Because Form 892 citations from the parents' prosecutions and from the IPRs carried forward into the family record, the list is best treated as a family-wide prior-art landscape rather than a clean list of art applied against the ’014 claims specifically. I cannot, without the ’014 file wrapper, certify which of these 94 references the examiner actually applied against the ’014 claims. The record does show the ’014 prosecution produced a non-final action ("NON FINAL ACTION MAILED," 2022‑10‑26 legal event; cited as "Office Action for U.S. Appl. No. 17/882,082, mailed on Oct. 28, 2022, Heikell," 12 pages), and the patent issued roughly a year later. Anyone needing the examiner-applied art must pull the ’014 file wrapper from USPTO Patent Center; I am stating this explicitly rather than fabricating which references drove allowance.

Caveat 2 — The claim set is narrower than the parents. The ’014 independent claims (1, 16, 22) each require, in substance:

• active data (interactions with the site) and passive data (cookies, IP),
• analysis against model data based on human interactions from a prior session with the same website, and
• a tiered/conditional escalation — CAPTCHA (claim 1) or a "request for further data" (claim 16) or a second-level analysis against prior-session human data (claim 22).

That combination is what matters for § 102. Several of the most famous references below (e.g., Kitts) were decisive against the parents but do not reach the ’014 independent claims on their own.

---

C. Tier 1 — Closest prior art (single-reference § 102 candidates and their limits)

1. US 2008/0114624 A1 — "Click-fraud protector" (Kitts; Microsoft)

• Full citation: Kitts, Brendan James. US 2008/0114624 A1. Pub. 2008‑05‑15; App. 11/559,291 filed 2006‑11‑13; assignee Microsoft Corp.
• Description: A data-mining component derives attributes of a web-page request; a computation component feeds those attributes into a statistical model to compute the probability the request was fraudulently initiated (a "quality score"). Attributes expressly include the user's IP address and residence (i.e., passive data).
• § 102 relevance — the single strongest documented anticipation in this family: In Google LLC v. Nobots LLC, the Board held Kitts discloses obtaining exclusively passive data; the CAFC held that the ’008 patent's "interest data" is defined to include passive data alone, and therefore reversed and held ’008 claim 19 unpatentable over Kitts. (https://ipwatchdog.com/2025/11/20/win-google-cafc-reverses-ptab-decision-upholding-bot-detector-patent-claim/)
• Against the ’014 claims: Kitts is a strong § 102/§ 103 reference for the passive-data-discrimination concept underlying claims 16 and 22, and for the "provide a value indicating whether a bot is interacting with a server" framing of claim 16. It is not a standalone anticipatory reference for claim 1, 16, or 22 as issued, because the record shows Kitts obtains only passive data — it does not disclose the claimed collection of active data (mouse/keyboard) or the CAPTCHA escalation step. Expect Kitts to appear as the primary reference in the pending IPR2026‑00429 against the ’014 patent.

2. US 2007/0239604 A1 — "User-browser interaction-based fraud detection system" (O'Connell I; IBM)

• Full citation: O'Connell, Brian M. & Walker, Keith R. US 2007/0239604 A1. Pub. 2007‑10‑11; App. 11/279,202 filed 2006‑04‑10; assignee IBM. Granted as US 8,650,080 B2 (2014‑02‑11).
• Description: Detects fraudulent e-commerce behavior by capturing user-browser interaction data — "the speed of selecting keys, the method the user utilizes to move between fields … how quickly the pointer is moving or if it is moving at all, whether the browser window loses and regains focus" — and comparing it to known fraudulent human or automated-program behavior, then performing an action such as "requesting additional authentication" or "denying the requested action."
• § 102 relevance: This is the closest single reference to the "first analysis … analyzing … active data … in conjunction with model data … [and] provide a request for further data" concept of ’014 claims 16 and 22. It is cited by the examiner in the family. However it does not disclose (a) collection of passive data (cookies/IP) as claimed in claim 1/11/18/28, (b) model data specifically based on a prior session with the same website, or (c) a CAPTCHA as the "further data." → Strong § 103 reference; not a complete § 102 anticipation of the independent claims.

3. US 2007/0240230 A1 — "User-browser interaction analysis authentication system" (O'Connell II; IBM)

• Full citation: O'Connell & Walker. US 2007/0240230 A1. Pub. 2007‑10‑11 (companion filing to O'Connell I); assignee IBM.
• Description: Computes a "pattern matching score" comparing the user's current browser interaction against a pre-established user-browser interaction profile for that user, and performs a verification action based on the score. The IBM press coverage confirms profiles were built "in roughly 15 minutes in one session or over several sessions," and that falling below a "pre-configured threshold" triggers a security question or other authentication. (https://www.csoonline.com/article/[545218](/patent/545218)/)
• § 102 relevance: Directly supports the "model data based on human interactions from a prior session" limitation of claim 1 and the "previously recorded data relating to human interactions from a prior session with the same website" limitation of claim 22, and the "request for further data / additional authentication" step. Best used in § 103 combination with a data-collection reference (Jacobson, Kroll) and a CAPTCHA reference (Behforooz/Google).

4. US 7,945,952 B1 — "Methods and apparatuses for presenting challenges to tell humans and computers apart" (Behforooz; Google)

• Full citation: Behforooz, Reza. US 7,945,952 B1. Filed 2005‑06‑30; granted 2011‑05‑17; assignee Google Inc.
• Description: Detects "a condition indicating abuses of a communication channel," then provides a human-in-the-loop challenge (text/speech, non-image), receives a response, and determines whether the response is correct — blocking privileges on failure.
• § 102 relevance: Discloses the "provide a CAPTCHA test … receive a response … perform a second analysis comprising assessing accuracy of the response" limitations of ’014 claim 1 (and claims 2, 21, 27). It is a textbook § 102 anticipation of the CAPTCHA-escalation sub-steps, but obviously does not disclose the active/passive-data first analysis. In the prior "Obviousness" section it was already paired with O'Connell I — correct positioning.

5. US 2009/0113294 A1 — "Progressive captcha" (Yahoo)

• Full citation: US 2009/0113294 A1. Priority 2007‑10‑30; pub. 2009‑04‑30; assignee Yahoo! Inc.
• Description: Presents CAPTCHA challenges that escalate in difficulty/succession based on user responses.
• § 102 relevance: Relevant to ’014 claim 2 ("provide an additional CAPTCHA test … third analysis … third analysis value") and to the tiered structure of claim 1. A strong § 102/§ 103 reference for the iteration limitation, but not for the behavioral first analysis.

6. US 2009/0094311 A1 / US 8,280,993 B2 — "System and Method for Detecting Internet Bots" (Yahoo)

• Full citation: US 2009/0094311 A1, priority 2007‑10‑04, pub. 2009‑04‑09; granted as US 8,280,993 B2 (2012‑10‑02); assignee Yahoo! Inc.
• Description: Passively collects request/session attributes and classifies traffic as bot vs. human (server-side detection using navigational/request data).
• § 102 relevance: Pertinent background for passive data + probability classification (claims 11, 18, 28). Likely § 103, not standalone § 102, against the independent claims.

7. US 2008/0263636 A1 / US 8,056,129 B2 — "Method and system for validating active computer terminal sessions" (IBM)

• Full citation: US 2008/0263636 A1, priority 2007‑04‑19, pub. 2008‑10‑23; granted US 8,056,129 B2 (2011‑11‑08); assignee IBM.
• Description: Monitors an active terminal session and validates the session against expected conditions (human vs. automated activity).
• § 102 relevance: Background for the "provide instructions that allow client computer interactions … to be remotely monitored" preamble of claim 22. Generally a § 103 reference; used in the prior Obviousness section as the claim-22 primary reference.

8. US 2005/0114705 A1 — "Method and system for discriminating a human action from a computerized action" (Reshef)

• Full citation: Reshef, Eran et al. US 2005/0114705 A1. Pub. 2005‑05‑26; App. 10/790,611 filed 2004‑03‑01; priority to prov. 60/069,202 filed 1997‑12‑11. (Note the 1997 priority — very early art.)
• Description: Challenge–response "human ability challenge" system (distorted visual, auditory, cognitive) used during authentication, to limit automated agents, and to confirm actions; the component compares the returned response against the correct response and can run on a proxy server separate from the application server.
• § 102 relevance: Foundational CAPTCHA/challenge-response art (§ 102 anticipation of plain CAPTCHA-provision steps), cited by the examiner. Not anticipatory of the behavioral-analysis claims.

9. US 2005/0008148 A1 — "Mouse performance identification" (Jacobson)

• Full citation: Jacobson, Dov. US 2005/0008148 A1. Pub. 2005‑01‑13; priority 2003‑04‑02.
• Description: Uses mouse movement characteristics (speed, path, number of clicks) as a biometric to identify a user.
• § 102 relevance: Discloses the "active data" / pointing-device vector movements and cadence element that the ’014 specification defines as active model data (claims 1, 9, 12, 13, 29, 30). Combine with O'Connell for § 103.

10. US 6,405,922 B1 — "Keyboard signature security system" (Kroll Family Trust)

• Full citation: US 6,405,922 B1. Priority 1997‑10‑02; granted 2002‑06‑18.
• Description: Keystroke-dynamics ("keyboard signature") authentication — typing cadence as a behavioral biometric.
• § 102 relevance: Discloses "key stroke combinations and/or cadence" (active data) for claims 9, 15, 30. Foundational, pre-dating the priority date by a decade.

11. US 7,516,220 B1 — "Method and system for detecting and deterring robot access of web-based interfaces by using minimum expected human response time" (IBM)

• Full citation: US 7,516,220 B1. Priority 2008‑05‑15; granted 2009‑04‑07; assignee IBM.
• Description: Detects/deters bots using minimum expected human response time as a discriminator.
• ⚠️ Date flag: Its priority date (2008‑05‑15) is after the ’014 priority date (2007‑11‑19). It therefore cannot be § 102 prior art against US 11,810,014 and appears in the list because it was cited during the later family prosecutions. Do not use it as anticipatory art. (Same caution applies to several 2008‑2009‑priority references in the list.)

12. US 2009/0150986 A1 — "User Authorization Using An Automated Turing Test" (IBM)

• Full citation: US 2009/0150986 A1. Priority 2007‑12‑05; pub. 2009‑06‑11; assignee IBM.
• ⚠️ Date flag: Priority 2007‑12‑05 is 16 days after the ’014 priority date (2007‑11‑19). Under AIA § 102(a)(2) it can only be relied on if it qualifies as a § 102(a)(2) "effectively filed" reference — it does not, because it postdates the priority date. Not anticipatory art for the ’014 patent. It is in the list only because it was cited downstream.

---

D. Tier 2 — References matching specific limitations (chiefly § 103 material)

(References whose priority dates fall in 2008–2015 — e.g., US 7,516,220; US 2009/0150986; US 2011/0029902; US 2011/0113388; US 2011/0021197; US 2015/0112892; US 8,413,250; US 8,510,795; US 8,893,395 as a grant — are either post-priority or have pre-priority priority dates but post-priority publications. Each must be individually assessed: a pre‑2007‑11‑19 priority date with a pre‑2007‑11‑19 publication qualifies under § 102(a)/(b); a later-filed application does not qualify as § 102(a)(2) art against 11,810,014 at all because 11,810,014's effective filing date is 2007‑11‑19.)

---

E. Tier 3 — Remaining cited references (background / general art)

Presented compactly, as they are not § 102 anticipatory for the ’014 independent claims:

Foundational access/authentication: US 5,375,244 A (AT&T, 1992/1994 grant, granting access to a resource); US 5,933,498 A (MRJ, 1996/1999, controlling access to digital property); US 6,195,698 B1 (Compaq, 1998/2001, selectively restricting access); US 6,460,141 B1 (RSA, 1998/2002, security and access management); US 7,506,170 B2 (Microsoft, 2004/2009, secure access to multiple networks); US 7,606,915 B1 (Microsoft, prevention of unauthorized scripts).

Fraud/abuse analytics: US 2006/0015390 A1 (Rijsinghani); US 2006/0136294 A1 (Linden, click fraud); US 2008/0147456 A1 (Broder); US 2008/0162200 A1 (O'Sullivan); US 2008/0288303 A1 (Claria); US 2008/021... US 8,682,718 B2 (Gere Dev., click fraud detection); US 2007/0255821 A1 (Ge); US 2005/0144067 A1 (PARC, unexpected behaviour in targeted advertising); US 7,089,241 B1 (AOL, classifier tuning); US 9,158,381 B2 / US 9,208,461 B2 (Psyleron/Busa — unrelated, random-signal & service allocation; cite only for completeness).

CAPTCHA / Turing-test art: US 2007/0201745 A1 (Penn State, image-based CAPTCHA generation); US 2008/0049969 A1 (Koziol, symbol identification challenge); US 2008/0066014 A1 (Misra, image-based Turing test); US 2007/0192849 A1 & US 7,721,107 B2 (PARC, physical token for human presence); US 7,785,180 B1 / US 7,980,953 B2 (CMU, object recognition & labelling via games); US 8,032,483 B1 (Google, using game responses to gather data); US 8,214,891 B2 (IBM, multi-touch gestures for CAPTCHA); US 8,793,135 B2 (AT&T, auditory CAPTCHAs); US 2010/0037147 A1 (IBM, human identification proof in virtual environments).

Behaviour/gesture/biometrics: US 2007/0165911 A1 (IBM, biometric authentication); US 2007/0300077 A1 (Mani, biometric verification of secondary authentications); US 2009/0320123 A1 (Motorola, motion passwords); US 2008/049... US 2008/006614? see above; US 2009/0055193 A1 (Pudding Holdings, spoken-content access) — note the citation entry in the record shows an inconsistent title ("Combination of somatostatin-analogs…" at US 2009/0197815 A1), which appears to be an OCR/record error.

Unrelated/administrative entries in the list (flag as noise): US 8,694,244 / US 8,700,259 / US 8,694,244-class Agero/SiriusXM off-board navigation patents; US 8,775,235 / US 8,775,236 (Accenture, electronic toll management); US 8,824,659 / US 8,908,652 (AT&T, speech-enabled call routing); US 8,903,052 (IBM, voice-print tagging of IVR); US 6,461,141-adjacent; JP 2007‑213409 A (Fujitsu login method); WO 2007/090605 A1 (Mediakey); US 2007/0106737 A1 (Barnes, delivery status notification); US 2008/0198158 A1 (Fabre) and US 2007/0192419 A1 (Siemens out-of-office). These appear to be family-prosecution artifacts (e.g., IBM-family cross-citations) rather than art relevant to bot detection. I am explicitly flagging them as low-relevance rather than inventing a bot-detection nexus for them.

---

F. Non-patent literature that matters most for § 102/§ 103

From the 135 NPL citations, the genuinely load-bearing items are:

• Von Ahn, Blum, Hopper, Langford, "CAPTCHA: Using Hard AI Problems for Security," LNCS 2656 (2003) — the canonical CAPTCHA reference.
• Von Ahn et al., "reCAPTCHA: Human-Based Character Recognition via Web Security Measures," Science 321 (2008) — note 2008 publication, post-priority; the TechCrunch piece dated 2007‑09‑16 is the pre-priority date anchor.
• Baird & Lopresti, Human Interactive Proofs workshops (HIP 2005); Lopresti, "Leveraging the CAPTCHA Problem" (2005); Coates et al. "Pessimal Print" (2003); Chew & Baird, "Image Recognition CAPTCHAs" (2004); Rusu & Govindaraju visual CAPTCHA (2005); Athanasopoulos et al. animated CAPTCHA (2006).
• Gamboa & Fred, "A behavioral biometric system based on human-computer interaction," Proc. SPIE 5404 (2004‑08‑25) — directly on point for pointer/keyboard behavioural model data.
• Andersen et al., "Using alert levels to enhance keystroke dynamic authentication" (dated 2007‑11‑19) — same date as the ’014 priority; treat with date caution.
• Pal, Webber & Schunter, "Trust Assessment from Observed Behavior" (IEEE NCA'06) — behavioural trust scoring.
• Park et al., "Securing Web Service by Automatic Robot Detection," USENIX ATC (2006); Tan & Kumar, "Discovery of Web Robot Sessions Based on their Navigational Patterns" (2004); Yampolskiy & Govindaraju, "Embedded Noninteractive Continuous Bot Detection," ACM CIE (2008).
• Tanzer / Kitts / O'Connell / Willner / O'Sullivan / Ge / Meek / Awadallah / Farahat / Krynski / Gusler claim charts — these are Google's NPE-litigation exhibits (see below), i.e., asserted invalidity positions, not neutral art.

---

G. § 102 conclusions — what actually anticipates, and what does not

1. No single cited reference anticipates independent claim 1, 16, or 22 of US 11,810,014. The claimed combination — collecting active + passive data, comparing against model data from a prior session with the same website, and conditionally escalating to a CAPTCHA / further-data request — is not found complete in any one reference in the 94-item list.

2. Strongest surviving § 102 analysis centers on Kitts (US 2008/0114624 A1). The Federal Circuit has already held (construing the ’008 patent's identical "interest data" definition) that "acquiring interest data" reads on wholly passive data, reversing the PTAB and holding ’008 claim 19 unpatentable over Kitts. Because the ’014 patent shares that specification and definition, the same construction should control, which materially strengthens a Kitts-based attack on the passive-data limitations of ’014 claims 16/18/22/28. It does not reach claim 1's active-data and CAPTCHA limitations.

3. The CAPTCHA limitations (claims 1, 2, 21, 27) are strongly pre-empted in isolation by Behforooz (US 7,945,952 B1), Reshef (US 2005/0114705 A1), Yahoo's progressive CAPTCHA (US 2009/0113294 A1), and US 7,685,891 B1 — but only as sub-combinations.

4. The behavioural model/data-collection limitations (claims 9, 12, 13, 15, 29, 30) are strongly pre-empted in isolation by Jacobson (US 2005/0008148 A1), Kroll (US 6,405,922 B1), O'Connell I/II, Willner (US 8,938,395), and Gamboa (NPL).

5. Practical § 103 combinations (consistent with the prior "Obviousness" section, which I have verified rather than replaced): O'Connell I + Jacobson + Behforooz for claim 1; IBM US 2008/0263636 + O'Connell I + Kroll/Greene for claim 22; Kitts + O'Connell I + Behforooz as the combination most likely to be run in IPR2026‑00429.

6. Date-screen the list before use. At least the following cannot be § 102 prior art against US 11,810,014 because they postdate 2007‑11‑19 in priority: US 7,516,220 B1 (2008‑05‑15), US 2009/0150986 A1 (2007‑12‑05), US 2011/0029902 A1, US 2011/0113388 A1, US 2011/0021197 A1, US 2015/0112892 A1, and all the post‑2012 items.

---

H. Litigation/PTAB art that telegraphs the coming attack

For a live validity defence, the actual asserted references matter more than the Form 892 list. Google's preliminary invalidity contentions in Nobots LLC v. Google LLC, No. 6:21‑cv‑1290‑ADA (W.D. Tex.), chart the following against the family: Willner, Ge, O'Sullivan I, O'Connell I, Krynski, Farahat, Awadallah I, Kitts I, Meek, Tanzer, Gusler I, Eldon I, plus obviousness combinations and § 101 contentions. The Board's Final Written Decision in IPR2022‑00940 (2023‑11‑29) held all ’008 claims unpatentable except 18 and 19, and the CAFC reversed as to claim 19. Expect the ’014 IPR to be built on the same Kitts/O'Connell backbone with an added CAPTCHA reference (likely Behforooz) to bridge the escalation limitation that the ’008 did not require.

---

I. Data-integrity flags and contradictions with the previously generated sections

1. Citation-count inconsistency in the source record. The Google Patents page for US 11,810,014 displays "Citations (94)" and, elsewhere, "Patent Citations (107)," plus "Non-Patent Citations (135)." I have analyzed the 94-item list as the "Citations" set and noted the discrepancy rather than silently reconciling it.

2. ⚠️ Contradiction with the previously generated Litigation and PTAB sections (date). Those sections are written as of 30 July 2026 and reference IPR2026‑00429 (filed 2026‑07‑29). The present task fixes the current date at 26 April 2026. An IPR filed on 2026‑07‑29 cannot exist as of 2026‑04‑26. One of the two date premises is wrong. I flag this explicitly rather than repeating the later-dated content as current fact.

3. Contradiction in case number/venue. The prior Litigation summary states the district case is 1:2022cv00585 (Austin Division), filed 2021‑12‑13. The Federal Circuit opinion and the ’008 IPR record instead reference No. 6:21‑cv‑1290‑ADA (W.D. Tex., Waco Division) and state Nobots sued Google in April 2022. The IPR number is IPR2022‑00940, FWD 2023‑11‑29, CAFC No. 24‑1432, decided 2025‑11‑20 — all confirmed. The "1:2022cv00585" figure is not corroborated by any source I retrieved and should be treated as unverified.

4. The prior "Patent summary" states that a CAFC 2026 docket search "did not yield any specific litigation directly referencing this patent number." That is consistent with what I found: the appellate activity is captioned to the ’008 patent, not to 11,810,014.

5. Reference-identity caveats I will not paper over: (a) The record attributes US 2005/0066201 A1 to inventor "Goodman Joshua T."; the title corresponds to the well-known CMU order-based HIP work, so the inventor attribution in the citation table appears anomalous and should be verified against the document itself. (b) US 2007/0239604 A1 is listed with priority 2006‑04‑10 by Google Patents and the PTAB exhibit, but a third-party database (Unified Patents) lists 2006‑04‑09; a one-day discrepancy that does not affect any § 102 conclusion. (c) Several citation rows contain visibly corrupted titles from OCR (e.g., the "somatostatin-analogs" entry) — these are record artifacts, not substantive art.

6. What I cannot confirm: I did not retrieve the ’014 file wrapper, so I cannot state which references the examiner actually applied against US 11,810,014's claims, nor the applicant's arguments that secured allowance in late 2023. Any statement that a given reference was "the" anticipating art for the ’014 claims would be speculation, and I have avoided it. Likewise, specific PTA days for the ’014 patent are not available in the material I retrieved.

Bottom line: The ’014 patent's 94-reference list is a family-wide landscape. Its closest single-reference art is Kitts (US 2008/0114624 A1) — proven anticipatory against a parent claim on the passive-data point by the Federal Circuit — but no cited reference anticipates independent claims 1, 16, or 22, which require the active+passive+prior-session-model+CAPTCHA-escalation combination. The patent's greatest exposure is a § 103 challenge of the O'Connell/Jacobson/Behforooz type, and secondarily a § 102 challenge to the passive-data claims built on Kitts under the now-binding "interest data" construction.

The analysis of obviousness under 35 U.S.C. § 103 for US Patent 11810014 requires identifying combinations of prior art references that would render the claimed invention obvious to a Person Having Ordinary Skill in the Art (POSA) by the patent's priority date of November 19, 2007. A POSA in this field would typically have a background in computer science, network security, and web development, with knowledge of bot detection, user interface design, and data analysis.

The core inventive concept of US11810014 involves a multi-layered, transparent bot detection system that uses a combination of active (behavioral) and passive (environmental) data, compared against human model data, and potentially escalating to a CAPTCHA if initial analyses are inconclusive, thereby minimizing the user burden.

Here are two combinations of prior art that would likely render the claims of US11810014 obvious:

Combination 1: O'Connell I (US20070239604A1) in view of Jacobson (US20050008148A1) and Google (US7945952B1)

This combination addresses the key elements of independent claim 1.

• Primary Reference: US20070239604A1 (O'Connell I)

  • Priority Date: April 10, 2006.
  • Disclosure: This patent application describes a "User-browser interaction-based fraud detection system." It teaches detecting fraud by analyzing user interactions with a web browser and developing an analysis value based on this to indicate legitimate or fraudulent (i.e., bot) activity. This reference provides the fundamental concept of using user-browser interactions for bot detection.

• Secondary Reference 1: US20050008148A1 (Jacobson)

  • Priority Date: April 2, 2003.
  • Disclosure: Jacobson teaches "Mouse performance identification," explicitly detailing the use of mouse movements (e.g., speed, path, number of clicks) as a biometric for user identification. This clearly falls within the "active data" as described in US11810014's specification.

• Secondary Reference 2: US7945952B1 (Google Inc.)

  • Priority Date: June 30, 2005.
  • Disclosure: This patent describes "Methods and apparatuses for presenting challenges to tell humans and computers apart," commonly known as CAPTCHAs. It teaches providing a CAPTCHA test and assessing the response to determine if the user is human.

Motivation for Combination and Obviousness Analysis for Claim 1 (Representative Claim):

A POSA in web security, aiming to improve the accuracy and user experience of bot detection systems, would be motivated to combine these references. O'Connell I provides a system for detecting fraud based on user-browser interactions. To enhance this system's robustness, a POSA would naturally seek to incorporate more specific and reliable forms of user interaction data. Jacobson teaches that mouse movements are a valuable biometric for user identification, providing a clear method for collecting "active data" (e.g., pointing device vector movements and/or cadence) for analysis.

Furthermore, recognizing that purely behavioral analysis might not be foolproof, and aiming to minimize intrusive challenges for legitimate users, a POSA would be motivated to implement a tiered verification approach. Google's patent on CAPTCHAs offers a well-known and effective method for definitively distinguishing humans from bots when initial, more transparent analyses are inconclusive.

Therefore, combining these references would lead to an obvious system that:

1. Collects "active data" (e.g., mouse movements from Jacobson, as part of O'Connell I's user-browser interactions) and common "passive data" (e.g., browser cookies, IP addresses, which are typically available in web interactions as encompassed by O'Connell I).
2. Analyzes this data against human interaction models (as implied by O'Connell I's comparison of user behavior profiles to fraudulent ones).
3. Generates an initial analysis value, allowing access without a CAPTCHA if the human likelihood is high (a desirable user experience goal, evident from US11810014's background).
4. If the initial analysis is inconclusive (fails predetermined criteria), escalates to providing a CAPTCHA test (from Google's teachings) and performs a second analysis on the CAPTCHA response for final access determination. This tiered approach optimizes both security and user experience.

Combination 2: IBM (US20080263636A1) in view of O'Connell I (US20070239604A1) and various data collection techniques (e.g., US20050008148A1, US6405922B1, US20070038568A1)

This combination addresses the multi-level analysis aspects of independent claim 22.

• Primary Reference: US20080263636A1 (IBM)

  • Priority Date: April 19, 2007.
  • Disclosure: This application describes a "Method and system for validating active computer terminal sessions." It focuses on monitoring and collecting various data during an active session to "validate" the legitimacy of the session, which implicitly involves distinguishing human from automated activity.

• Secondary Reference 1: US20070239604A1 (O'Connell I)

  • Priority Date: April 10, 2006.
  • Disclosure: As above, teaches "user-browser interaction-based fraud detection."

• Secondary Reference 2 (Illustrative Data Collection):

  • US20050008148A1 (Jacobson): Mouse performance identification.
  • US6405922B1 (Kroll Family Trust): Keyboard signature security system.
  • US20070038568A1 (Greene): Fraud analyst smart cookie (for passive data).

Motivation for Combination and Obviousness Analysis for Claim 22 (Representative Claim):

A POSA seeking to enhance IBM's system for validating active computer sessions to more effectively identify human users and filter out bots would be motivated to integrate the detailed interaction analysis techniques taught by O'Connell I and specific data collection methods.

1. Monitoring and Receiving Data: IBM's patent provides the overarching goal of "validating active computer terminal sessions" through monitoring. O'Connell I details how to perform "user-browser interaction-based fraud detection," providing specific examples of interactions to monitor. Combining these would obviously lead to a system that collects comprehensive "monitored data comprising active data relating to interactions of the client computer with the website and passive data of the client computer." The specific types of "active data" (e.g., mouse movements from Jacobson, keyboard activity from Kroll Family Trust) and "passive data" (e.g., browser cookies from Greene, originating IP address) were well-known to be useful indicators for user authentication and fraud detection in the art prior to US11810014's priority date.

2. Multi-Level Analysis: Claim 22 specifies a "first level of analyzing" for any human indication and a "second level of analyzing" (comparing monitored data with human interaction data from prior sessions) if the first level is insufficient. IBM's concept of "validating" a session implies a decision-making process based on criteria. A POSA would find it obvious to implement a multi-tiered analysis approach to improve the efficiency and accuracy of such validation. A quick "first level" assessment for basic human activity (e.g., any mouse or keyboard input) followed by a more robust "second level" comparison against established human behavior models (as taught by the concept of behavioral profiles in O'Connell I) is a standard design choice in security systems to balance performance with thoroughness. This tiered approach allows for rapid identification of obvious bots while providing a deeper analysis for more sophisticated threats.

In conclusion, the combinations of prior art discussed above, particularly US20070239604A1, US20050008148A1, US7945952B1, and US20080263636A1, demonstrate that the methods and systems for evaluating user status, including the collection and analysis of active and passive data, comparison with human models, and a tiered approach escalating to CAPTCHAs, would have been obvious to a POSA by the priority date of US Patent 11810014. The motivation for such combinations would stem from the continuous desire in the art to create more effective, efficient, and user-friendly bot detection and web security systems.

To provide a comprehensive overview of US patent 11810014, including patent term adjustments (PTA), patent term extensions (PTE), continuation/divisional applications, related family members, and projected expiration date, I will use the information provided in the patent text and supplement with general knowledge about patent term calculations.

Patent Term Adjustments (PTA)

Patent Term Adjustment (PTA) can extend the term of a U.S. patent to compensate for certain administrative delays by the USPTO during prosecution (35 U.S.C. § 154(b)). These delays fall into categories such as failure to issue an office action within 14 months, failure to respond to an applicant's reply within 4 months, or failure to issue a patent within 36 months from the filing date. The USPTO calculates PTA, and the determination is typically provided by the issue date of the patent.

To determine the specific PTA for US patent 11810014, one would typically need to consult the patent's file wrapper on the USPTO Patent Center. Without direct access to the file wrapper or a specific PTA calculation stated on the patent document, the exact PTA for this patent cannot be provided at this time.

Patent Term Extensions (PTE)

Patent Term Extensions (PTE) are distinct from PTA and are generally granted for patents covering pharmaceutical products, medical devices, food additives, or color additives to compensate for delays incurred during regulatory review by agencies like the FDA (35 U.S.C. § 156). The extension period is based on the time lost during clinical testing and regulatory approval, with a maximum extension of five years, and the total patent term (including extension) cannot exceed 14 years following agency approval.

Given the nature of US patent 11810014, titled "Systems, methods and apparatus for evaluating status of computing device user," which relates to bot detection and user authentication in computing environments, it is highly unlikely to be eligible for a Patent Term Extension (PTE) as it does not appear to cover a product requiring FDA or similar regulatory approval.

Continuation Applications and Divisional Applications

US patent 11810014 explicitly states in its description that it is a continuation application: "This application is a continuation application of and claims priority to application Ser. No. 16/578,823 filed Sep. 23, 2019, which is a divisional application of application Ser. No. 15/457,099 filed Mar. 13, 2017 and issued as U.S. Pat. No. 10,423,885 on Sep. 24, 2019, which claims priority to application Ser. No. 12/313,502 filed Nov. 19, 2008 and issued as U.S. Pat. No. 9,595,008 on Mar. 14, 2017, which claims priority to provisional application Ser. No. 61/003,743 filed Nov. 19, 2007, all of which are incorporated herein by reference."

• Continuation Applications: A continuation application allows an applicant to pursue additional claims to an invention disclosed in an earlier, still-pending "parent" application, using the same specification and claiming priority to the parent's filing date.

  • US11810014B2 is a continuation of application Ser. No. 16/578,823.

• Divisional Applications: A divisional application is filed when a patent application claims more than one distinct invention, often in response to a USPTO restriction requirement. It is based on the same disclosure as the parent but claims a different invention, retaining the parent's filing date.

  • Application Ser. No. 16/578,823 (the direct parent of US11810014B2) is a divisional application of Ser. No. 15/457,099.

Related Family Members

Based on the patent's own declaration, the family members include:

• Provisional Application: Ser. No. 61/003,743 filed Nov. 19, 2007
• Parent Applications (in chronological order of filing):
  • Ser. No. 12/313,502 filed Nov. 19, 2008 (Issued as U.S. Pat. No. 9,595,008 on Mar. 14, 2017)
  • Ser. No. 15/457,099 filed Mar. 13, 2017 (Issued as U.S. Pat. No. 10,423,885 on Sep. 24, 2019)
  • Ser. No. 16/578,823 filed Sep. 23, 2019 (Issued as U.S. Pat. No. 11,775,853 on Oct. 3, 2023)
  • US17/882,082 (this patent, US11810014B2), filed Aug. 5, 2022.

The patent family also includes other related applications that claim priority from the same chain, as listed in the "Family Applications" section of the patent:

• US12/313,502 (US9595008B1)
• US15/457,099 (US10423885B2)
• US16/578,823 (US11775853B2)
• US17/874,137 (US11836647B2) filed 2022-07-26
• US17/882,082 (US11810014B2) filed 2022-08-05
• US18/488,298 (US20240119324A1) filed 2023-10-17

Projected Expiration Date

The term of a U.S. utility patent generally expires 20 years from the filing date of the earliest non-provisional application to which it claims priority. Provisional application filing dates do not count towards the 20-year term. The earliest priority date for US11810014B2, as stated in the patent document, is November 19, 2007 (from provisional application Ser. No. 61/003,743). However, the 20-year term starts from the filing date of the earliest non-provisional application.

The earliest non-provisional application in this chain is Ser. No. 12/313,502, filed November 19, 2008. Therefore, the base expiration date would be 20 years from November 19, 2008.

Base Expiration Date: November 19, 2008 + 20 years = November 19, 2028.

As noted in the "Info" section of the patent, the "Anticipated expiration" is listed as 2028-11-19. This aligns with the calculation based on the earliest non-provisional filing date. This date would be adjusted by any Patent Term Adjustments (PTA), but as noted above, specific PTA information is not available in the provided text. Given the nature of the invention, Patent Term Extensions (PTE) are not expected.

Defensive Disclosure Document for US Patent 11810014

This document outlines derivative variations and extensions of the core inventive concepts disclosed in US Patent 11810014, titled "Systems, methods and apparatus for evaluating status of computing device user." The purpose of this defensive disclosure is to establish prior art for potential future incremental improvements by competitors, rendering such improvements obvious or non-novel. The derivations are structured around independent Claims 1, 16, and 22, covering various technical axes.

---

Derivations based on Independent Claim 1

Claim 1 Summary: A non-transitory machine readable medium for generating a value indicating a likelihood of human/bot operation, by collecting active and passive data, performing a first analysis with model data, granting access if criteria met, otherwise providing a CAPTCHA, receiving response, performing a second analysis, and granting access if second criteria met.

---

1.1. Material & Component Substitution: Hardware-Accelerated Biometric Signal Processing

Enabling Description:
This derivative utilizes a specialized Hardware Security Module (HSM) or Trusted Platform Module (TPM) integrated within the client computing device to collect and pre-process active biometric data. Instead of JavaScript in a browser, a low-level firmware agent or a kernel-mode driver within the operating system (OS) captures raw input device signals (e.g., mouse sensor data, keyboard matrix scans, touchscreen capacitance changes) at a high sampling rate (e.g., 10 KHz). This raw data is then cryptographically signed and timestamped by the HSM/TPM before being transmitted to the server. The model data for human interactions would incorporate these low-level hardware-derived biometric signatures, enabling detection of subtle anomalies indicative of synthetic input, beyond what typical software-only monitoring can achieve. Passive data (e.g., device serial numbers, hardware configuration hashes) is also collected and signed by the HSM/TPM.

flowchart TD
    A[Client Computer with HSM/TPM] --> B{Firmware/Kernel Agent};
    B --> C[Raw Input Data (Mouse, Keyboard, Touch)];
    C --> D[HSM/TPM];
    D -- Cryptographic Signature & Timestamp --> E[Pre-processed Active Data];
    F[OS/Browser] --> G[Passive Data (Device Config, Software Env)];
    G --> D;
    D -- Cryptographic Signature & Timestamp --> H[Pre-processed Passive Data];
    E & H --> I[Encrypted Transmission to Server];
    I --> J[Server-Side Analysis Module];
    J -- Compare with Model Data --> K{First Analysis Value};
    K -- Meets Criteria --> L[Grant Access];
    K -- Fails Criteria --> M[Provide Hardware-Enabled CAPTCHA];
    M --> N[Client Response (HSM-signed)];
    N --> J;
    J -- Second Analysis --> O{Second Analysis Value};
    O -- Meets Criteria --> L;
    O -- Fails Criteria --> P[Deny Access];

---

1.2. Operational Parameter Expansion: Ultra-Scale, Low-Latency Bot Detection for High-Frequency Trading

Enabling Description:
This derivative applies the bot detection system to a high-frequency trading (HFT) environment, where user interaction with a trading terminal must be verified in sub-millisecond timescales. Active data collection involves monitoring human trader input (e.g., order entry keystrokes, mouse clicks on bid/ask ladders, drag-and-drop order modifications) with a resolution of microseconds, collected directly from specialized low-latency input devices. Passive data includes network latency measurements, CPU/GPU utilization on the trading workstation, and specific OS kernel scheduling events. Model data comprises ultra-fine-grained human behavioral patterns (e.g., consistent reaction times to market events, specific sequences of key presses for complex order types, muscle memory-driven mouse trajectories). The "first analysis" is performed by an FPGA-accelerated inference engine co-located with the trading server, generating a probability value within tens of microseconds. If this value indicates bot activity (e.g., deterministic latency, perfectly synchronized multiple order entries), a "request for further data" (e.g., a dynamic, real-time haptic feedback challenge or a CAPTCHA integrated into the trading GUI) is issued immediately, and access to order submission is temporarily halted.

sequenceDiagram
    participant HT as Human Trader
    participant TW as Trading Workstation (Low-Latency I/O)
    participant FP as FPGA Inference Engine
    participant TS as Trading Server
    participant DB as Model Data DB

    HT->>TW: Input (Keystrokes, Mouse)
    TW-->>FP: Microsecond-res Active/Passive Data Stream
    FP->>DB: Query Model Data (Human HFT Patterns)
    DB-->>FP: Return Model Segments
    FP->>FP: First Analysis (μs latency)
    FP-->>TS: First Analysis Value
    alt First Analysis Value Meets Criteria
        TS->>HT: Grant Order Submission Access
    else First Analysis Value Fails Criteria
        TS->>TW: Issue Real-time Haptic/Visual CAPTCHA
        TW->>HT: Present CAPTCHA
        HT->>TW: CAPTCHA Response
        TW-->>FP: CAPTCHA Response Data
        FP->>FP: Second Analysis (μs latency)
        FP-->>TS: Second Analysis Value
        alt Second Analysis Value Meets Criteria
            TS->>HT: Grant Order Submission Access
        else
            TS->>HT: Deny Order Submission Access
        end
    end

---

1.3. Cross-Domain Application: Bot Detection for Remote Surgery Robotic Control

Enabling Description:
This derivative applies bot detection to the highly sensitive domain of remote surgery, where a human surgeon operates robotic instruments via a console. The system ensures that only the authorized human surgeon is controlling the robotic system and no unauthorized automated program has interfered. Active data comprises the surgeon's haptic feedback input (force, torque, movement vectors), eye-tracking patterns on surgical displays, and voice commands, collected by specialized sensors on the surgical console. Passive data includes the console's operating system integrity checks, network latency to the surgical robot, and environmental sensor data from the operating room (e.g., temperature, light levels, acoustic profiles). Model data is built from expert surgeons' verified haptic and ocular patterns during various surgical tasks. A "first analysis" continuously assesses the likelihood of a human surgeon. If the analysis value drops below a critical threshold (e.g., indicating unusually smooth or jerky movements, or non-human eye gaze patterns), the system issues a "request for further data" in the form of a real-time, adaptive kinesthetic CAPTCHA (e.g., requiring a specific fine-motor movement sequence only a human can perform), and temporarily locks high-risk robotic movements until verified.

graph TD
    A[Surgeon Console (Haptic, Eye-track, Voice Sensors)] --> B{Active Data Collection};
    C[OS Integrity, Network Latency, OR Sensors] --> D{Passive Data Collection};
    B & D --> E[Real-time Data Stream];
    E --> F[Remote Surgery Server];
    F --> G[Human Surgeon Model Database];
    F -- First Analysis --> H{Surgeon Likelihood Score};
    H -- Score >= Threshold --> I[Maintain Robotic Control];
    H -- Score < Threshold --> J[Issue Kinesthetic CAPTCHA];
    J --> A;
    A --> K[CAPTCHA Response (Haptic/Ocular)];
    K --> F;
    F -- Second Analysis --> L{CAPTCHA Verification Score};
    L -- Score >= Threshold --> I;
    L -- Score < Threshold --> M[Engage Safety Protocols / Alert];

---

1.4. Integration with Emerging Tech: AI-Driven Adaptive Bot Detection with Decentralized Identity Verification (DID)

Enabling Description:
This derivative integrates AI-driven optimization, real-time IoT sensor data, and blockchain-based Decentralized Identity (DID) for advanced bot detection. Active data collection is augmented by a network of IoT sensors (e.g., proximity, thermal, acoustic, gesture recognition via radar/LiDAR) around the user's workspace, continuously streaming environmental and subtle physiological data. This data, combined with traditional active (mouse, keyboard) and passive (device fingerprint, IP) data, feeds into a deep learning model (e.g., a Transformer network) for real-time human-bot classification. The model is continuously optimized through federated learning across a consortium of participating websites, adapting to new bot tactics without centralizing sensitive user behavior data. When a "first analysis value" is generated, if it indicates an ambiguous state, the system requests "further data." This further data involves a challenge leveraging the user's DID: the user is prompted to cryptographically sign a challenge nonce using their private key associated with a self-sovereign identity on a blockchain. The server verifies this signature against the public DID recorded on the blockchain, providing a strong, unforgeable proof of human identity (if linked to a verified human ID), thus circumventing traditional CAPTCHAs.

graph TD
    A[Client Computer] --> B{Active Data (Mouse, Keyboard, Screen Interaction)};
    C[IoT Sensors (Proximity, Thermal, Acoustic, Gesture)] --> D{Ambient Data Stream};
    E[Client OS/Browser] --> F{Passive Data (Device ID, IP, Env)};
    B & D & F --> G[Data Aggregation Layer];
    G --> H[Federated Learning Node / Deep Learning Model];
    H -- Real-time Inference --> I{First Analysis Value (Human/Bot Probability)};
    I -- Meets Criteria --> J[Grant Access];
    I -- Fails Criteria (Ambiguous) --> K[Request DID Signature Challenge];
    K --> L[User's Decentralized Identity Wallet];
    L -- Sign Challenge Nonce --> M[Cryptographic Signature];
    M --> H;
    H -- Verify Signature (against Blockchain DID) --> N{Second Analysis Value};
    N -- Meets Criteria --> J;
    N -- Fails Criteria --> O[Deny Access / Flag for Review];

---

1.5. The "Inverse" or Failure Mode: Privacy-Preserving Low-Fidelity Bot Detection

Enabling Description:
This derivative operates in a privacy-preserving or "limited-functionality" mode, where explicit user consent is paramount, or in environments with strict data collection regulations. Instead of collecting detailed active data (e.g., full mouse trajectories, keystroke timings), the system only collects aggregated or obfuscated "low-fidelity" active data. For instance, mouse movement is sampled only once every 5 seconds (position only, no velocity/acceleration), and keyboard input is limited to "keypress event detected" rather than specific keys or timings. Passive data is anonymized (e.g., IP addresses are truncated or hashed, generic browser fingerprints are used). The "first analysis" uses a simplified model trained on this sparse, anonymized data, yielding a coarse "human-like" or "bot-like" score. If this score is below a minimum threshold for "human-like" activity, access is not immediately denied but is instead routed to a "limited functionality" mode (e.g., read-only access, reduced interaction features). No CAPTCHA is presented initially. Only upon the user attempting to access critical features within the limited mode would a prompt for "further data" appear, explicitly requesting consent for higher-fidelity data collection or a simple CAPTCHA.

stateDiagram
    [*] --> InitialAccess;
    InitialAccess --> LowFidelityDataCollection;
    LowFidelityDataCollection --> PerformCoarseAnalysis;
    PerformCoarseAnalysis --> IfHumanLike: Human-like;
    PerformCoarseAnalysis --> IfBotLike: Bot-like;
    Human-like --> FullFunctionalityGranted;
    Bot-like --> LimitedFunctionalityMode;
    LimitedFunctionalityMode --> AttemptCriticalFeature;
    AttemptCriticalFeature --> RequestConsentOrCAPTCHA;
    RequestConsentOrCAPTCHA --> A[User Opts-in for Hi-Fi Data]: HighFidelityDataCollection;
    RequestConsentOrCAPTCHA --> B[User Completes CAPTCHA]: CAPTCHAVerification;
    A --> HighFidelityDataCollection;
    B --> CAPTCHAVerification;
    HighFidelityDataCollection --> FullFunctionalityGranted;
    CAPTCHAVerification --> FullFunctionalityGranted;
    FullFunctionalityGranted --> [*];
    LimitedFunctionalityMode --> [*];
    RequestConsentOrCAPTCHA --> C[User Declines]: LimitedFunctionalityMode;

---

Derivations based on Independent Claim 16

Claim 16 Summary: A non-transitory machine readable medium for providing a value indicating a judgment of human/bot operation, by providing data collection data, receiving active and passive data, analyzing data with model data to develop a first analysis value, determining if it fails criteria, and providing a request for further data.

---

2.1. Material & Component Substitution: Bio-Integrated Sensor Array for Active Data Collection

Enabling Description:
This derivative integrates a bio-integrated sensor array, potentially worn by the user (e.g., a smart ring, wristband, or embedded within a desk/chair), to collect highly specific active and passive data. Active data would include physiological responses such as galvanic skin response (GSR), heart rate variability (HRV), eye saccade velocity, and micro-tremors in hand movements, directly streamed to the client computer. This data is correlated with traditional input (keyboard/mouse) events. Passive data includes ambient biometric signatures (e.g., facial recognition via webcam, voiceprint analysis). Data collection is managed by a dedicated, energy-efficient microcontroller in the bio-integrated device, which can perform local cryptographic signing before transmission. The "request for further data" could involve a physiological challenge (e.g., requiring a specific emotional response detectable by GSR, or a controlled breathing pattern) rather than a visual/auditory CAPTCHA, to confirm human presence and attention.

classDiagram
    class User {
        +InputDeviceEvents
        +PhysiologicalResponses
    }
    class BioIntegratedSensorArray {
        +CollectGSR()
        +CollectHRV()
        +CollectSaccadeVelocity()
        +CollectMicroTremors()
        +CollectAmbientBiometrics()
        +CryptographicallySignData()
        +TransmitData()
    }
    class ClientComputer {
        +ReceiveActivePassiveData()
        +PackageDataForServer()
    }
    class Server {
        +ReceiveClientData()
        +AnalyzeData()
        +EvaluateModelData()
        +GenerateFirstAnalysisValue()
        +DetermineCriteriaFailure()
        +RequestFurtherData()
    }
    class PhysiologicalChallenge {
        +GenerateChallenge()
        +ReceiveResponse()
        +AssessResponse()
    }
    User --|> InputDeviceEvents
    User --|> PhysiologicalResponses
    BioIntegratedSensorArray --> ClientComputer: Transmit Signed Data
    ClientComputer --> Server: Transmit Packaged Data
    Server -- AnalyzeData --> PhysiologicalChallenge: Request/Receive Further Data

---

2.2. Operational Parameter Expansion: Hyper-Localized, Context-Aware Challenge Generation

Enabling Description:
This derivative focuses on ultra-fine-grained contextual awareness for generating "requests for further data." The system continuously monitors micro-environmental factors around the client (e.g., local Wi-Fi signal strength and neighboring APs, Bluetooth device presence, ambient light sensor readings, accelerometer data from the device itself for posture/motion) as additional passive data points. Active data includes not just typical input but also application-specific usage patterns (e.g., sequence of menu navigations in a CAD software, specific hotkey combinations in a video editor). When the "first analysis value" indicates potential bot activity, the "request for further data" is dynamically generated based on the current, hyper-localized context of the user. For instance, if the client's accelerometer indicates movement, the challenge might be a physics-based puzzle (e.g., balancing a virtual object); if nearby Bluetooth devices are detected, it might require interacting with a specific paired device. This makes it significantly harder for bots to spoof a contextually relevant response.

graph TD
    A[Client Computer] --> B{Active Data (Input, App Usage)};
    C[Client Sensors (Wi-Fi, Bluetooth, Light, Accelerometer)] --> D{Hyper-Local Passive Data};
    B & D --> E[Data Stream];
    E --> F[Server-Side Analysis Module];
    F --> G[Human Interaction Model Database];
    F -- First Analysis --> H{First Analysis Value};
    H -- Fails Criteria --> I[Context-Aware Challenge Generator];
    I --> J[Current Environmental/Device Context];
    J --> I;
    I -- Generates Challenge --> K[Request Further Data (Contextual)];
    K --> A;

---

2.3. Cross-Domain Application: Bot Detection for Smart City Infrastructure Management

Enabling Description:
This derivative applies bot detection to the critical infrastructure management of a smart city, specifically for control systems accessed by human operators (e.g., traffic light control, public utility management, emergency dispatch systems). The "client computer" is a specialized operator workstation. Active data collected includes operator-specific GUI interaction patterns (e.g., drag-and-drop operations for routing emergency vehicles, precise slider adjustments for water pressure, timing of command sequences for power grid switching). Passive data includes network flow analytics from the workstation, physical access logs to the control room, and multi-factor authentication event logs. Model data represents typical human operational sequences and response times during routine and emergency scenarios. If the "first analysis value" suggests bot activity, the "request for further data" could involve a procedural knowledge test within a simulated environment (e.g., "re-sequence these traffic lights to clear congestion given this incident" or "identify the correct shut-off valve diagram"), or a biometric voice challenge confirming the operator's identity and authority.

flowchart TD
    A[Operator Workstation (Smart City Control)] --> B{Active Data (GUI Interaction Patterns)};
    C[Network Flow Analytics, Physical Access Logs, MFA Logs] --> D{Passive Data};
    B & D --> E[Data Collection Module];
    E --> F[Smart City Server];
    F --> G[Human Operator Model (Routine/Emergency)];
    F -- First Analysis --> H{First Analysis Value (Human/Bot)};
    H -- Fails Criteria --> I[Request Further Data (Procedural/Biometric)];
    I --> A;
    A --> J[Operator Response];
    J --> F;
    F -- Second Analysis --> K{Access Decision};
    K -- Granted --> L[Maintain System Control];
    K -- Denied --> M[Lockdown System / Alert Authorities];

---

2.4. Integration with Emerging Tech: Predictive Bot-Activity Forecasting via Quantum Machine Learning (QML)

Enabling Description:
This derivative uses Quantum Machine Learning (QML) for a highly sophisticated "first analysis" that not only detects current bot activity but also predicts future bot behaviors. Active and passive data (e.g., device telemetry, network traffic patterns, user interaction streams) are pre-processed and encoded into quantum states. A quantum neural network (QNN) or variational quantum eigensolver (VQE) running on a hybrid quantum-classical computing architecture performs the "first analysis." This QML model identifies complex, non-linear correlations in the data that classical models might miss, enabling earlier and more nuanced detection. The model data for human interactions is similarly encoded. If the QML-derived "first analysis value" (a quantum-probability amplitude) fails to meet criteria, a "request for further data" is provided. This could be a personalized, cryptographically-secure challenge generated by a Post-Quantum Cryptography (PQC) algorithm, requiring the user to solve a PQC-based puzzle that is computationally intractable for classical bots.

sequenceDiagram
    participant CC as Client Computer
    participant QC as Quantum/Classical Hybrid Server
    participant DB as Model Data Database
    participant CH as Challenge Generator (PQC)

    CC->>QC: Transmit Active/Passive Data (Quantum-encoded)
    QC->>DB: Load Quantum-encoded Human Model Data
    QC->>QC: Perform First Analysis (QML)
    QC-->>CC: First Analysis Value (Quantum Probability)
    alt If First Analysis Value Fails Criteria
        QC->>CH: Request PQC Challenge
        CH-->>QC: PQC Challenge Parameters
        QC->>CC: Provide PQC Challenge
        CC->>CC: User Solves PQC Challenge
        CC->>QC: Transmit PQC Solution
        QC->>QC: Perform Second Analysis (PQC Verification)
        QC-->>CC: Second Analysis Value
    else
        QC->>CC: Grant Access
    end

---

2.5. The "Inverse" or Failure Mode: Fail-Safe User Verification with Human Oversight

Enabling Description:
This derivative is designed for high-assurance scenarios where false positives (denying a human) are unacceptable, or where the "request for further data" might fail (e.g., network outage). In this "fail-safe" mode, if the "first analysis value" fails to meet predetermined criteria, access is not immediately denied, nor is a CAPTCHA automatically presented. Instead, the system triggers a "request for further data" to a human oversight committee or a pre-designated human security analyst. The system forwards the collected active and passive data, along with the first analysis value, to this human reviewer. The user at the client computer enters a "pending verification" state with extremely limited (e.g., only static content viewing) or no direct interaction capabilities with the protected resource. The human analyst then reviews the evidence and can manually "override" the system's determination, approve access, or initiate a direct human-to-human verification process (e.g., video call, phone call with pre-arranged code words).

stateDiagram
    [*] --> InitialAccessAttempt;
    InitialAccessAttempt --> CollectActivePassiveData;
    CollectActivePassiveData --> PerformFirstAnalysis;
    PerformFirstAnalysis --> IfCriteriaMet: AccessGranted;
    PerformFirstAnalysis --> IfCriteriaFailed: PendingHumanReview;
    PendingHumanReview --> NotifyHumanAnalyst;
    NotifyHumanAnalyst --> A[Human Analyst Review Data];
    A --> B[Analyst Decision];
    B --> C[Approve Access]: AccessGranted;
    B --> D[Deny Access]: AccessDenied;
    B --> E[Request Direct Human Verification]: DirectVerification;
    DirectVerification --> AccessGranted;
    DirectVerification --> AccessDenied;
    AccessGranted --> [*];
    AccessDenied --> [*];

---

Derivations based on Independent Claim 22

Claim 22 Summary: A non-transitory machine readable medium for providing a value indicating a judgment of human/bot operation, by providing remote monitoring instructions, receiving monitored data, performing a first-level analysis, performing a second-level analysis (if first fails, compare with prior human interactions), and providing a second-level analysis value.

---

3.1. Material & Component Substitution: Network-Level Deep Packet Inspection (DPI) with Custom Hardware

Enabling Description:
This derivative focuses on network-level monitoring rather than client-side software. A custom-built hardware appliance, containing specialized network interface cards and an FPGA/ASIC for high-speed packet processing, is deployed within the network perimeter (e.g., datacenter egress points, corporate firewall). This appliance performs Deep Packet Inspection (DPI) on all client-server traffic, extracting both active (e.g., HTTP request timings, payload size variability, observed JavaScript execution patterns within HTTP responses) and passive (e.g., TCP/IP fingerprinting, TLS handshake characteristics, DNS query patterns) data without client-side agents. The "first level of analyzing" involves real-time signature matching against known bot network traffic patterns. If this first level is inconclusive, a "second level of analyzing" is performed by streaming the anomalous packet data to a powerful server with a GPU-accelerated behavioral analytics engine. This engine compares the observed network flow patterns against established model data derived from authenticated human users' network behavior from prior sessions, identifying subtle deviations in network cadence, request sizes, and protocol compliance.

graph TD
    A[Client Computer] --> B[Network Traffic (Encrypted/Unencrypted)];
    B --> C[DPI Appliance (FPGA/ASIC)];
    C -- Extract Active/Passive Data --> D{Network Data Stream};
    D --> E[First Level Analysis (Signature Matching)];
    E -- If Human Indication --> F[Provide Access / Continuous Monitoring];
    E -- If No Human Indication (Fails Criteria) --> G[Stream Anomalous Data];
    G --> H[GPU-Accelerated Behavioral Analytics Server];
    H --> I[Human Network Behavior Model DB];
    H -- Second Level Analysis (Pattern Comparison) --> J{Second-Level Analysis Value};
    J -- Meets Criteria --> F;
    J -- Fails Criteria --> K[Block Traffic / Incident Response];

---

3.2. Operational Parameter Expansion: Predictive Anomaly Detection for Large-Scale Distributed Systems

Enabling Description:
This derivative extends monitoring to vast, distributed computing systems (e.g., cloud data centers, edge computing networks) handling millions of concurrent client interactions. The system doesn't just detect bots; it predicts potential bot campaigns. Monitored data is collected across thousands of nodes, including server-side logs, application performance metrics, network telemetry, and aggregated client-side signals (e.g., load balancer statistics, CDN access logs). A "first level of analyzing" uses streaming analytics (e.g., Apache Flink, Kafka Streams) to identify real-time deviations from expected traffic baselines across the entire distributed system. If anomalies are detected (failing first-level criteria), the system triggers a "second level of analyzing." This involves feeding historical and real-time anomalous data into a large-scale predictive model (e.g., an LSTM or Prophet model trained on past bot attacks) to forecast the likelihood and potential vector of a future bot campaign. The "second-level analysis value" would be a risk score indicating the probability and estimated impact of an impending bot attack, allowing for pre-emptive defense measures.

flowchart LR
    subgraph Data Sources
        C1[Client Traffic]
        S1[Server Logs]
        N1[Network Telemetry]
        A1[Application Metrics]
    end

    C1 & S1 & N1 & A1 --> D[Distributed Data Ingestion (e.g., Kafka)];
    D --> E[Streaming Analytics (First-Level Analysis)];
    E -- Baseline Deviation Alerts --> F{Anomalous Data Stream};
    E -- No Deviation --> G[Normal Operations];

    F --> H[Historical Data Repository];
    F & H --> I[Large-Scale Predictive Model (Second-Level Analysis)];
    I -- Generates --> J[Second-Level Analysis Value (Risk Score)];
    J --> K{Decision Engine};
    K -- High Risk --> L[Pre-emptive Defense Actions];
    K -- Low Risk --> G;

---

3.3. Cross-Domain Application: Bot Detection for Autonomous Agricultural Systems

Enabling Description:
This derivative applies bot detection to autonomous agricultural machinery (e.g., self-driving tractors, robotic harvesters) controlled remotely by human operators. The goal is to ensure that remote commands originate from an authorized human and not a malicious bot attempting to disrupt operations or steal resources. The "client computer" is the human operator's control station, while the "server" is the farm's central management system communicating with the autonomous machines. Monitored data includes active data (e.g., joystick movements, touchscreen inputs, voice commands for fine-tuning) from the operator's station and passive data (e.g., GPS coordinates of the operator, video feed of the operator from the control room, command execution timestamps from the machines). The "first level of analyzing" checks for basic human-like control patterns and adherence to geofencing. If the first level fails, a "second level of analyzing" compares the operator's command sequences and movement profiles against model data of verified human operators performing specific agricultural tasks (e.g., precise steering for planting, rhythmic motions for harvesting). A "second-level analysis value" determines if the commands are genuinely human-driven, with potential for emergency stops or manual overrides if bot activity is confirmed.

sequenceDiagram
    participant HO as Human Operator (Control Station)
    participant FMC as Farm Management Server
    participant AM as Autonomous Machine

    HO->>FMC: Remote Control Commands (Joystick, Touch, Voice)
    HO->>FMC: Active Data (Control Input, Video Feed)
    HO->>FMC: Passive Data (GPS, Station Logs)
    FMC->>FMC: First Level Analysis (Basic Control Patterns, Geofence)
    alt If First Level Fails
        FMC->>FMC: Second Level Analysis (Compare with Human Operator Model)
        FMC-->>AM: Second-Level Analysis Value
        alt If Second-Level Analysis Fails
            FMC->>AM: Issue Emergency Stop / Manual Override
        else If Second-Level Analysis Meets Criteria
            FMC->>AM: Transmit Control Commands
        end
    else If First Level Meets Criteria
        FMC->>AM: Transmit Control Commands
    end
    AM->>FMC: Machine Status Feedback

---

3.4. Integration with Emerging Tech: Explainable AI (XAI) for Transparent Bot Detection and Trust Anchoring with Blockchain

Enabling Description:
This derivative integrates Explainable AI (XAI) for greater transparency in bot detection decisions, combined with blockchain for immutable record-keeping and trust anchoring. Monitored active and passive data is fed into an XAI-enabled machine learning model (e.g., a neural network with LIME or SHAP integration). The "first level of analyzing" quickly flags highly suspicious patterns. If a determination is made, the XAI component provides a human-readable "explanation" for why a user was classified as a human or a bot (e.g., "mouse movements were too linear and lacked human tremor," or "typing speed was consistent with human variance"). If this first level is inconclusive, a "second level of analyzing" performs a deeper dive, generating a more detailed explanation alongside a probability score. This explanation, along with the raw data and the model's output, is then hashed and timestamped on a public or consortium blockchain (e.g., Hyperledger Fabric), creating an immutable, auditable record of the decision. This blockchain entry acts as a trust anchor, proving the integrity of the bot detection process and mitigating disputes, particularly crucial for regulatory compliance or appeal processes.

flowchart TD
    A[Client Computer] --> B{Monitored Data (Active + Passive)};
    B --> C[XAI-Enabled ML Model (First Level Analysis)];
    C -- Decision + Explanation --> D{Blockchain Notary Service};
    D -- Hash & Timestamp --> E[Blockchain (Immutable Audit Log)];
    C -- Inconclusive --> F[Second Level Analysis (Deeper XAI)];
    F -- Detailed Decision + Explanation --> D;
    D --> E;
    E -- Provides Transparency --> G[Auditors / Regulators];
    C -- Decision (Human) --> H[Grant Access];
    C -- Decision (Bot) --> I[Deny Access];

---

3.5. The "Inverse" or Failure Mode: Stealthy Behavioral Profiling for Threat Intelligence

Enabling Description:
This derivative operates in a "stealthy" or "audit-only" mode, primarily for gathering threat intelligence on sophisticated botnets without immediately alerting or blocking them. The system provides instructions for covert remote monitoring, ensuring that data collection is entirely transparent to the client computer's operator, even if it is a bot. Received monitored data (active and passive) is collected without any real-time access decisions or CAPTCHA challenges. The "first level of analyzing" passively profiles incoming traffic, segmenting it into broad categories (e.g., known human agents, suspected low-sophistication bots, unknown/novel patterns). If "unknown/novel patterns" are detected (failing a criterion for known human/bot activity), a "second level of analyzing" initiates deep behavioral profiling. This involves running the new patterns through a sandboxed environment where the bot's behavior is meticulously recorded over extended periods, mapping its routines, evasion techniques, and interaction speeds against advanced human interaction models. The "second-level analysis value" is not an access decision, but rather a detailed "threat intelligence report" on the new bot variant, including its likely origin, capabilities, and potential impact. This data is then used to update enterprise-wide bot detection models.

stateDiagram
    [*] --> CovertMonitoring;
    CovertMonitoring --> DataCollection;
    DataCollection --> FirstLevelProfiling;
    FirstLevelProfiling --> IfKnownHuman: HumanProfiled;
    FirstLevelProfiling --> IfKnownBot: KnownBotProfiled;
    FirstLevelProfiling --> IfNovelPattern: NovelPatternDetected;
    HumanProfiled --> UpdateThreatIntelDB;
    KnownBotProfiled --> UpdateThreatIntelDB;
    NovelPatternDetected --> SecondLevelDeepProfiling;
    SecondLevelDeepProfiling --> GenerateThreatIntelReport;
    GenerateThreatIntelReport --> UpdateThreatIntelDB;
    UpdateThreatIntelDB --> [*];

---

Combination Prior Art Scenarios with Open-Source Standards

Here are three scenarios combining the concepts of US11810014 with existing open-source standards to establish obviousness for future developments:

1. Integration of Behavioral Biometrics with OWASP ModSecurity Core Rule Set (CRS)

• Scenario: Combining the active and passive data collection and first-level analysis described in Claim 1 of US11810014 with the OWASP ModSecurity Core Rule Set (CRS) for web application firewalls (WAFs).
• Enabling Description: A web server running ModSecurity with CRS is configured to incorporate real-time behavioral biometric analysis. The "data collection data" provided by the server includes JavaScript that captures user-browser interactions (e.g., mouse movements, keystroke dynamics) and client-side environmental data (e.g., browser agent, screen resolution). This data, transmitted to the server, is processed by a server-side module (as per US11810014) to generate a "human confidence score." This score is then fed into ModSecurity as a custom variable. The CRS rules are modified to include conditions based on this human confidence score. For instance, if the score is below a certain threshold, requests from that client are subjected to more aggressive CRS rules (e.g., higher anomaly scoring, blocking known bot signatures, or triggering specific CAPTCHA challenges provided by ModSecurity's capabilities), effectively performing the "first analysis," "generating a first analysis value," and "providing a CAPTCHA test" as claimed.
• Open-Source Standard: OWASP ModSecurity Core Rule Set (CRS).
• Relevant Claims (US11810014): Claims 1, 9, 10, 11, 15.

2. Federated Learning for Distributed Human Model Training via OpenFL

• Scenario: Implementing the "model data based on human interactions from a prior session" (Claim 1, 16, 22) across multiple independent websites or services using the Open Federated Learning (OpenFL) framework.
• Enabling Description: Multiple participating websites, each deploying the client-side data collection mechanisms (JavaScript for active data like mouse/keyboard activity, passive data like IP/browser cookies), contribute to a shared, continually improving human interaction model. Instead of a central server aggregating all raw human interaction data (which raises privacy concerns), each website's server trains a local machine learning model based on its users' verified human interactions (model data). These local model updates (e.g., neural network weights) are then securely aggregated and averaged by a central aggregator using the OpenFL framework, without sharing raw data. This aggregated model, representing generalized human behavior, is then distributed back to each participating server for performing their "first analysis" or "second level of analyzing" in conjunction with their locally collected active and passive data. This ensures the model data is robust, diverse, and adaptive to evolving human interaction patterns.
• Open-Source Standard: OpenFL (Federated Learning framework).
• Relevant Claims (US11810014): Claims 1, 5, 9, 14, 16, 18, 22, 24.

3. Behavioral Data Telemetry and Anomaly Detection with ELK Stack

• Scenario: Utilizing the Elastic Stack (Elasticsearch, Logstash, Kibana) for real-time ingestion, storage, analysis, and visualization of the monitored active and passive data (Claim 22), specifically for anomaly detection.
• Enabling Description: Client computers, via provided data collection data (e.g., a JavaScript agent), transmit active data (mouse movements, keystrokes, form interactions) and passive data (browser type, OS, IP address) as telemetry logs. These logs are ingested by Logstash, processed, and stored in Elasticsearch. Kibana is used to visualize these raw data streams and human interaction model data. A "first level of analyzing" (Claim 22) is performed by Elasticsearch's machine learning capabilities (e.g., anomaly detection jobs) on the incoming data stream, identifying unusual spikes or deviations from expected human behavioral baselines. If a first-level anomaly is detected (failing criteria), a "second level of analyzing" is triggered. This involves a more complex query or script that compares the anomalous user's detailed interaction patterns (retrieved from Elasticsearch) against historical "model data" (stored in Elasticsearch) of verified human users. Alerts are then generated in real-time if a high bot likelihood is determined, enabling immediate action.
• Open-Source Standard: ELK Stack (Elasticsearch, Logstash, Kibana).
• Relevant Claims (US11810014): Claims 1, 16, 22, 28, 29, 30.