Prosecution Insights
Last updated: April 18, 2026
Application No. 18/383,727

DISCONNECTED DATABASE DATA STRUCTURE PROTECTION

Non-Final OA §103
Filed
Oct 25, 2023
Examiner
ZHENG, BIN QING
Art Unit
2499
Tech Center
2400 — Computer Networks
Assignee
Servicenow Inc.
OA Round
3 (Non-Final)
63%
Grant Probability
Moderate
3-4
OA Rounds
3y 0m
To Grant
99%
With Interview

Examiner Intelligence

Grants 63% of resolved cases
63%
Career Allow Rate
24 granted / 38 resolved
+5.2% vs TC avg
Strong +61% interview lift
Without
With
+61.1%
Interview Lift
resolved cases with interview
Typical timeline
3y 0m
Avg Prosecution
10 currently pending
Career history
48
Total Applications
across all art units

Statute-Specific Performance

§101
8.3%
-31.7% vs TC avg
§103
65.5%
+25.5% vs TC avg
§102
6.1%
-33.9% vs TC avg
§112
20.1%
-19.9% vs TC avg
Black line = Tech Center average estimate • Based on career data from 38 resolved cases

Office Action

§103
DETAILED ACTION Notice of Pre-AIA or AIA Status 1. 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 2. 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 March 09, 2026 has been entered. Response to Amendment 3. Claims 1, 9, 11, 19 and 20 have been amended. Claims 1-3, 8-13 and 18-28 are presented for examination. Response to Arguments 4. Applicant’s arguments, see pages 9-12, filed March 02, 202, with respect to claims 1-3, 8-13 and 18-20, have been considered but they are not persuasive. 5. With respect to claims 1, 11 and 20, applicant stated that Klein (US2020/0097587 A1) does not disclose or suggest one or more locals calls from one or more application clients much less receiving, by way of an offline interface provided as part of a disconnected database in the absence of network communication, one or more locals calls from one or more application clients, wherein the offline interface, the disconnected database, and the application clients are executing on a same computing device, as recited by the pending claims. In particular, Klein is silent regarding the claimed local calls being calls made from an application client running on the same computing device as the disconnected database data structure as recited by the pending claims. Examiner’s Response: The examiner respectfully disagrees. Klein is not silent regarding the claimed local calls being calls made from an application client running on the same computing device as the disconnected database as recited by claims 1, 11 and 20. Noted that in para. 0041 and 0042, Klein discloses a client system and a database system. The client system includes an application. In para 0020, Klein further discloses that this database may be local to a particular machine or computing system. Therefore, Klein’s database maybe a local database that resides on a computer device rather than a remote server. In para, 0041, Klein also discloses that client system and database system may be part of a common computer system and may operate on common computing components. Therefore, an application and the database may coexist on the same computing device. As indicated in paras. 0046, 0048, 0073 and 0075, an application takes a user input and process it to produce a dynamic query. The application also sends the query to the database system. In paras. 0067, Klein indicated that the dynamic query is provided to the database system via an API. Because the application and the local database runs on the same computing device, queries sent from the application to the local database are local calls. Therefore, calls made from the application to the local database are local calls made by an applicant running on the same computing device as the local database (e.g., the disconnected database). Accordingly, Klein teaches receiving, by way of an offline interface for accessing a disconnected database, one or more locals calls from one or more application clients, wherein the offline interface, the disconnected database, and the application clients are disposed upon a computing device; (Noted that indicates what the cited art does not teach.) {Klein [Para. 0020] “Database can be local to a particular machine or computing system.” [Para. 0041] “The client system 210 and the database system 214 may be part of a common computing system, including being operated on common computing components.” [Para. 0067] “The user input 310 and dynamic query shell can be provided to the database system, such as via an API or RFC.” [Para. 0073] “The client system 504 can take user input 520 and process it, in a process 522, to produce a dynamic query 524.” [Para. 0075] “The dynamic query 524 is also sent from the client system 504 to the database system 508.” [Para. 0046] “If the user input checks 238 pass, the user input 230 can be added to the dynamic SQL statement 222. The dynamic SQL statement 222 can then be sent to the database system 214 for execution.” [Para. 0048] “Once the user input 230 has been escaped, it can be used to construct an executable version of the dynamic SQL statement 222 that is then sent to the database system 214 for execution.”} 6. With respect to claims 1, 11 and 20, applicant further stated that Lisac (US 2020/0389532 A1) does not disclose or suggest an offline interface provided as part of a disconnected database in the absence of network communication, one or more locals calls from one or more application clients, wherein the offline interface, the disconnected database, and the application clients are executing on a same computing device as recited by claims 1, 11 and 20. In particular, applicant stated that the sync application programming interface (API) of Lisac accesses information in a hosted database of a cloud server in order to generate the payload (e.g., the disconnected database) to be cached but is not the offline interface for accessing the disconnected database as recited by the pending claims. Examiner’s Response: The examiner respectfully disagrees. Lisac teaches two APIs, a sync API and a simulation API. The simulation API enables a client application to establish a simulated database session with a local database, allowing offline data access. Simulation API is the offline interface for accessing the disconnected database as recited by claims 1, 11 and 20. Lisac teaches receiving, by way of an offline interface for accessing a disconnected database, one or more locals calls from one or more application clients, wherein the offline interface, the disconnected database, and the application clients are disposed upon a computing device; {Lisac [Para. 0048] “At block 535, when client device 310 is operating in offline mode, responsive to a user request received from the application at application layer 315 on client device 310 to access data in offline mode, communication interface 321 may execute a call to simulation API 329 to access cached data on local database 335 and conduct a simulated database session between the application and local database 335.” [Para. 0007] “Transmitting,…the payload from the hosted client instance to the mobile device for caching onto a local database on the mobile device for access by the client application in the offline mode; wherein data from the cached subset of service management incident data stored on the local database of the mobile device is accessible by the mobile device in a simulated database session in the offline mode between the client application and the local database on the mobile device via a simulation API of the local database.”} Also see para. 0021, 0035 and 0036 for more information about the simulation API. Noted that the payload generated by the syn API is stored on a local database in a mobile device. In offline mode, the client application on the mobile device accesses data on the local database by using the local database's simulation API. When in offline mode, the application sends a request to the simulation API to access local database data and conduct a simulated database session (see para. 0048). The local database is a disconnected database. The simulation API, the local database (e.g., the disconnected database) and the client application are running on the same mobile device. Thus, requests sent by the client applicant are local calls. Therefore, simulation API is the offline interface for accessing the disconnected database as recited by claims 1, 11 and 20. Therefore, the combination of Klein and Lisac implements an offline interface for accessing a disconnected database as recited by the pending claims 1, 11 and 20. 7. Applicant’s arguments, with respect to dependent claims 2, 3, 8-10, 12, 13, 18, 19 and 21-28 have been considered but are not persuasive. Applicant is redirected to the examiner’s responses to arguments with respect to claim 1, above. Claim Objections 8. Claims 1, 11 and 20 are objected to because of the following informalities: In claims 1 and 20, “….a plurality of locals calls from one or more application clients, wherein the offline interface, the disconnected database, and the application clients are executing on a same computing device;” should read “…a plurality of local calls from one or more application clients, wherein the offline interface, the disconnected database and the application clients are executing on a same computing device;”. The comma after “the disconnected database” should be deleted. In claim 11, “…wherein the offline interface, the disconnected database, and the application clients are executing on a same computing device;” should read “…wherein the offline interface, the disconnected database and the application clients are executing on a same computing device;”. The comma after “the disconnected database” should be deleted. Appropriate correction is required. Claim Rejections - 35 USC § 103 9. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. 10. 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. 11. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows: 1. Determining the scope and contents of the prior art. 2. Ascertaining the differences between the prior art and the claims at issue. 3. Resolving the level of ordinary skill in the pertinent art. 4. Considering objective evidence present in the application indicating obviousness or nonobviousness. 12. Claim 1, 8, 9, 11, 18, 19, 20, 21, 24, 25 and 28 are rejected under 35 U.S.C. § 103 as being unpatentable over Klein (US 2020/0097587 A1), hereafter Klein, in view of Lisac et al. (US 2020/0389532 A1), hereafter Lisac, and further in view of Singh et al. (US 2020/0404007 A1), hereafter Singh. Noted that indicates what the cited art does not teach. Regarding claim 1, Klein teaches a method, comprising: {Klein [Para. 0006] “A method is provided for detecting malicious database activity, such as a SQL injection attempt.”} receiving, by way of an offline interface for accessing a disconnected database, one or more locals calls from one or more application clients, wherein the offline interface, the disconnected database, and the application clients are disposed upon a computing device; {Klein [Para. 0020] “Database can be local to a particular machine or computing system.” [Para. 0041] “The client system 210 and the database system 214 may be part of a common computing system, including being operated on common computing components.” [Para. 0067] “The user input 310 and dynamic query shell can be provided to the database system, such as via an API or RFC.” [Para. 0073] “The client system 504 can take user input 520 and process it, in a process 522, to produce a dynamic query 524.” [Para. 0075] “The dynamic query 524 is also sent from the client system 504 to the database system 508.” [Para. 0046] “If the user input checks 238 pass, the user input 230 can be added to the dynamic SQL statement 222. The dynamic SQL statement 222 can then be sent to the database system 214 for execution.”} Also see paras. 0048 in Klein. Klein discloses a client system and a database system (see para. 0041 and 0042). The client system includes an application. In para 0020, Klein further discloses that this database may be local to a particular machine or computing system. Therefore, Klein’s database maybe a local database that resides on a computer device rather than a remote server. In para, 0041, Klein also discloses that client system and database system may be part of a common computer system and may operate on common computing components. Therefore, an application and the database may coexist on the same computing device. As indicated in paras. 0046, 0048, 0073 and 0075, an application takes a user input and process it to produce a dynamic query. The application also sends the query to the database system. In paras. 0067, Klein indicated that the dynamic query is provided to the database system via an API. Because the application and the local database runs on the same computing device, queries sent from the application to the local database are local calls. Therefore, calls made from the application to the local database are local calls made by an applicant running on the same computing device as the local database (e.g., the disconnected database). generating, via a data protection machine learning model, predictions regarding the plurality of local calls, wherein the data protection machine learning model has been trained to predict whether a call is a malicious call or a non-malicious call calls; {Klein [Para. 0073] “The client system 504 can take user input 520 and process it, in a process 522, to produce a dynamic query 524. The dynamic query 524 is hashed to provide a query hash value 526, which is provided to the injection detection component 510.” [Para. 0075] “The dynamic query 524 is also sent from the client system 504 to the database system 508.” [Para. 0077] “At 546, the injection detection component 510 can process the statistics 534 received from the database system 508, in some cases, to extract or format the information, to provide formatted information 550.” [Para. 0078] “The machine learning classifier 554 uses the formatted information 550, and the information from the call stack 514, to provide a result 556. Typically, the result 556 is a label of “yes” or “no,” “good,” or “bad,” “suspicious,” or “benign,” or a similar binary classification.” [Para. 0036] “A machine learning technique is trained to recognize “normal” database behavior. Queries that deviate from “normal” operation can be flagged as potential SQL injection attempts.”} Klein’s system applies an ML classifier to a dynamic query to determine whether it represents an attempted query language injection. and based on the predictions from the data protection machine learning model, blocking a local call of the plurality of local calls that is predicted to be malicious from accessing the disconnected database, and allowing a local call of the plurality of local calls that is predicted to be non-malicious to access the disconnected database, {Klein [Para. 0078] “The result 556 can be provided to the database system 508, where, at 558, the database system can proceed to forward the query to a query executor 562 if the query is benign. If the query is suspicious, the database system 508 provides a notification to a security component 566 as a result of the determining at 558.” [Para. 0081] “At 616, if the result indicates that the query is benign, user input associated with the query is optionally escaped at 618. The user input is used at 620 to build a dynamic query 622, which is executed at 624 to provide query results 628. The query results 624 are then returned, such as to an application of a client system, at 630. In some cases, such as in the scenario 500, the dynamic query 620 may be already been formed prior to analysis by the machine learning component at 604. In this event, the operations 600 can proceed from 616 to 624.” [Para. 0083] “In response to determining a potentially malicious query at 616, query execution can be terminated at 636.” [Para. 0084] “If malicious activity is detected or suggested at 616, an application, database session, or both, associated with the source of the potentially malicious query can be terminated at 644.”} Also see paras. 0079 and 0080 in Klein. wherein blocking a local call that is predicted to be malicious from accessing the disconnected database comprises quarantining the application client. {Klein [Para. 0084] “If malicious activity is detected or suggested at 616, an application, database session, or both, associated with the source of the potentially malicious query can be terminated at 644.”[Para. 0085] “For example, if the malicious activity is occurring in association with an application process, that application process can be terminated, or a database can block further requests associated with that process.”} However, Klein does not teach receiving, by way of an offline interface provided as part of a disconnected database in the absence of network communication, a plurality of locals calls from one or more application clients, wherein the offline interface, the disconnected database, and the application clients are executing on a same computing device; wherein blocking a local call that is predicted to be malicious from accessing the disconnected database comprises quarantining the application client. However, Lisac teaches receiving, by way of an offline interface provided as part of a disconnected database in the absence of network communication, a plurality of locals calls from one or more application clients, wherein the offline interface, the disconnected database, and the application clients are executing on a same computing device; {Lisac [Para. 0048] “At block 535, when client device 310 is operating in offline mode, responsive to a user request received from the application at application layer 315 on client device 310 to access data in offline mode, communication interface 321 may execute a call to simulation API 329 to access cached data on local database 335 and conduct a simulated database session between the application and local database 335.” [Para. 0007] “Transmitting,…the payload from the hosted client instance to the mobile device for caching onto a local database on the mobile device for access by the client application in the offline mode; wherein data from the cached subset of service management incident data stored on the local database of the mobile device is accessible by the mobile device in a simulated database session in the offline mode between the client application and the local database on the mobile device via a simulation API of the local database.”} Also see para. 0021, 0035 and 0036 for more information about the simulation API. Lisac teaches two APIs, a sync API and a simulation API. Noted that payload generated by the syn API is stored on a local database in a mobile device. In offline mode, the client application on the mobile device accesses data on the local database by using the local database's simulation API. When in offline mode, the application sends a request to the simulation API to access local database data and conduct a simulated database session (see para. 0048). The local database is a disconnected database. The simulation API, the local database (e.g., the disconnected database) and the client application are running on the same mobile device. Thus, requests sent by the client applicant are local calls. Therefore, simulation API is the offline interface for accessing the disconnected database as recited by claim 1. Lisac is analogous art because each of Klein and Lisac pertains to processing application-to-database operations. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Klein to include Lisac’s teaching of the limitations of claim 1, listed above. Doing so would allow an application to “remain data source agnostic” (Lisac, para. 0021). However, Lisac also does not teach quarantining the applicant client. However, Singh teaches quarantining the applicant client. {Singh [Para. 0039] “AE-CLT filtering tracks user-to-machine, machine-to-machine, and/or user-to-user communications within the enterprise. Machine-to-machine communications can refer to interactions directed by an application or other programming on a machine to interact with another machine, such as web server to application, application to database, and other backend operations.” [Para. 0050] “A system administrator can define policies that are specific to a particular enterprise that define the manner in which the threat detection and response system should respond to potential threats. Various enforcement actions can be directed by the collector server system in response to the policies including immediately quarantining a machine, process, application, and/or user associated with a detected security threat.”} Singh is analogous art because each of Klein, Lisac and Singh pertains to processing application-to-database operations. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Klein and Lisac to include Singh’s teaching of quarantining an application client. One could use the combination to implement features of claim 1. Doing so “can detect injection exploits” (Singh, para. 0329). Claim 8: Regarding claim 8, Klein, Lisac and Singh teach the elements of claim 1 as stated. However, Klein and Singh do not teach wherein the disconnected database initially includes data from a network-accessible database server. However, Lisac teaches wherein the disconnected database initially includes data from a network-accessible database server. {Lisac [Para. 0034] “Sync API 364 includes a set of REST APIs that are optimized for synchronizing batch record data from database 370 onto local database 335 of client device 310. Batch record data may correspond to a subset of the field service management data stored on database 370. Sync API 364 provides efficient server side logic to generate a payload that is optimized for efficiency and that is transmitted to mobile device for use in offline mode. The optimization may include querying data by executing a batch request that triggers a background job for running multiple queries on database 370 and transmitting the resulting data in an optimized denormalized format for storage on local database 335 of client device 310.”} Also see para. 0021. Local database 335 of client device 310 includes a subset of the field service management data from database 370. Lisac is analogous art because each of Klein, Lisac and Singh pertains to processing application-to-database operations. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Klein and Singh to include Lisac’s teaching of a disconnected database that initially includes data from a network-accessible database server. Doing so would allow an application to “remain data source agnostic” (Lisac, para. 0021). Claim 9: Regarding claim 9, Klein, Lisac and Singh teach the elements of claim 1 as stated. However, Klein and Singh do not teach wherein the offline interface comprises an application programming interface (API) accessible only to applications executing on a same computing device as the disconnected database. However, Lisac teaches wherein providing the offline interface comprises an application programming interface (API) accessible only to applications executing on the same computing device as the disconnected database. {Lisac [Para. 0048] “At block 535, when client device 310 is operating in offline mode, responsive to a user request received from the application at application layer 315 on client device 310 to access data in offline mode, communication interface 321 may execute a call to simulation API 329 to access cached data on local database 335 and conduct a simulated database session between the application and local database 335.” [Para. 0021] “In the offline mode, the client application on the mobile device may conduct a simulated database session with the local database on the mobile device via a simulation API to access the cached subset of service management data.”} Also see paras. 0007, 0035 and 0036 in Lisac. Lisac is analogous art because each of Klein, Lisac and Singh pertains to processing application-to-database operations. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Klein and Singh to include Lisac’s teaching of an API that is accessible only to applications executing on the same computing device as the disconnected database. Doing so would allow an application to “remain data source agnostic” (Lisac, para. 0021). Claim 21: Regarding claim 21, Klein, Lisac and Singh teach the elements of claim 2 as stated. Klein further teaches wherein the data protection machine learning model has been trained with online interaction data to predict whether the calls are malicious calls or non- malicious calls. {Klein [Para. 0036] “A machine learning technique is trained to recognize “normal” database behavior. The application execution information for a particular query can be correlated with the database execution information for the query by obtaining hash values for queries submitted by the application and hash values for queries executed by a database system. A hash value of application database statement matching a hash value of a database statement to be executed on the database can indicate that the queries are the same, as so characteristics of the query can be correlated to train a classifier, or to detect a potential SQL injection attempt using a trained classifier.” [Para. 0076] “The injection detection component 510 can perform analogous actions for training data. For example, the injection detection component 510 can be allowed to “observe” queries for a period of time for training purposes. Once the injection detection component 510 is sufficiently trained, such as to recognize “normal” patterns, it can start to classify queries.”} Claim 24: Regarding claim 24, Klein teach the elements of claim 21 as outlined above. Klein further teaches wherein the online interaction data includes anomalous database interaction behavior. {Klein [Para. 0088] “At 720, the first version of the first dynamic query is parsed and tokenized to obtain a first set of tokens. The second version of the first dynamic query is parsed and tokenized at 724 to obtain a second set of tokens. The first and second sets of tokens are compared at 728. It is determined at 732 whether the first and second sets of tokens are equal. At 736, a training label is generated indicating whether the user input may be associated with a security violation. A machine learning component is trained at 740 with the user input and the training label to, at least in part, provide a trained classifier.”} Also see para. 0038 and 0058 -0066 in Klein for more information about the training process. Claims 11, 18, 19, 25 and 28: Regarding claims 11, 18, 19, 25 and 28, the claims are directed to a computer system that implements the method recited by claims 1, 8, 9, 21 and 24. Therefore, the rejection applied to claims 1, 8, 9, 21 and 24 also applies to claims 11, 18, 19, 25 and 28. Claims 1, 8, 9, 21 and 24 are rejected under the same rationale as claims 11, 18, 19, 25 and 28. Claims 11 further recites a system comprising: one or more processors; and a memory coupled to the one or more processors, wherein the memory is configured to provide the one or more processors with instructions which when executed cause the one or more processors to perform the operations recited by claim 1. {Klein [Para. 0092] “The computing system 1000 includes one or more processing units 1010, 1015 and memory 1020, 1025. A processing unit can be a general-purpose CPU,… or any other type of processor. The memory 1020, 1025 stores software 1080 implementing one or more innovations described herein, in the form of computer-executable instructions suitable for execution by the processing unit(s) 1010, 1015.”} Claim 20: Regarding claim 20, the claim is directed to a computer readable storage medium containing instructions for performing the operations recited by claim 1. Therefore, the rejection applied to claim 1 also applies to claim 20. Claim 1 is rejected under the same rationale as claim 20. Claim 20 further recites a computer program product, the computer program product being embodied in a non- transitory computer readable storage medium and comprising computer instructions for implementing the operations recited by claim 1. {Klein [Para. 0104] “Disclosed methods can be implemented as computer-executable instructions or a computer program product stored on one or more computer-readable storage media, such as tangible, non-transitory computer-readable storage media, and executed on a computing device.”} 13. Claims 2, 3, 12 and 13 are rejected under 35 U.S.C. § 103 as being unpatentable over Klein, Lisac and Singh as applied to claims 1 and 11, and further in view of Tang et al., (Detection of SQL Injection Based on Artificial Neural Network), hereafter Tang (https://doi.org/10.1016/j.knosys.2020.105528). Regarding claim 2, Klein, Lisac and Singh teach the elements of claim 1 as stated. However, Klein, Lisac and Singh do not teach wherein the data protection machine learning model has been trained to predict whether the calls are malicious or non-malicious calls using known malicious attacks. However, Tang teaches wherein the data protection machine learning model has been trained to predict whether the calls are malicious or non-malicious calls using known malicious attacks. {Tang [Sect. 1, para. 4] “This paper presents a simple and efficient method for SQL injection detection based on artificial neural network, it consists of three parts: data preprocessing, feature extraction and model training. Firstly, 8 types of relevant features are extracted by analyzing a large amount of SQL injection data, and then a great many actual data is used to train the neural network model.” [Sect. 4.3] “ The required malicious data is from the parameter payload of SQL injection provided by the open source website GitHub, and the normal data is from the ISP (Internet Service Provider). The malicious data of training sets and test sets are distributed in a ratio of 7:3. The normal data and malicious data in the test sets are 1:1. We have 7095 pieces of malicious data and 76960 pieces of normal data in the training set, and 3040 pieces of both normal data and malicious data in the test set.”} Tang’s method uses SQL injection data to train a neural network model that detects SQL injection attacks. Tang is analogous art because each of Klein, Lisac, Singh and Tang pertains to implementing procedures for protecting enterprise data. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Klein, Lisac and Singh to include Tang’s teaching of training a data protection ML model that predicts whether calls are malicious or non-malicious calls using known malicious attacks. Doing so “can effectively and comprehensively detect SQL injection attacks” (Tang, sect. 2.3, para. 2). Claim 3: Regarding claim 3, Klein, Lisac and Singh teach the elements of claim 1 as stated. However, Klein, Lisac and Singh do not teach wherein the data protection machine learning model has been trained to predict whether the calls are malicious calls or non-malicious calls using interactions corresponding to structure query language (SQL) injection attacks, denial-of-service (DOS) attacks, data modification attacks, or data theft attacks. However, Tang teaches wherein the data protection machine learning model has been trained to predict whether the calls are malicious calls or non-malicious calls using interactions corresponding to structure query language (SQL) injection attacks, denial-of-service (DOS) attacks, data modification attacks, or data theft attacks. {Tang [Sect. 4.3] “ The required malicious data is from the parameter payload of SQL injection provided by the open source website GitHub, and the normal data is from the ISP. The malicious data of training sets and test sets are distributed in a ratio of 7:3; The normal data and malicious data in the test sets are 1:1. We have 7095 pieces of malicious data and 76960 pieces of normal data in the training set, and 3040 pieces of both normal data and malicious data in the test set.”} Tang trains a neural network model for detecting a SQL injection attack, and the training data includes SQL injection data. Tang is analogous art because each of Klein, Lisac Singh and Tang pertains to implementing procedures for protecting enterprise data. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Klein, Lisac and Singh to include Tang’s teaching of training a data protection machine learning model using interactions corresponding to structure query language (SQL) injection attacks. Doing so “can effectively and comprehensively detect SQL injection attacks” (Tang, sect. 2.3, para. 2). Claims 12 and 13: Regarding claims 12 and 13, the claims are directed to a computer system that implements the method recited by claims 2 and 3. Therefore, the rejection applied to claims 2 and 3 also applies to claims 12 and 13. Claims 2 and 3 are rejected under the same rationale as claims 2 and 3. 14. Claim 10 is rejected under 35 U.S.C. § 103 as being unpatentable over Klein, Lisac and Singh as applied to claim 1, and further in view of Thapliyal et al. (US 2016/0057211 A1), hereafter Thapliyal. Regarding claim 10, Klein, Lisac and Singh teach the elements of claim 1 as stated. However, Klein, Lisac and Singh do not teach wherein application support for the offline interface is provided via a software development kit (SDK). However, Thapliyal teaches wherein application support for the offline interface is provided via a software development kit (SDK). {Thapliyal [Para. 0056] “The method and apparatus for auto-injecting support for offline access capabilities into a given JavaScript SDK is described. The mobile API’s generated as part of the SDK has transparent support for offline access. All data transfer via these APIs is cached locally in device storage. In case of no internet connection, the API server serves the data from the cache for read operations.” [Para. 0058] “An offline support injector 802 includes an offline mirror API creator 803, an API call signature cache 805, and a queue manager 807.” [Para. 0059] “For each of the publicly exported APIs in the input JavaScript SDK (commonJS), the offline mirror APO creator 802 creates supporting APIs for offline capabilities.”} Thapliyal is analogous art because each of Klein, Lisac, Singh and Thapliyal pertains to processing application-to-server communications. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Klein, Lisac and Singh to include Thapliyal’s teaching of providing application support for an offline interface via an SDK. Doing so would “enable the IT Developers to build robustness into their enterprise mobile apps, and improve overall user experience of their mobile apps” (Thapliyal, para. 0057). 15. Claims 22, 23, 26 and 27 are rejected under 35 U.S.C. § 103 as being unpatentable over Klein, Lisac and Singh as applied to claims 1, 21, 11 and 25, and further in view of Gaddam et al. (US 2021/0328969 A1), hereafter Gaddam. Regarding claim 22, Klein, Lisac and Singh teach the elements of claim 1 as stated. However, Klein, Lisac and Singh do not explicitly teaches wherein the online interaction data are based at least in part on a source property, a location context, a time context, one or more targeted data fields, or changes in connectivity. However, Gaddam teaches wherein the online interaction data are based at least in part on a source property, a location context, a time context, one or more targeted data fields, or changes in connectivity. {Gaddam [Para. 0093] “The database access requests may additionally comprise data or metadata, such as a timestamp, an identifier corresponding to the requesting entity, a location of origin (either geographical or digital, such as an IP address), a sequence number, checksum, source port, destination port, etc.” [Para. 0094] “These database access requests may include, for example, requests to query the database.” [Para. 0098] “The machine learning model may be trained using historical database access requests collected by the database server over the course of the requesting entity profile's existence.” [Para. 0065] “The feature vectors in feature store 110 may comprise database access requests corresponding to entity profiles. For example, a feature vector may comprise a query to read data file “secret_key” on Jun. 14, 2018, 2:53.32 P.M. from requesting entity “AG” originating from API “Android-8.” The feature vectors in feature store 110 may be used by database servers 112 and 114 to train machine learning models stored in model cache 108.”} Gaddam is analogous art because each of Klein, Lisac, Singh and Gaddam pertains to processing application-to-database operations. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Klein, Lisac and Singh to include Gaddam’s teaching of the limitations of claim 22, listed above. Doing so would “accurately detect fraudulent database access requests” (Gaddam, para. 0014). Claim 23: Regarding claim 23, Klein teaches the elements of claim 21 as outlined above. However, Klein, Lisac and Singh do not teach wherein using the online interaction data to train the data protection machine learning model includes extracting machine learning features from the online interaction data, wherein the machine learning features correspond to one or more source properties of the online interaction data, one or more destination properties of the online interaction data, or one or more database queries of the online interaction data. Gaddam further teaches wherein using the online interaction data to train the data protection machine learning model includes extracting machine learning features from the online interaction data, {Gaddam [Para. 0065] “The feature vectors in feature store 110 may comprise database access requests corresponding to entity profiles. For example, a feature vector may comprise a query to read data file “secret_key” on Jun. 14, 2018, 2:53.32 P.M. from requesting entity “AG” originating from API “Android-8.” Feature vectors stored in feature store 110 may have corresponding labels, such as normal or anomalous. In some embodiments, feature vectors stored in feature store 110 may correspond to access sequences comprising a number of ordered database access requests. The feature vectors in feature store 110 may be used by database servers 112 and 114 to train machine learning models stored in model cache 108.” [Para. 0063] “The machine learning models stored in model cache 108 may evaluate requesting entity behavior based on database access requests and request sequences, and output an anomaly score that indicates whether the database access requests are normal or anomalous.”} Gaddam generates feature vectors from database access requests, and used them to train a machine learning model for detecting an anomalous database access request. Gaddam’s models are trained to detect attack sequence (see para. 0109). wherein the machine learning features correspond to one or more source properties of the online interaction data, one or more destination properties of the online interaction data, or one or more database queries of the online interaction data. {Gaddam [Para. 0093] “The database access requests may additionally comprise data or metadata, such as a timestamp, an identifier corresponding to the requesting entity, a location of origin (either geographical or digital, such as an IP address), a sequence number, checksum, source port, destination port, etc.” [Para. 0094] “These database access requests may include, for example, requests to query the database. For a resource database implemented as a relational database, this may include SQL or SQL-like statements such as “SELECT ‘keys’ FROM ‘secrets,’” a request to retrieve the ‘keys’ records from the ‘secrets’ table.” [Para. 0098] “At step S408, the database server can determine a machine learning model corresponding to the requesting entity profile. The machine learning model may be trained using historical database access requests collected by the database server over the course of the requesting entity profile's existence. These historical database access requests may be stored as feature vectors in a feature store (such as feature store 110 from FIG. 1).”} Gaddam generates feature vectors from database access requests. These requests include requests to query a database (see paras. 0065 and 0094). Additionally, Gaddam also generates feature vectors that correspond to anomalous database interaction behaviors, and uses them to train ML models for detecting anomalous database access requests (see para. 0065). Gaddam is analogous art because each of Klein, Lisac, Singh and Gaddam pertains to the processing of application-to-database operations. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Klein, Lisac and Singh to include Gaddam’s teaching of the limitations of claim 23, listed above. Doing so would “accurately detect fraudulent database access requests” (Gaddam, para. 0014). Claims 26 and 27: Regarding claims 26 and 27, the claims are directed to a computer system that implements the method recited by claims 22 and 23. Therefore, the rejection applied to claims 22 and 23 also applies to claims 26 and 27. Claims 22 and 23 are rejected under the same rationale as claims 26 and 27. Conclusion 16. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Balasubrahmanian et al. (US 2018/0357304 A1) discloses a system for executing queries received at a client application on a local copy of objects obtained from a remote datastore. Ben-Natan (US 7,426,512 B1) discloses a method for monitoring access to a protected database resource. A data security device intercepts both local and remote access attempts to the database resource and monitors all database access attempts for auditing, logging, and security analysis. 17. Any inquiry concerning this communication or earlier communications from the examiner should be directed to BIN QING ZHENG whose telephone number is (703)756-1535. The examiner can normally be reached on M-F 9:30 am - 05:30 pm. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Philip J. Chea can be reached on 571-272-3951. 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. /BIN QING ZHENG/ Examiner, Art Unit 2499 /PHILIP J CHEA/Supervisory Patent Examiner, Art Unit 2499
Read full office action

Prosecution Timeline

Oct 25, 2023
Application Filed
May 28, 2025
Non-Final Rejection — §103
Aug 14, 2025
Applicant Interview (Telephonic)
Aug 14, 2025
Examiner Interview Summary
Aug 19, 2025
Response Filed
Nov 12, 2025
Final Rejection — §103
Feb 13, 2026
Response after Non-Final Action
Mar 09, 2026
Request for Continued Examination
Mar 18, 2026
Response after Non-Final Action
Mar 31, 2026
Non-Final Rejection — §103
Apr 16, 2026
Interview Requested

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12602488
Identifying Security-Relevant Commits Through Architectural Context
2y 5m to grant Granted Apr 14, 2026
Patent 12579249
SYSTEMS AND METHODS FOR AUTHENTICATION
2y 5m to grant Granted Mar 17, 2026
Patent 12566863
VISUALIZATION OF SECURITY VULNERABILITIES
2y 5m to grant Granted Mar 03, 2026
Patent 12561474
INTERFACE INVOCATION REQUEST PROCESSING METHODS AND APPARATUSES
2y 5m to grant Granted Feb 24, 2026
Patent 12524523
CYBER THREAT INFORMATION PROCESSING APPARATUS, CYBER THREAT INFORMATION PROCESSING METHOD, AND STORAGE MEDIUM STORING CYBER THREAT INFORMATION PROCESSING PROGRAM
2y 5m to grant Granted Jan 13, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

3-4
Expected OA Rounds
63%
Grant Probability
99%
With Interview (+61.1%)
3y 0m
Median Time to Grant
High
PTA Risk
Based on 38 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month