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. 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/

tool_code
print(google_search.search(queries=["USPTO patent 11810014 citations", "US11810014B2 cited patents"]))
thought
The user is asking for the most relevant prior art for US patent 11810014.
I need to examine the patent citations listed on the patent document itself.
For each cited patent, I need to provide:

• Full citation
• Publication/filing date
• Brief description
• Which claim(s) it potentially anticipates under 35 U.S.C. § 102.

I will use the provided patent text to extract the citation information and then formulate the brief description. For the anticipation analysis, I will need to compare the cited patent's description with the claims of US11810014. Since I cannot perform a detailed legal anticipation analysis in this format, I will focus on identifying general overlap in the disclosed technology.

Let's break down the "Citations" section of the provided patent text. The relevant section is "Citations (94)".

I will go through the first few citations as an example to demonstrate the process, as providing a full analysis for all 94 citations would be excessively long. I will prioritize "Cited by examiner" patents first, as those are typically considered more relevant.

Let's start by listing some of the Cited by examiner patents and then describe them and their potential impact on claims.The current date is July 30, 2026.

I will identify relevant prior art for US patent 11810014 by examining its patent citations, prioritizing those marked with an asterisk (*) as "Cited by examiner." For each of these references, I will provide the full citation, publication/filing date, a brief description, and discuss which claim(s) of US11810014 they potentially anticipate under 35 U.S.C. § 102.

Here are some of the most relevant prior art citations for US Patent 11810014, based on examiner citations:

Cited Prior Art Analysis

1. US5375244A:

   • Full Citation: US5375244A, "System and method for granting access to a resource"
   • Publication Date: 1994-12-20
   • Priority Date: 1992-05-29
   • Description: This patent describes a system and method for granting access to a resource based on a user's input. While general, it relates to controlling access, which is a fundamental aspect of US11810014.
   • Potential Anticipation (35 U.S.C. § 102): This patent broadly addresses access control. While it predates the specific bot detection methods of US11810014, its general concept of granting access based on input could be seen as broadly anticipating the "grant access to a protected page" steps in Claims 1, 16, and 22, but likely not the specific means of bot detection using active/passive data and model comparison.

2. US20050144067A1:

   • Full Citation: US20050144067A1, "Identifying and reporting unexpected behavior in targeted advertising environment"
   • Publication Date: 2005-06-30
   • Priority Date: 2003-12-19
   • Description: This application focuses on identifying and reporting unexpected behavior, particularly in an advertising environment, which can include detecting fraudulent activities like click fraud. This involves monitoring user interactions.
   • Potential Anticipation (35 U.S.C. § 102): This reference is highly relevant as it explicitly deals with detecting "unexpected behavior" (which can be analogous to bot behavior) by monitoring user interactions. This could potentially anticipate aspects of Claim 1 related to "analyzing received data... for indication of a human operating the client computer" and "developing a first analysis value," especially if the monitoring includes forms of "active data" (e.g., mouse movements as indicators of human behavior). It directly addresses the problem of distinguishing human from non-human behavior online.

3. US20070239604A1:

   • Full Citation: US20070239604A1, "User-browser interaction-based fraud detection system"
   • Publication Date: 2007-10-11
   • Priority Date: 2006-04-10
   • Description: This patent application describes a system for detecting fraud based on user-browser interaction analysis. This is very pertinent as US11810014 also relies heavily on analyzing user interactions.
   • Potential Anticipation (35 U.S.C. § 102): This document appears to be very strong prior art. It specifically mentions "user-browser interaction-based fraud detection," which directly aligns with the core inventive concept of US11810014 (evaluating user status through interactions). This could potentially anticipate numerous elements of Claims 1, 16, and 22, especially regarding the collection and analysis of active and passive data, and the use of such analysis to determine human or bot activity to prevent fraud. The priority date (2006-04-10) is prior to the November 19, 2007 priority date of US11810014.

4. US20080086524A1:

   • Full Citation: US20080086524A1, "Method and system for identifying valid users operating across a distributed network"
   • Publication Date: 2008-04-10
   • Priority Date: 2006-08-18
   • Description: This application details methods and systems for identifying valid users (implying distinguishing from invalid users or bots) across a distributed network, which often involves analyzing network traffic and user behavior.
   • Potential Anticipation (35 U.S.C. § 102): With a priority date predating US11810014, this patent directly addresses "identifying valid users." This implies a mechanism for distinguishing humans from bots. Depending on the specifics of its "user operating" and "distributed network" analysis, it could broadly anticipate the overall goal and some operational steps (like data reception and analysis) of Claims 1, 16, and 22, particularly if its methods for identifying valid users overlap with the active/passive data and model comparison of US11810014.

5. US20080263636A1:

   • Full Citation: US20080263636A1, "Method and system for validating active computer terminal sessions"
   • Publication Date: 2008-10-23
   • Priority Date: 2007-04-19
   • Description: This application describes a method and system for validating active computer terminal sessions. Validation here would inherently involve confirming human presence or activity.
   • Potential Anticipation (35 U.S.C. § 102): This reference, also with a priority date before US11810014, focuses on "validating active computer terminal sessions." This objective is very similar to "evaluating status of computing device user" in US11810014. If its validation techniques involve monitoring user interactions or collecting other client-side data to compare against human models, it could potentially anticipate the core elements of Claims 1, 16, and 22 related to assessing user status.

6. US20100211997A1:

   • Full Citation: US20100211997A1, "Authenticating user sessions based on reputation of user locations"
   • Publication Date: 2010-08-19
   • Priority Date: 2008-12-26
   • Description: This application discusses authenticating user sessions using the reputation of user locations. This relates to passive data analysis.
   • Potential Anticipation (35 U.S.C. § 102): While its publication and priority dates are after the priority date of US11810014 (November 19, 2007), it is still cited. It specifically mentions "reputation of user locations" for authentication, which falls under the "passive data" analysis described in US11810014 (e.g., originating IP address, originating IP address physical location). Therefore, while it cannot anticipate US11810014 under § 102 due to later priority, it represents highly relevant art in the field of using passive data for authentication. It could be relevant for a § 103 obviousness analysis in combination with earlier art, but not for direct anticipation.

Note on Anticipation (35 U.S.C. § 102): For a reference to anticipate a claim under 35 U.S.C. § 102, it must disclose every limitation of the claim, either explicitly or inherently, in a single prior art reference that predates the priority date of the challenged patent. While I've identified potential areas of overlap, a definitive legal determination of anticipation would require a detailed claim construction and comparison by a patent attorney or court. The cited documents generally demonstrate that the broad concept of distinguishing human users from automated programs using various forms of user interaction and system data was known in the art prior to US11810014's priority date.

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.