Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in
37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible
for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been
timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR
1.114. Applicant’s submission filed on 04/09/2026 has been entered.
Claims 1, 8 and 15 are independent claims. The applicant has amended claims 1-5, 7-8, 12, 15 and 20, claim 14 has been cancelled. Claims 1-13 and 15-20 have been examined and are pending. This Action is made Non-FINAL.
Response to Arguments
Applicants’ arguments in the instant Amendment, filed on 04/09/2026, with respect to
limitations listed below, have been fully considered but they are not persuasive. Applicant’s
arguments with respect to claim(s) 1, 8 and 15 have been considered but are moot because the
new ground of rejection does not rely on any reference applied in the prior rejection of record for
any teaching or matter specifically challenged in the argument.
The Examiner respectfully suggests that the claim be further amended; details in the
specification be incorporated, to distinguish the claimed invention over prior art of record.
Should the Applicant desire an interview to further clarify the claim interpretation/rejections,
please contact the Examiner at (571) 272-1531 to schedule an interview.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-4 and 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Steiner (US 2015/0355957 A1), in view of Brown (US 2017/0295190 A1) and further in view of Singh (US 2020/0404007 A1).
Regarding Claim 1
Steiner discloses:
A method executed by a computer system that assesses a timestamped database query, comprising:
receiving, by the computer system, a time-stamped [a direct audit program such as Centrify DirectAudit may generate a data stream indicative of user interaction on a user machine/workstation including a timestamp, machine user ID and user commands; ¶0056];
receiving, by the computer system, the time-stamped database query [IBM Guardium agents may generate data streams indicative of database interaction on a database server including a timestamp, client machine IP, database user ID, database server IP, and the database query (SQL query); ¶0056];
determining, by the computer system, a mutual detection between the time-stamped endpoint cybersecurity detection and the time-stamped database query [the CEP platform of analysis engine 102 may correlate the keyboard interactions from the user X audit data stream with the data queries shown by the agent data stream, determining that one of the data queries from user X is not correlated with/preceded by a keyboard interaction on user x machine, evaluated against the applicable model of normalcy; ¶0061];
determining, by the computer system, a detection-query timeframe between the time-stamped endpoint cybersecurity detection and the time-stamped database query [a model or pattern of normalcy may dictate that a certain event from one data stream is always preceded within, e.g., five (5) seconds, by a certain event from a second data stream, and embodiments apply a time window to detect correlations, which can be increased or decreased; ¶0069];
in response to the mutual detection and the detection-query timeframe, predicting, by the computer system, that the time-stamped database query is a malicious database query [if the applicable model of normalcy indicates that typical data queries are always preceded by/correlated with a keyboard interaction, analysis engine 102 may characterize the uncorrelated data query as an anomaly; ¶0061]; and
in response to the predicting of the malicious database query, blocking, by the computer system, the time-stamped database query [an alert may comprise a command instructing the restriction or shutting down of an affected workstation, database, network or network access; ¶0016 and 0057].
Steiner discloses correlating heterogeneous workstation and database-query streams across time and evaluating the correlation against a model of normalcy to characterize an uncorrelated database query as an anomaly (Steiner: 0061, 0069), and generating a classification event with a DETAIL record from processed events (Steiner: 0088, 0090). Steiner does not disclose that the workstation is a cybersecurity detection generated by a cybersecurity agent, or that the correlated events are events specified by a cybersecurity event signature. Brown discloses a cybersecurity agent on a monitored endpoint that receives timestamped event notifications and, using a correlator index of object/activity type combinations associated with an exploit, correlates the events and generates an exploit detection event (Brown: ¶0008, 0022, 0025, 0030). It would have been obvious to one having ordinary skill in the art to generate Steiner's workstation as a cybersecurity detection from an endpoint cybersecurity agent, and to evaluate Steiner's correlation against Brown's predefined event type combinations since Steiner and Brown are analogous art directed to detecting security threats via correlated timestamped events. The motivation to combine would be to ground Steiner's correlation in a predefined set of exploit indicative event types rather than a general model of normalcy (Steiner: ¶0061; Brown: ¶0010).
Steiner and Brown do not disclose that the database query is intercepted by the same cybersecurity agent monitoring the endpoint device, or that the query is determined malicious and blocked. Singh discloses an application agent hooking SQL/NoSQL/LDAP query execution functions and an operating system agent, with events from both agents linked via a common process ID (Singh: ¶0043, 0337-0338), and further discloses stopping a thread once classified as malicious and preventing execution of a query whose parameters match an exploit pattern (Singh: ¶0159, 0166). It would have been obvious to one having ordinary skill in the art to implement Steiner's monitoring using Singh's linked agent architecture and apply Singh's short circuit enforcement to the query identified by Steiner/Brown, since all three references are directed to endpoint agent detection of malicious database activity. The motivation to combine would be to enable targeted blocking of the specific malicious query rather than Steiner's broader workstation or network level action (Singh: ¶0166).
Regarding Claim 2
Steiner discloses:
The method of claim 1, further comprising determining that the timestamped database query occurs within the detection-query timeframe of the endpoint cybersecurity detection [a model of normalcy may dictate that a certain event from one data stream is always preceded within, e.g., five (5) seconds, by a certain event from a second data stream, and embodiments apply a time window to detect correlations, which can be increased or decreased; ¶0069. The CEP platform of analysis engine 102 may correlate the keyboard interactions from the user X audit data stream with the data queries shown by the agent data stream, determining that one of the data queries from user X is not correlated with/preceded by a keyboard interaction on user x machine within the applicable window; ¶0061].
Regarding Claim 3
Steiner discloses:
The method of claim 1, further comprising determining that the timestamped database query conforms to a cybersecurity assessment profile [analyzing a pattern or sequence of events and comparing to other patterns or sequence of events can detect anomalies not detectable by looking at a single event, wherein a database query is preceded by user interaction represents the applicable pattern of normalcy against which the query is evaluated; ¶0061].
Regarding Claim 4
Steiner discloses:
The method of claim 1, further comprising determining that the timestamped database query fails to conform to a cybersecurity assessment profile [if the applicable model of normalcy indicates that typical data queries are always preceded by/correlated with a keyboard interaction, analysis engine 102 may characterize the uncorrelated data query as an anomaly; ¶0061].
Regarding Claim 6
Steiner discloses:
The method of claim 1, further comprising predicting a cybersecurity attack [embodiments identify and alert in real-time insider threat attacks targeting database and systems using databases, such as file storage and sharing systems, where such threats may involve unauthorized manipulation and falsification of data, sabotage of databases, and exfiltration of data; ¶0030].
Claims 5 and 7 are rejected under 35 U.S.C. 103 as being unpatentable over Steiner (US 2015/0355957 A1) in view of Brown (US 2017/0295190 A1), in view of Singh (US 2020/0404007 A1) as applied to claim 1 above, and further in view of Herwadkar (US 2019/0102553 A1).
Regarding Claim 5
Steiner, Brown, and Singh teach the limitations of claim 1, including determining the detection query timeframe, evaluating the mutual detection against a cybersecurity event signature, intercepting the database query within a common cybersecurity agent framework, and predicting and blocking the malicious database query. Steiner, Brown, and Singh do not explicitly teach determining that the database query is a true positive report. Herwadkar, however, teaches calculating a confidence score for an identified anomaly, where the confidence score reflects the degree to which a threshold is not met, and further teaches tuning thresholds to reflect a false positive tolerance and obtaining user feedback to identify and correct queries that were previously, but incorrectly, flagged as anomalous [¶0060-0061, ¶0114-0118,]. It would have been obvious to one of ordinary skill in the art to incorporate Herwadkar's confidence determination into the Steiner/Brown/Singh combination so that a query identified as malicious is further validated as a true positive rather than a false positive, since Herwadkar is analogous art directed to reducing false positives in database query anomaly detection. The motivation to combine would be to improve the reliability of the malicious-query determination before the query is blocked.
Regarding Claim 7
Steiner, Brown, and Singh teach the limitations of claim 1, including determining the detection query timeframe, evaluating the mutual detection against a cybersecurity event signature, intercepting the database query within a common cybersecurity agent framework, and predicting and blocking the malicious database query. Steiner, Brown, and Singh do not explicitly teach that an object requested by the database query is compared to that signature. Herwadkar, however, teaches parsing a database query to extract semantic attributes including object references such as table names and column identifiers selected by the query, and comparing those extracted attributes, via a vector representation, against a set of trained query attributes to identify anomalies [¶0033, ¶0052, ¶0067, ¶0094-0095]. It would have been obvious to one of ordinary skill in the art to compare the object requested by the database query, as extracted using Herwadkar's attribute-parsing technique, against the cybersecurity event signature of the Steiner/Brown/Singh combination, since Herwadkar is analogous art directed to identifying the specific database objects targeted by a query for security assessment purposes. The motivation to combine would be to enable the signature comparison to account for which specific database object the query is attempting to access, improving detection precision.
Claim 8-13 and 15-20 is rejected under 35 U.S.C. 103 as being unpatentable over Steiner (US 2015/0355957 A1), in view of Brown (US 2017/0295190 A1), in view of Singh (US 2020/0404007 A1), and further in view of Klein (US 2020/0097587 A1).
Regarding Claim 8
Steiner discloses:
At least one computer system that assesses a time-stamped database query, comprising:
at least one central processing unit; and at least one memory device storing instructions that, when executed by the at least one central processing unit, perform operations, the operations comprising:
receiving a time-stamped e[a direct audit program such as Centrify DirectAudit may generate a data stream indicative of user interaction on a user machine/workstation including a timestamp, machine user ID and user commands; ¶0056];
receiving the time-stamped database query intercepted by a server associated with a database [IBM Gu ardium agents may generate data streams indicative of database interaction on a database server including a timestamp, client machine IP, database user ID, database server IP, and the database query (SQL query); ¶0056];
determining a mutual detection between the time-stamped endpoint cybersecurity detection and the time-stamped database query [the CEP platform of analysis engine 102 may correlate the keyboard interactions from the user X audit data stream with the data queries shown by the agent data stream, determining that one of the data queries from user X is not correlated with/preceded by a keyboard interaction on user x machine, evaluated against the applicable model of normalcy; ¶0061];
determining a detection-query timeframe between the time-stamped endpoint cybersecurity detection intercepted by the cybersecurity agent and the timestamped database query intercepted the server associated with the database [a model or pattern of normalcy may dictate that a certain event from one data stream is always preceded within, e.g., five (5) seconds, by a certain event from a second data stream, and embodiments apply a time window to detect correlations, which can be increased or decreased; ¶0069];
referencing mutual occurrences and detection-query timeframes between database queries and endpoint cybersecurity detections [the models of normalcy and rules are developed through machine learning techniques applied by the CEP platform, built from data streams reflecting typical behavior, capturing both the correlation pattern between a database query and a corresponding workstation event and the applicable time window between them; ¶0058, 0060, 0061, 0069];
determining the time-stamped database query represents a malicious operation based on an output generated by the cybersecurity service [if the applicable model of normalcy indicates that typical data queries are always preceded by/correlated with a keyboard interaction, analysis engine 102 may characterize the uncorrelated data query as an anomaly; ¶0061]; and
in response to the determining that the time-stamped database query represents the malicious operation, blocking the time-stamped database query [an alert may comprise a command instructing the restriction or shutting down of an affected workstation, database, network or network access; ¶0016 and 0057].
Steiner does not disclose that the workstation is characterized as an endpoint cybersecurity detection generated by a cybersecurity agent, or that the correlated events are events specified by a cybersecurity event signature. Brown further discloses a cybersecurity agent implemented on a monitored endpoint that receives timestamped event notifications and, using a correlator index specifying combinations of object type and activity type associated with an exploit, correlates the events and generates an exploit detection event (Brown: ¶0008, 0022, 0025, 0030). It would have been obvious to one having ordinary skill in the art to generate Steiner's workstation as a time-stamped endpoint cybersecurity detection from an endpoint cybersecurity agent, and to evaluate Steiner's mutual detection against Brown's predefined event combinations, since Steiner and Brown are analogous art directed to detecting security threats via correlated timestamped events. The motivation to combine would be to ground Steiner's correlation in a predefined set of exploit indicative event types rather than a general model of normalcy (Steiner: ¶0061; Brown: ¶0010).
Steiner and Brown do not disclose comparing the detection-query timeframe to the machine-learning-trained profile as a discrete pre-screening step performed prior to the mutual-detection and malicious-determination analysis. Klein, however, discloses determining whether a hash value associated with an application-side query matches a hash value associated with a database-side query and, if a match is found, correlating the two using additional information including whether the queries are at least partially contemporaneous, prior to providing the correlated information to a machine learning classifier for a fuller determination of malicious activity (Klein: ¶0052, 0076-0078). It would have been obvious to one having ordinary skill in the art to structure Steiner's correlation-and-classification process as a discrete pre-screening step, using Steiner's timeframe-and-occurrence-based profile as the preliminary comparison, consistent with Klein's staged correlate-then-classify architecture, since Steiner and Klein are analogous art directed to correlating timestamped query-related events to detect malicious database activity. The motivation to combine would be to improve processing efficiency by filtering non-matching or out-of-window query events prior to committing to the fuller classification analysis (Klein: ¶0076).
Steiner, Brown, and Klein do not disclose that the query is determined malicious and blocked as such, as opposed to Steiner's more general workstation/database/network-level alert action. Singh, however, discloses that upon invocation of an exit function such as a SQL query execution function, if the function's parameters match an exploit pattern list, the agent will not allow the call to execute and returns a non-zero value, and that once a detection framework classifies a detected anomaly as malicious, an agent stops the thread or otherwise prevents execution (Singh: ¶0159, 0166). It would have been obvious to one having ordinary skill in the art to apply Singh's malicious-classification and short-circuit enforcement technique to the query identified by the Steiner/Brown/Klein combination, since Singh is analogous art directed to endpoint-agent-based prevention of malicious database query execution. The motivation to combine would be to enable targeted blocking of the specific malicious query rather than Steiner's broader workstation, database, or network-level action (Singh: ¶0166).
Regarding Claim 9
Claim 9 is directed to a system corresponding to the computer-implemented method in claim 2. Claim 9 is similar in scope to claim 2 and is therefore rejected under similar rationale.
Regarding Claim 10
Steiner discloses:
The at least one computer system of claim 8, wherein the operations further comprise determining that the detection-query timeframe conforms to the profile [a model or pattern of normalcy may dictate that a certain event from one data stream is always preceded within, e.g., five (5) seconds, by a certain event from a second data stream; a data query correlated with/preceded by a keyboard interaction within that time window conforms to the applicable model of normalcy; ¶0061, 0069].
Regarding Claim 11
Steiner discloses:
The at least one computer system of claim 8, wherein the operations further comprise determining that the detection-query timeframe fails to conform to the profile [if the applicable model of normalcy indicates that typical data queries are always preceded by/correlated with a keyboard interaction, analysis engine 102 may characterize the uncorrelated data query as an anomaly; ¶0061].
Regarding Claim 12
Klein further teaches:
The at least one computer system of claim 11, wherein the operations further comprise allowing the time-stamped database query (Klein: [0076]: injection detection component 510 processes information received from client system 504 and database system 508 to determine whether a query may be associated with a query language injection attempt). Klein further discloses that the machine learning classifier produces a result, and that if the result indicates the query is benign, the database system proceeds to forward the query to a query executor for execution (Klein: [0078]: machine learning classifier 554 provides a result 556; database system 508 can proceed to forward the query to a query executor 562 if the query is benign).
It would have been obvious to one having ordinary skill in the art to allow the time stamped database query to execute where the query is not affirmatively determined to be malicious, in the system of Steiner/Brown/Klein/Singh, because Steiner and Klein are analogous art directed to database query anomaly and injection attempt detection systems that determine whether to permit or restrict execution of a monitored query (Steiner: [0016]: alert may comprise a command instructing the restriction or shutting down of an affected workstation, database, network or network access; Klein: [0078]). The motivation to combine would be to avoid unnecessarily disrupting normal database operations by permitting execution of queries that are not affirmatively confirmed to be malicious, thereby reducing false-positive impact on legitimate database access.
Regarding Claim 13
Steiner discloses:
The at least one computer system of claim 8, wherein the operations further comprise predicting a cybersecurity attack [embodiments identify and alert in real-time insider threat attacks targeting database and systems using databases, such as file storage and sharing systems, where such threats may involve unauthorized manipulation and falsification of data, sabotage of databases, and exfiltration of data; ¶0030].
Regarding Claim 15
Steiner discloses:
A memory device storing instructions that, when executed by a central processing unit, perform operations, comprising:
monitoring [system 100 may include monitoring agents such as IBM Guardium agents located at databases, agents located at applications, direct audit programs such as Centrify DirectAudit located at user workstations, and network sensors located at access points to a network; IBM Guardium agents may generate data streams indicative of database interaction on a database server including a timestamp, client machine IP, database user ID, database server IP, and the database query (SQL query); ¶0055-0056];
determining a mutual detection between [the CEP platform of analysis engine 102 may correlate the keyboard interactions from the user X audit data stream with the data queries shown by the agent data stream, determining that one of the data queries from user X is not correlated with/preceded by a keyboard interaction on user x machine, evaluated against the applicable model of normalcy; ¶0061];
agents monitoring client devices [the models of normalcy and rules are developed through machine learning techniques applied by the CEP platform, built from data streams reflecting typical behavior received from various agents, sensors and audit programs located at workstations; ¶0055, 0058, 0060, 0061];
generating cybersecurity predictions associated with the pre-screening of the mutual detections [if the applicable model of normalcy indicates that typical data queries are always preceded by/correlated with a keyboard interaction, analysis engine 102 may characterize the uncorrelated data query as an anomaly; ¶0061]; and
blocking the [an alert may comprise a command instructing the restriction or shutting down of an affected workstation, database, network or network access; ¶0016 and 0057].
Steiner does not disclose the struck-through portions above: that the monitored queries are LDAP queries or reported via a cloud computing environment, that the correlated events are events specified by a cybersecurity event signature, that the pre-screening step comprises routing the mutual detection to a distinct cybersecurity service, or that LDAP queries specifically are blocked as such. Brown discloses a cybersecurity agent implemented on a monitored endpoint that receives timestamped event notifications and, using a correlator index specifying combinations of object type and activity type associated with an exploit, correlates the events and generates an exploit detection event (Brown: ¶0008, 0022, 0025, 0030). It would have been obvious to one having ordinary skill in the art to evaluate Steiner's mutual detection against Brown's predefined event-type combinations, since Steiner and Brown are analogous art directed to detecting security threats via correlated timestamped events. The motivation to combine would be to ground Steiner's correlation in a predefined set of exploit-indicative event types rather than a general model of normalcy (Steiner: ¶0061; Brown: ¶0010).
Steiner and Brown do not disclose that the monitored queries are LDAP queries or that LDAP queries specifically are blocked upon a suspicious determination. Singh, however, discloses that an application agent hooks into API calls including functions which execute SQL queries, NoSQL queries, and LDAP queries (Singh: ¶0043), and that upon invocation of an exit function such as a program execution, SQL/NoSQL, or LDAP query execution function, if the function's parameters match an exploit pattern list, the detection agent will take remedial action to stop the exploit code from execution (Singh: ¶0166). It would have been obvious to one having ordinary skill in the art to apply Steiner's mutual detection technique specifically to LDAP queries monitored and blocked using Singh's LDAP query hooking and short circuit enforcement technique, since Singh is analogous art directed to detecting and preventing malicious LDAP query execution. The motivation to combine would be to extend Steiner's database-query anomaly detection to LDAP-based directory access, a database access protocol also susceptible to injection attacks (Singh: ¶0022).
Steiner, Brown, and Singh do not disclose pre-screening the mutual detection by routing the mutual detection to a distinct cybersecurity service that compares the mutual detection to the machine learning trained profile. Klein, however, discloses an injection detection component, separate from the client system and database system, that receives correlated query information and applies a machine learning classifier to produce a benign or suspicious result (Klein: ¶0070, 0076-0078). It would have been obvious to one having ordinary skill in the art to route Steiner's mutual detection to a distinct cybersecurity service structured as Klein's injection detection component for comparison against the machine-learning-trained profile, since Steiner and Klein are analogous art directed to correlating and evaluating query-related events using a machine learning classification stage. The motivation to combine would be to modularize the detection process, allowing the correlation and classification functions to be updated or scaled independently (Klein: ¶0070).
Regarding Claim 16
Claim 16 is directed to a storing instructions corresponding to the computer-implemented method in claim 9. Claim 16 is similar in scope to claim 9 and is therefore rejected under similar rationale.
Regarding Claim 17
Claim 17 is directed to a storing instructions corresponding to the computer-implemented method in claim 10. Claim 17 is similar in scope to claim 10 and is therefore rejected under similar rationale.
Regarding Claim 18
Claim 18 is directed to a storing instructions corresponding to the computer-implemented method in claim 11. Claim 18 is similar in scope to claim 11 and is therefore rejected under similar rationale.
Regarding Claim 19
Claim 19 is directed to a storing instructions corresponding to the computer-implemented method in claim 12. Claim 19 is similar in scope to claim 12 and is therefore rejected under similar rationale.
Regarding Claim 20
Claim 20 is directed to a storing instructions corresponding to the computer-implemented method in claim 13. Claim 20 is similar in scope to claim 13 and is therefore rejected under similar rationale.
Conclusion
Any inquiry concerning this communication or earlier communications from the
examiner should be directed to SAAD ABDULLAH whose telephone number is (571) 272-1531.
The examiner can normally be reached on Monday - Friday, 9:30am - 5:30pm, EST. If attempts
to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Lynn Feild can
be reached on (571) 272-2092. The fax phone number for the organization where this application
or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent
Application Information Retrieval (PAIR) system. Status information for published applications
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished
applications is available through Private PAIR only. For more information about the PAIR
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would
like assistance from a USPTO Customer Service Representative or access to the automated
information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SAAD AHMAD ABDULLAH/Examiner, Art Unit 2431
/LYNN D FEILD/Supervisory Patent Examiner, Art Unit 2431
Prosecution Insights