DETAILED ACTION
A response was received on 02 January 2026. By this response, Claims 1, 2, 4, 6-10, 12-15, 17, 19, and 20 have been amended. No claims have been added or canceled. Claims 1-20 are currently pending in the present application.
The amendments to the specification were not fully compliant with 37 CFR 1.121 and 1.125 as detailed in the notice mailed 05 May 2026. A response to the notice of non-compliant amendment was received on 26 May 2026.
Response to Arguments
Applicant's arguments filed 02 January 2026 have been fully considered but they are not persuasive.
Regarding the rejection of Claims 1-20 under 35 U.S.C. 112(a) for failure to comply with the enablement requirement, Applicant argues that paragraphs 0046-0047 and provisional application 63/196,458 provide sufficient disclosure of an algorithm to allow one of ordinary skill to make or use the invention without undue experimentation (see pages 8-9 of the 02 January 2026 response). First, it is noted that paragraphs 0046-0047 do not appear to include the quoted text, although it appears that these citations may be intended to refer to the paragraphs renumbered as 0048-0049. Although paragraph 0048 states that the server “can employ generically-defined artifacts (e.g. automations)”, this does not explain how the automations are to be generated. Further, although this refers to the above cited provisional application, there is no explanation in the present specification and no explanation in the present response of more specific citations of where the provisional application is alleged to provide support for this feature. Although the provisional application generally appears to discuss automation and artifacts, there does not appear to be any description in the provisional application of generating an automation based on an artifact as recited in the present claims. Although paragraph 0049 mentions dynamic generation of new automation types, there is no discussion in this paragraph or elsewhere of how such automations would be generated, whether based on an artifact or not. Although Applicant further alleges that one of ordinary skill would understand that the server “would generate an automation based on stored automations without having to rewrite an automation” (page 9 of the 02 January 2026 response, no evidence cited) and paragraph 0048 states “content can be generated that can be adapted programmatically to multiple environments”, this still does not explain what steps would need to be taken to generate such an automation. As per MPEP § 2161.01, claims may lack written description when the claims define the invention in functional language specifying a desired result but the specification does not sufficiently describe how the function is performed or the result is achieved, which can occur when the algorithm, steps, or procedures for performing the computer function are not explained at all or are not explained in sufficient detail. When a claim is not limited to any particular structure for performing a recited function and does not invoke 35 U.S.C. 112(f), any claim language reciting the ability to perform a function per se would typically be construed broadly to cover any and all embodiments that perform the recited function. Because such a claim encompasses all devices or structures that perform the recited function, there is a concern regarding whether the applicant's disclosure sufficiently enables the full scope of protection sought by the claim. As set forth in the previous Office action, the scope of “generating an automation based on the artifact” is a broad recitation and the claims do not recite any details limiting the steps used to generate this automation. There is no detail provided in the specification of how the automation is generated or what the schema does. The specification provides no specific algorithm, instructions, or working example of how the automation is to be generated. The lack of details or examples in any detail suggests that there is little direction provided by the inventor. Combined with the broad scope of the claims, this suggests that the enablement of the description is not commensurate in scope with the claims (MPEP § 2164.08) and that undue experimentation would be required to make or use the invention based on the disclosure (MPEP § 2164.06).
Regarding the rejection of Claims 1-20 under 35 U.S.C. 112(b) as indefinite, and with reference to amended independent Claim 1, Applicant argues that the amended language of a “block executable file automation” would be understood as something that could be transmitted (page 9 of the 02 January 2026 response), this language is still not clear as something that could be transmitted. At best, it appears to be an automation for a file, but again, it is not clear how an automation would be transmitted. See the revised rejection below for further detail.
With reference to Claims 7, 13, and 20 Applicant argues that the claims have been amended to recite “for future use of the artifact” (see pages 10-12 of the 02 January 2026 response). First, it is noted that Claim 20 has not been amended in this manner. Further, although it is now clear that the use is of the artifact, it is still not grammatically clear what the phrase is intended to modify due to its placement in the claim.
Regarding the rejection of Claims 1-20 under 35 U.S.C. 102(a)(1) as being anticipated by Maes, US Patent Application Publication 2016/0254957, and with particular reference to independent Claim 1, Applicant argues that Maes does not disclose a system for remotely managing another organization’s SOAR platform (page 12 of the 02 January 2026 response), and Applicant further argues that Maes does not disclose a system configured to manage network security on behalf of many different tenant networks (page 12 of the 02 January 2026 response, citing Maes, paragraphs 0210-0211). In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., remotely managing another organization’s platform, many different tenant networks) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). Although Claim 14 recites “remotely managing” in the preamble, none of the claims require any limitations relating to whether anything being managed belongs to any particular organization, nor do the claims mention any tenant networks, let alone many different tenant networks.
Applicant further argues that Maes does not disclose generating a block executable file automation for the tenant based on the artifact, where Applicant asserts that “the topologies of Maes” are specific to a single cloud platform whereas the claims as amended recite that automations are executable security orchestration artifacts for one of many tenants (pages 12-13 of the 02 January 2026 response, citing Maes, Abstract, and paragraphs 0030 and 0035 of the present specification). Again, as noted above, the features Applicant relies on (automations are executable security orchestration artifacts, or many tenants) are not recited in the rejected claims. It is maintained that the cited portions of Maes do disclose generating, via an automation schema, an executable automation for the tenant based on the artifact that includes a security tool configured to continuously monitor an API deployed by the tenant security platform as recited in amended independent Claim 1 (see Maes, paragraph 0045, provisioned application, including executables or installable artifacts, using APIs; paragraph 0064, control of APIs; paragraph 0144, obtaining artifacts required to deploy application; see also paragraph 0199, monitoring using APIs).
Therefore, for the reasons detailed above, the Examiner maintains the rejections as set forth below.
Drawings
The objection to Figure 5 as requiring a prior art label and the objection to the drawings for informalities are withdrawn in light of the amended drawings filed. The objections to the drawings for failure to comply with 37 CFR 1.84(p)(5) are partially withdrawn because not all issues have been addressed, as detailed below.
The drawings are objected to as failing to comply with 37 CFR 1.84(p)(5) because they include the following reference character(s) not mentioned in the description: 522 and 524 (see Figure 5). Corrected drawing sheets in compliance with 37 CFR 1.121(d), or amendment to the specification to add the reference character(s) in the description in compliance with 37 CFR 1.121(b) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Specification
The objection to the abstract for informalities is withdrawn in light of the amendments thereto. The objection to the disclosure for informalities is NOT withdrawn, because not all issues have been addressed and/or because the amendments have raised new issues, as detailed below.
The disclosure is objected to because of the following informalities:
The specification does not include a section identified as the background as per 37 CFR 1.77(b).
The list of documents to be incorporated by reference is not clear. At the end of page 5, line 3 (see the annotated version of the substitute specification), there is an “and” without anything following it.
The specification includes minor grammatical and other errors. For example, at the end of the last line of paragraph 0031 (as renumbered), there is an “and” without anything following it and the sentence does not end with a period. In paragraph 0048 (as renumbered), line 19, it appears that “convention” should read “conventional”. In the last line of paragraph 0048 (as renumbered), it appears that “tenant’s” should read “tenants” (plural, not possessive).
Appropriate correction is required. The above is not intended as an exhaustive list of errors in the specification. Applicant’s cooperation is again requested in correcting any errors of which applicant may become aware in the specification.
Claim Rejections - 35 USC § 112
The rejections of Claims 1-20 under 35 U.S.C. 112(a) for failure to comply with the enablement requirement and under 35 U.S.C. 112(b) as indefinite are NOT withdrawn, for the reasons detailed above in the response to arguments, and/or because not all issues have been addressed and/or because the amendments have raised new issues, as detailed below.
The following is a quotation of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the enablement requirement. The claims contain subject matter which was not described in the specification in such a way as to enable one skilled in the art to which it pertains, or with which it is most nearly connected, to make and/or use the invention.
A determination of a failure to comply with the enablement requirement is made considering the undue experimentation factors set forth in MPEP § 2164.01(a). In the present application, the factors which appear to weigh most heavily are the breadth of the claims (MPEP § 2164.08), the amount of direction provided by the inventor (MPEP § 2164.03), and the existence of working examples (MPEP § 2164.02). Independent Claims 1, 10, and 14 broadly recite “generating, via the automation schema, a block executable file automation for the tenant based on the artifact” or similar language. The phrase “generating [an] … automation based on the artifact” is a broad recitation, and the claims do not recite any details of the steps used to generating this automation. Although the specification generally discusses using a schema to generate an automation based on the artifact in similar language as the claims (see paragraphs 0055 and 0049 as renumbered), there appears to be no detail provided in the specification of how the automation is actually generated or what the schema does in the generation. There are also no details of the particular type of automation (“block executable file”) described in the specification. The specification appears to have no specific algorithm, instructions, or other working example of how the automation is to be generated. The lack of details or examples in any detail suggests that there is little direction provided by the inventor. Combined with the broad scope of the claims, this suggests that the enablement of the description is not commensurate in scope with the claims (MPEP § 2164.08) and that undue experimentation would be required to make or use the invention based on the disclosure (MPEP § 2164.06).
Claims not explicitly referred to above are rejected due to their dependence on a rejected base claim.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 recites “a block executable file automation” in line 11. This phrase is generally unclear as to whether this is a block of executable code (see paragraph 0048 as renumbered, where an artifact can include a block of executable code), or an automation that can block executable files (see paragraph 0049 as renumbered), or how the term “block” may otherwise be intended to modify the remainder of the phrase. The claim further recites “transmit… the generated automation to the tenant security platform” in lines 14-15. It is still not clear that an “automation” is something that could be transmitted. The phrase “block executable file automation” does not clearly limit the automation itself to an executable file or executable code. These ambiguities render the claim indefinite.
Claim 7 recites “the security automation application is configured to automatically update the artifact based on the detected variable associated with the tenant for future use of the artifact” in lines 1-3. It is not grammatically clear what the phrase “for future use” is intended to modify. While it is now clear that the future use is “of the artifact”, it is still not grammatically clear what is “for” the future use based on the placement of the phrase.
Claim 10 recites “a block executable file automation” in line 10. This phrase is generally unclear as to whether this is a block of executable code (see paragraph 0048 as renumbered, where an artifact can include a block of executable code), or an automation that can block executable files (see paragraph 0049 as renumbered), or how the term “block” may otherwise be intended to modify the remainder of the phrase. The claim further recites “transmitting… the generated automation to the SOAR platform deployed by the tenant” in lines 13-14. It is still not clear that an “automation” is something that could be transmitted. The phrase “block executable file automation” does not clearly limit the automation itself to an executable file or executable code. These ambiguities render the claim indefinite.
Claim 13 recites “automatically updating, via the content library, the artifact based on the detected variable associated with the tenant for future use of the artifact” in lines 1-3. It is not grammatically clear what the phrase “for future use” is intended to modify. While it is now clear that the future use is “of the artifact”, it is still not grammatically clear what is “for” the future use based on the placement of the phrase.
Claim 14 recites “a block executable file automation” in line 12. This phrase is generally unclear as to whether this is a block of executable code (see paragraph 0048 as renumbered, where an artifact can include a block of executable code), or an automation that can block executable files (see paragraph 0049 as renumbered), or how the term “block” may otherwise be intended to modify the remainder of the phrase. The claim further recites “transmit… the generated automation to the SOAR platform deployed by the tenant” in lines 15-16. It is still not clear that an “automation” is something that could be transmitted. The phrase “block executable file automation” does not clearly limit the automation itself to an executable file or executable code. These ambiguities render the claim indefinite.
Claim 20 recites “the security automation application further causes the processor to automatically update the artifact based on the detected variable associated with the tenant for future use” in lines 2-3. It is not grammatically clear what the phrase “for future use” is intended to modify; for example, it is not clear if the tenant, the variable, or the artifact is “for future use”, and it is not grammatically clear what is “for” the future use.
Claims not explicitly referred to above are rejected due to their dependence on a rejected base claim.
Claim Rejections - 35 USC § 102
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.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Maes, US Patent Application Publication 2016/0254957.
In reference to Claim 1, Maes discloses a security automation platform coupled to a tenant configured to deploy a tenant security platform, where the automation platform includes a processor and a memory configured to store a security automation application, content library, variable store, automation schema, and API broker (see paragraph 0209, processor; paragraph 0143 and Figure 4, definitive software library database 323; paragraph 0045, APIs; see also paragraphs 0115-0116), where the application causes the processor to detect a variable associated with the tenant via the variable store (paragraph 0116); correlate, via the library, the detected variable to an artifact stored in the library (paragraph 0116; see also paragraphs 0143-0144); generate, via the schema, an executable automation based on the artifact, where the automation includes a security tool configured to monitor an API (see paragraphs 0045, provisioned application, including executables or installable artifacts, using APIs; paragraphs 0064, 0087, and 0144, describing control of APIs and obtaining artifacts required to deploy application; see also paragraph 0199, monitoring using APIs); and transmit, via the broker, the generated automation to the tenant security platform (paragraphs 0045, 0064, 0087, 0144).
In reference to Claim 2, Maes further discloses detecting a security event associated with the API and generating and transmitting to the tenant security platform an alert associated with the event (see paragraphs 0045 and 0119-0126, events and notifications).
In reference to Claims 3-5, Maes further discloses a recommended action to mitigate the security event, including removing network access associated with a suspect account with approval from an administrative account (see paragraphs 0120-0126, remediation; see also paragraphs 0064, 0074-0078, monitoring, and 0080, administrator approval).
In reference to Claims 6 and 7, Maes further discloses that the artifact includes a detection, workbook, rule, or playbook as well as updating the artifact (see paragraphs 0143-0144).
In reference to Claim 8, Maes further discloses a plurality of tenants and a plurality of tenant security platforms managed simultaneously (see Figures, tenants 302-1 to 302-n; see also paragraph 0029, cloud; paragraphs 0038, 0053).
In reference to Claim 9, Maes further discloses a GUI to receive user input including an instruction associated with management of the platform (see paragraphs 0050 and 0217, GUIs).
Claims 10-13 are directed to methods corresponding to the functionality of the platforms of Claims 1-4 and 7, and are rejected by a similar rationale, mutatis mutandis.
Claims 14-20 are directed to systems including a tenant as described in Claim 1 and a management server corresponding to the platforms of Claims 1-7, and are rejected by a similar rationale, mutatis mutandis.
Conclusion
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Zachary A Davis whose telephone number is (571)272-3870. The examiner can normally be reached Monday-Friday, 9:00am-5:30pm, Eastern Time.
Examiner interviews are available via telephone 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, Rupal D Dharia can be reached at (571) 272-3880. 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.
/Zachary A. Davis/Primary Examiner, Art Unit 2492
