DETAILED ACTION
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 .
Status of Claims
In response to communications filed on 16 July 2026, claims 1-24 are presently pending in the application, of which, claims 1 and 8 are presented in independent form.
Response to Remarks/Arguments
All objections and/or rejections issued in the previous Office Action, mailed 19 March 2026, have been withdrawn, unless otherwise noted in this Office Action.
Applicant's arguments filed 16 July 2026 have been fully considered but they are not persuasive. Applicant’s arguments are directed to amended features and have been incorporated into the rejection below.
No other arguments were presented by the Applicant.
Claim Rejections - 35 USC § 103
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 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.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 103 that form the basis for the rejections under this section made 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-14 are rejected under 35 U.S.C. 103 as being unpatentable by Gupta, Satya (U.S. 2016/0337400 and known hereinafter as Gupta) in view of Kinder, Ross, et al (U.S. 2018/0152480 and known hereinafter as Kinder).
As per claim 1, Gupta teaches a method comprising:
accessing a compromised provider object stored in a provider object database (e.g. Gupta, see paragraphs [0034-0035], which discloses a malicious actor may use a database query injection attack, such as a SQL injection attack, where once the altered SQL query is executed, the malicious actor can access database records for many customers, where customer records indicate a provider object.);
extracting data from a compromised provider object (e.g. Gupta, see paragraph [0041], which discloses the instrumentation engine extracts database query information for one or more database queries.);
building an injection query using the extracted data (e.g. Gupta, see paragraph [0041], which discloses insert the extracted database query information into context data sent to one or more threads of the web server, where the information may be checked for a potential database injection attack.);
adding a cross-reference element to the injection query, the cross-reference element including a compromised provider object identifier for the compromised provider object (e.g. Gupta, see paragraphs [0041-0042], which discloses the instrumentation engine may send some or all of the captured database query data to the analysis engine, which uses the matched information to perform deep context aware searches for detecting a database injection attack, where for example, if the database activities comprise a database request querying tables of the database, the analysis engine may match the user and session information (e.g. cross-reference elements) to corresponding information specified in the query.);
transmitting the injection query to a provider object creation module (e.g. Gupta, see paragraphs [0041-0042], which discloses the instrumentation engine may send some or all of the captured database query data to the analysis engine, which uses the matched information to perform deep context aware searches for detecting a database injection attack, where for example, if the database activities comprise a database request querying tables of the database, the analysis engine may match the user and session information (e.g. cross-reference elements) to corresponding information specified in the query.);
initiating creation of a clean provider object using the extracted data and the cross- reference element (e.g. Gupta, see paragraph [0075], which discloses a remedial action (e.g. clean provider object) to thwart an injection attack is to logout the offending user by removing his/her session ID from the database. Release the sockets associated with the threads on which the thread has appeared; terminate the thread on which a threat has appeared, and/or blacklist the user that caused the threat.);
storing the clean provider object in the provider object database (e.g. Gupta, see paragraphs [0041-0043], which discloses creating a golden table that includes verified and clean URLs and stored as a table and referenced to determine a database injection attack.);
notifying third party systems of a provider object identifier for the created clean provider object (e.g. Gupta, see paragraph [0077], which discloses the analysis engine lets the security monitoring agent know which remedial action to carry out. The monitoring agent then performs the action associated with the remedial action on the application and then sends a confirmation message back to the analysis engine. See further paragraph [0051], which discloses terminate the attacker session and record to alert security operations personnel.).
Gupta does not explicitly disclose forcing creation of the clean provider object by causing the provider object creation module to avoid merge/search operations that prevent creation of duplicate provider objects during standard provider object creation; thereby enabling the third party system to update records referencing the compromised provider object identifier to reference the clean provider object identifier; and deactivating the compromised provider object.
Kinder teaches forcing creation of the clean provider object (e.g. Kinder, see paragraph [0065], Figure 10, which discloses applying a selected repair to a detected security risk, where the repair is executed, the check is run again and information is displayed to confirm that the security risk was resolved.) by causing the provider object creation module to avoid merge/search operations that prevent creation of duplicate provider objects during standard provider object creation (e.g. Kinder, see paragraphs [0052-0053], which discloses a remediation plan that allows the for the system detect a risk, identify security risks, correct and/or reverse the security risk, and then transmit the information via a communication network to one or more systems.);
thereby enabling the third party system to update records referencing the compromised provider object identifier to reference the clean provider object identifier (e.g. Kinder, see paragraph [0053-0056], which discloses if the detected or identified security risk has been corrected or reversed, a change condition is determined indicating the remedial action has addressed the identified/detected risk. See additionally, Figure 6, which discloses permission setting to enable restricted access.); and
deactivating the compromised provider object (e.g. Kinder, see paragraph [0011-0018], which discloses templates may be used to implement security risk remediation where when in the protect mode, when a repair plan is selected, the object may be deactivated until the repair is completed.).
Gupta is directed to detection of SQL injection query. Kinder is directed to reversibly remediating a security risk. Both are analogous art because they are directed to injection query attacks and therefore it would have been obvious to one of ordinary skilled in the art at the time the invention was filed to modify the teachings of Gupta with the teachings of Kinder to include the claimed features with the motivation to improve injection queries.
As per claim 8, Gupta teaches an intermediation server comprising a non-transitory computer readable medium storing instructions which, when executed by a processor (e.g. Gupta, see Figure 7A, which discloses memory, processor, and network interface.) , cause the processor to:
accessing a compromised provider object stored in a provider object database (e.g. Gupta, see paragraphs [0034-0035], which discloses a malicious actor may use a database query injection attack, such as a SQL injection attack, where once the altered SQL query is executed, the malicious actor can access database records for many customers, where customer records indicate a provider object.);
extracting data from a compromised provider object (e.g. Gupta, see paragraph [0041], which discloses the instrumentation engine extracts database query information for one or more database queries.);
building an injection query using the extracted data (e.g. Gupta, see paragraph [0041], which discloses insert the extracted database query information into context data sent to one or more threads of the web server, where the information may be checked for a potential database injection attack.);
adding a cross-reference element to the injection query, the cross-reference element including a compromised provider object identifier for the compromised provider object (e.g. Gupta, see paragraphs [0041-0042], which discloses the instrumentation engine may send some or all of the captured database query data to the analysis engine, which uses the matched information to perform deep context aware searches for detecting a database injection attack, where for example, if the database activities comprise a database request querying tables of the database, the analysis engine may match the user and session information (e.g. cross-reference elements) to corresponding information specified in the query.);
transmitting the injection query to a provider object creation module (e.g. Gupta, see paragraphs [0041-0042], which discloses the instrumentation engine may send some or all of the captured database query data to the analysis engine, which uses the matched information to perform deep context aware searches for detecting a database injection attack, where for example, if the database activities comprise a database request querying tables of the database, the analysis engine may match the user and session information (e.g. cross-reference elements) to corresponding information specified in the query.);
initiating creation of a clean provider object using the extracted data and the cross- reference element (e.g. Gupta, see paragraph [0075], which discloses a remedial action (e.g. clean provider object) to thwart an injection attack is to logout the offending user by removing his/her session ID from the database. Release the sockets associated with the threads on which the thread has appeared; terminate the thread on which a threat has appeared, and/or blacklist the user that caused the threat.);
storing the clean provider object in the provider object database (e.g. Gupta, see paragraphs [0041-0043], which discloses creating a golden table that includes verified and clean URLs and stored as a table and referenced to determine a database injection attack.);
notifying third party systems of a provider object identifier for the created clean provider object (e.g. Gupta, see paragraph [0077], which discloses the analysis engine lets the security monitoring agent know which remedial action to carry out. The monitoring agent then performs the action associated with the remedial action on the application and then sends a confirmation message back to the analysis engine. See further paragraph [0051], which discloses terminate the attacker session and record to alert security operations personnel.).
Gupta does not explicitly disclose forcing creation of the clean provider object by causing the provider object creation module to avoid merge/search operations that prevent creation of duplicate provider objects during standard provider object creation; thereby enabling the third party system to update records referencing the compromised provider object identifier to reference the clean provider object identifier; and deactivating the compromised provider object.
Kinder teaches forcing creation of the clean provider object (e.g. Kinder, see paragraph [0065], Figure 10, which discloses applying a selected repair to a detected security risk, where the repair is executed, the check is run again and information is displayed to confirm that the security risk was resolved.) by causing the provider object creation module to avoid merge/search operations that prevent creation of duplicate provider objects during standard provider object creation (e.g. Kinder, see paragraphs [0052-0053], which discloses a remediation plan that allows the for the system detect a risk, identify security risks, correct and/or reverse the security risk, and then transmit the information via a communication network to one or more systems.);
thereby enabling the third party system to update records referencing the compromised provider object identifier to reference the clean provider object identifier (e.g. Kinder, see paragraph [0053-0056], which discloses if the detected or identified security risk has been corrected or reversed, a change condition is determined indicating the remedial action has addressed the identified/detected risk. See additionally, Figure 6, which discloses permission setting to enable restricted access.); and
deactivating the compromised provider object (e.g. Kinder, see paragraph [0011-0018], which discloses templates may be used to implement security risk remediation where when in the protect mode, when a repair plan is selected, the object may be deactivated until the repair is completed.).
Gupta is directed to detection of SQL injection query. Kinder is directed to reversibly remediating a security risk. Both are analogous art because they are directed to injection query attacks and therefore it would have been obvious to one of ordinary skilled in the art at the time the invention was filed to modify the teachings of Gupta with the teachings of Kinder to include the claimed features with the motivation to improve injection queries.
As per claims 2 and 9, the modified teachings of Gupta and Kinder teaches the method of claim 1 and the intermediation server of claim 8, respectively, wherein before extracting the data the provider objects are filtered to identify provider objects that are eligible to be duplicated (e.g. Gupta, see paragraphs [0054, 0062], which discloses the dynamically capturing and parsing database queries, where the parsed queries may be sent to a CMS to be replicated (e.g. duplicated) using a replicator interface, where the CMS makes a determination of whether the valid request needs to be extracted.).
As per claims 3 and 10, the modified teachings of Gupta and Kinder teaches the method of claim 1 and the intermediation server of claim 8, respectively, wherein building the injection query comprises converting at least some of the data from a format-specific format to a standard format (e.g. Gupta, see paragraph [0047], which discloses the analysis engine communicates with a validation engine to declare an injection attack, where the analysis engine analyzes context data that maps extracted database information from a server and determines the format or content of the expression parameters.); and
adding the data to the injection query in the standard format (e.g. Gupta, see paragraph [0047], which discloses the analysis engine then adds the triggered database queries into a number of expressions and outputs the database queries.).
As per claims 4 and 11, the modified teachings of Gupta and Kinder teaches the method of claim 1 and the intermediation server of claim 8, respectively wherein building the injection query comprises adding at least some of the data to the injection query without converting the format of the data (e.g. Gupta, see paragraphs [0055-0056], which discloses the instrumentation engine that may first extract the corresponding data types for the expression parameters, which then adds the expression parameters and then captures the database queries triggered from the attack.).
As per claims 5 and 12, the modified teachings of Gupta and Kinder teaches the method of claim 1 and the intermediation server of claim 8, respectively, wherein the injection query includes a replicated use case to indicate that the requested provider object is going to be a duplicate of a compromised provider object (e.g. Gupta, see paragraphs [0054, 0062], which discloses the dynamically capturing and parsing database queries, where the parsed queries may be sent to a CMS to be replicated (e.g. duplicated) using a replicator interface, where the CMS makes a determination of whether the valid request needs to be extracted.).
As per claims 6 and 13, the modified teachings of Gupta and Kinder teaches the method of claim 1 and the intermediation server of claim 8, respectively, wherein the third party systems are notified that the provider object is a clean provider object by modifying a header in a communication protocol used to communicate the message (e.g. Gupta, see paragraph [0077], which discloses the analysis engine lets the security monitoring agent know which remedial action to carry out. The monitoring agent then performs the action associated with the remedial action on the application and then sends a confirmation message back to the analysis engine. See further paragraph [0051], which discloses terminate the attacker session and record to alert security operations personnel.).
As per claims 7 and 14, the modified teachings of Gupta and Kinder teaches the method of claim 1 and the intermediation server of claim 8, respectively, wherein deactivating the compromised provider object comprises at least one of:
making the compromised provider object read only (e.g. Kinder, see paragraph [0053-0056], which discloses if the detected or identified security risk has been corrected or reversed, a change condition is determined indicating the remedial action has addressed the identified/detected risk. See additionally, Figure 6, which discloses permission setting to enable the object to be read only.);
restricting access to the compromised provider object (e.g. Kinder, see paragraph [0053-0056], which discloses if the detected or identified security risk has been corrected or reversed, a change condition is determined indicating the remedial action has addressed the identified/detected risk. See additionally, Figure 6, which discloses permission setting to enable restricted access.); and
password protecting the compromised provider object (e.g. Kinder, see Figure 6, which discloses permission settings and protected settings that limits the object.).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure. See attached PTO-892 that includes additional prior art of record describing the general state of the art in which the invention is directed to.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FARHAN M SYED whose telephone number is (571)272-7191. The examiner can normally be reached M-F 8:30AM-5:30PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Apu Mofiz can be reached at 571-272-4080. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/FARHAN M SYED/Primary Examiner, Art Unit 2161 September 10, 2026
Prosecution Insights