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 .
Information Disclosure Statement
The information disclosure statements (IDSes) submitted on November 10, 2024, and March 5, 2026 were filed. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Specification
The disclosure is objected to because of the following informalities:
Paragraphs [0011] and [0012], “promoting” should be “prompting”.
Paragraph [[0036] “API endpoint ID” should be “path API endpoint ID”.
Paragraph [0113], “Figure 5” should be “Figure 11”, as subsequent paragraphs describe steps found in Figure 11.
Appropriate correction is required.
Claim Objections
Claims 5 and 6 are objected to because of the following informalities:
“promoting” should be “prompting”.
Appropriate correction is required.
Claim Rejections - 35 USC § 112(b)
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-8, and 12-17 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.
Claims 1 and 8 recites the limitation "the created user identities" in claim 1, lines 7-8, and claim 8, lines 11-12. There is insufficient antecedent basis for this limitation in the claim, and should be replaced with the term “the set of artificial user identities”, as the term “set of artificial user identities” was stated in claim 1.
Claims 2-7 depend on the limitations present in claim 1, and as a result, claims 2-7 are also rejected under 112(b) as they are dependent on claim 1 above.
The term “proper subset” in claim 7, line 2 is a relative term which renders the claim indefinite. The term “proper subset” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. Although the term is stated to also be known as a “strict subset” in paragraph [0126] in the Specification of the invention, there is no further definition as to what either the “proper subset” or “strict subset” is defined as in the context of creating or utilization of an artificial user identities.
Claim 12 recites the limitation "the paths" in line 1. There is insufficient antecedent basis for this limitation in the claim, and should be replaced with the term “the execution paths”, as the term “execution paths” was stated in claim 9.
Claims 13-17 depend on the limitations present in claim 12, and as a result, claims 13-17 are also rejected under 112(b) as they are dependent on claim 12 above.
The term “trimmed API specification” in claim 13, line 4 is a relative term which renders the claim indefinite. The term “trimmed API specification” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. Although described in paragraph [0138], in that the LLM 34 generates a respective “trimmed API specifications 56” for the execution path identified in step 156 in figure 11, and comprises information that LLM 34 extracts from the API specification only for the consumer API endpoint, it is not described what aspects are “trimmed” in the trimmed API specification for a consumer API endpoint, such as functions being eliminated that are deemed unnecessary for the API consumer to utilize, or other parameters that are retained in the “trimmed” API specification.
Claims 14-17 depend on the limitations present in claim 13, and as a result, claims 14-17 are also rejected under 112(b) as they are dependent on claim 13 above.
Claim Rejections - 35 USC § 112(a)
The following is a quotation of the first paragraph 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-21 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 written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
The written description requirement is satisfied only if the specification reasonably conveys to those skilled in the art that the inventor had possession of the claimed invention as of the filing date. See Ariad Pharm., Inc. v. Eli Lilly & Co., 598 F.3d 1336, 1351, 94 USPQ2d 1161, 1172 (Fed. Cir. 2010) (en banc). For computer-implemented inventions, the sufficiency of disclosure must be assessed with attention to the interrelationship of the disclosed hardware and software, and the critical inquiry remains whether the disclosure reasonably conveys possession of the claimed subject matter. See MPEP § 2161.01; Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 682, 114 USPQ2d 1349, 1356.
In claim 1, it is stated, in lines 2-4, that a large language model (LLM) takes an API specification of a software application as an input, and claim 1 recites, inter alia, “prompting the LLM to create, based on the specification, a set of artificial user identities” and “testing the software application with the created user identities to discover a security vulnerability in the software application.” The specification does not reasonably convey possession of the claimed subject matter in the breadth claimed because it does not adequately describe how the LLM is programmed, configured, or operated to create the set of artificial user identities based on the API specification. The disclosure appears to state the desired result—i.e., that the LLM creates artificial user identities—but does not provide sufficient detail regarding the model inputs, prompting structure, or other operative mechanism by which the LLM is caused to generate the claimed identities. Merely reciting that an LLM is prompted to generate the identities is not sufficient written description for the claimed functionality absent disclosure showing that applicant was in possession of the manner in which the generation is achieved.
In addition, the specification does not reasonably convey possession of the broader limitation “testing the software application with the created user identities to discover a security vulnerability in the software application.”
The disclosure is directed principally to a particular BOLA-oriented security testing workflow involving API specifications, artificial user identities, registration/login scripts, and token-based testing. Here, although the specification describes a general BOLA-oriented testing workflow, it does not reasonably convey possession of the claimed subject matter because it does not adequately describe how the LLM is programmed, configured, or operated to create the set of artificial user identities for BOLA testing, nor does it adequately describe how those identities are used in a defined sequence of operations to detect a BOLA vulnerability, but does not describe a generalized method for discovering security vulnerabilities across the full scope of claim 1. The specification largely recites the intended outcome of vulnerability discovery, rather than describing the claimed vulnerability-detection technique with sufficient specificity.
Accordingly, the specification fails to reasonably convey that applicant was in possession of the claimed invention.
Claims 2-7 depend on the limitations present in claim 1, and as a result, claims 2-7 are also rejected under 112(a) as they are dependent on claim 1 above.
Claim 8 shares the limitations also present in claim 1, and as it also shares the limitation of inputting, to an LLM, an API specification, it is also rejected under 112(a) for lack of written description as claim 1 above.
Claim 9 shares the limitations also present in claim 1, and as it also shares the limitation of inputting, to an LLM, an API specification, it is also rejected under 112(a) for lack of written description as claim 1 above.
Claims 10-19 depend on the limitations present in claim 9, and as a result, claims 10-19 are also rejected under 112(a) as they are dependent on claim 9 above.
Claim 15 states the claim limitation of “wherein ranking the test scripts comprises identifying, for each of the consumer API endpoints, a primary key comprising a consumer operation selected from a list consisting of a GET operation, a POST operation, a PUT operation and a DELETE operation, and ranking the test scripts based on a primary key, wherein, in the primary keys, the ranking for a given script whose respective consumer operation comprises a GET operation is greater than a given script whose respective consumer operation comprises a POST operation, wherein the ranking for a given script whose respective consumer operation comprises a POST operation is greater than a given script whose respective consumer operation comprises a PUT operation, and wherein the ranking for a given script whose respective consumer operation comprises a PUT operation is greater than a given script whose respective consumer operation comprises a DELETE operation”, described in paragraphs [0144] and [0146], and Fig. 6, where consumer endpoints execute commands of the API operations of GET, POST, PUT, and DELETE, in that particular order based on the ranking of test scripts. However, how the test scripts are ranked based on the API operations, as well as the primary key, remains unknown, such as via a system where certain requests are of higher importance, address severe or vulnerable aspects of a system, or otherwise any way of addressing the test scripts to be ranked is not described in a sufficient manner.
Similar issues exist for claim 16, which recites “further comprising identifying a set of scripts having identical primary keys, identifying, for each of the producer API endpoints in the set, a secondary key comprising a producer operation selected from a list consisting of a POST operation, a GET operation, a PUT operation and a DELETE operation, and ranking the test scripts in the set based on the secondary key, wherein, in the secondary key, the ranking for a given script whose respective producer operation comprises a POST operation is greater than a given script whose respective producer operation comprises a GET operation, wherein the ranking for a given script whose respective producer operation comprises a GET operation is greater than a given script whose respective producer operation comprises a PUT operation, and wherein the ranking for a given script whose respective producer operation comprises a PUT operation is greater than a given script whose respective producer operation comprises a DELETE operation”, as described in paragraphs [0145]-[0146] and Fig. 6, and is rejected by 112(a) for similar rationale as claim 15 above.
Similar issues exist for claim 17, which recites “wherein upon detecting one of the scripts comprising multiple producer endpoints, assigning a delete operation to the secondary key of detected script if any of the multiple producer endpoints in the detected script comprises any DELETE operations, assigning a PUT operation to the secondary key of detected script if any of the multiple producer endpoints in the detected script comprises any PUT operations and does not comprise any DELETE operations, assigning a POST operation to the secondary key of detected script if any of the multiple producer endpoints in the detected script comprises any POST operations and does not comprise any DELETE operations or any PUT operations, and assigning a GET operation to the secondary key of detected script if any of the multiple producer endpoints in the detected script comprises any GET operations and does not comprise any DELETE operations any PUT operations or any POST operations”, as described in paragraphs [0023], [0144]-[0146] and Fig. 6, as it is also not stated how assigning operations to secondary keys with scripts without certain operations in any of the scripts remains unknown and is not described in sufficient detail in the Specification.
Claim 20 shares the limitations also present in claims 1 and 9, and as it also shares the limitation of inputting, to an LLM, an API specification, it is also rejected under 112(a) for lack of written description as claims 1 and 9 above.
Claim 21 shares the limitations also present in claims 1 and 9, and as it also shares the limitation of inputting, to an LLM, an API specification, it is also rejected under 112(a) for lack of written description as claims 1 and 9 above.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-21 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. In claim 1, the claim recites “prompting the LLM to create, based on the specification, a set of artificial user identities”, which provides the LLM to generate synthetic data or test personas based on input information, and “testing the software application with the created user identities to discover a security vulnerability in the software application”, which takes the generated synthetic data or test personas from the LLM, and utilizes said data or personas to discover vulnerabilities and evaluates the results. This judicial exception is not integrated into a practical application because the limitations above involve the process of generating and evaluating information, and as these tasks of reviewing API specification information, creating hypothetical user identities, and using the identities to assess and evaluate the security of a computer program, the claim limitations fall within the abstract idea, specifically the category of mental processes and information analysis, with the aid of a computer. See MPEP § 2106.05(a)(II), “IMPROVEMENTS TO ANY OTHER TECHNOLOGY OR TECHNICAL FIELD”. “Merely adding generic computer components to perform the method is not sufficient. Thus, the claim must include more than mere instructions to perform the method on a generic component or machinery to qualify as an improvement to an existing technology”. The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception because the claim limitation also present in the independent claim, “inputting, to a large language model (LLM), a specification of an application programming interface (API) of the software application”, recites a judicial exception, particular an insignificant extra-solution activity to the judicial exception, of inputting information, which is the API specification, into a component, which is the LLM, to carry out the process of generating artificial user identities and testing for vulnerabilities present in the application. In terms of subject matter eligibility, while step 1 is fulfilled with claim 1 being a method claim, Step 2A, Prong One is fulfilled, as the claim recites an abstract idea, with Step 2A, Prong Two failing, as the claim does not recite additional elements to integrate the judicial exception into a practical application, as merely using an LLM as a tool to generate the user identities does not go beyond the abstract idea of generating said identities. Finally, Step 2B fails, as the additional elements of inputting to an LLM does not amount to significantly more than the judicial exception of an abstract idea of generating user identities and evaluating an application. The independent claim does not recite an inventive concept beyond the abstract idea itself.
In claim 2, the recitation of “wherein the API comprises multiple API endpoints, and wherein the specification of the API comprises a specification of the API endpoints” merely amounts to selecting a particular data source or type of data to be manipulated, such as “Limiting a database index to XML tags, Intellectual Ventures I LLC v. Erie Indem. Co., 850 F.3d at 1328-29, 121 USPQ2d at 1937”. Therefore, the elements are grouped under data gathering as an insignificant extra-solution activity, as stated in MPEP 2106.05(g), “Insignificant Extra-Solution Activity”.
In claim 3, the recitation of “wherein the security vulnerability comprises a broken object level authorization vulnerability” merely amounts to selecting a particular data source or type of data to be manipulated, and therefore, the elements are grouped under data gathering as an insignificant extra-solution activity, as stated in MPEP 2106.05(g), “Insignificant Extra-Solution Activity”.
In claim 4, the recitation of “wherein the specification comprises an OpenAPI specification” merely amounts to selecting a particular data source or type of data to be manipulated, and therefore, the elements are grouped under data gathering as an insignificant extra-solution activity, as stated in MPEP 2106.05(g), “Insignificant Extra-Solution Activity”.
In claim 5, the recitation of “generating, using the first sets of information, a registration test script to register the artificial user identities with the software application”, and “wherein testing the software application comprises executing the registration test script” merely amounts to selecting a particular data source or type of data to be manipulated, and therefore, the elements are grouped under data gathering as an insignificant extra-solution activity, as stated in MPEP 2106.05(g), “Insignificant Extra-Solution Activity”. Furthermore, the limitation of “further comprising promoting the LLM to identify, based on the specification, a first set of information required to register each given artificial user identity with the software application” is a mental process that can be performed in the mind, and therefore, the element is a mental process, in particular, “FairWarning IP, LLC v. Iatric Sys., Inc., 839 F.3d 1089, 120 USPQ2d 1293 (Fed. Cir. 2016)”. The patentee in FairWarning claimed a system and method of detecting fraud and/or misuse in a computer environment. The court determined that these claims were directed to a mental process of detecting misuse, and that the claimed rules here were “the same questions (though perhaps phrased with different words) that humans in analogous situations detecting fraud have asked for decades, if not centuries.” 839 F.3d. at 1094-95, 120 USPQ2d at 1296, as described in MPEP 2106.04(a)(2), subsection III, “Mental Processes”.
In claim 6, the recitation of “generating, using the second sets of information, a login test script to log the artificial user identities into the software application, wherein the second set comprises a subset of the first set”, and “wherein testing the software application comprises executing the registration test script” merely amounts to selecting a particular data source or type of data to be manipulated, and therefore, the elements are grouped under data gathering as an insignificant extra-solution activity, as stated in MPEP 2106.05(g), “Insignificant Extra-Solution Activity”. Furthermore, the limitation of “further comprising promoting the LLM to identify, based on the specification, a second set of information required to log each given artificial user identity into the software application” is a mental process that can be performed in the mind, and therefore, the element is a mental process, as described in MPEP 2106.04(a)(2), subsection III, “Mental Processes”.
In claim 7, the recitation of “wherein the subset comprises a proper subset” merely amounts to selecting a particular data source or type of data to be manipulated, and therefore, the elements are grouped under data gathering as an insignificant extra-solution activity, as stated in MPEP 2106.05(g), “Insignificant Extra-Solution Activity”.
In claim 8, the independent claim 8 discloses similar limitations present in independent claim 1 above, and as a result, is also rejected for similar reasons to claim 1 above under 35 U.S.C. 101. See MPEP § 2106.05(a)(II), “IMPROVEMENTS TO ANY OTHER TECHNOLOGY OR TECHNICAL FIELD”. “Merely adding generic computer components to perform the method is not sufficient. Thus, the claim must include more than mere instructions to perform the method on a generic component or machinery to qualify as an improvement to an existing technology”.
In claim 9, the independent claim 9 discloses similar limitations present in independent claim 1 above, and as a result, is also rejected for similar reasons to claim 1 above under 35 U.S.C. 101. Furthermore, claim 9 recites “prompting the LLM to generate, based on the specification, respective test scripts to test the identified execution paths”, merely amounts to selecting a particular data source or type of data to be manipulated, and therefore, the element is grouped under data gathering as an insignificant extra-solution activity, as stated in MPEP 2106.05(g), “Insignificant Extra-Solution Activity”. Furthermore, the limitation of “for each given API consumer in the set, prompting the LLM to identify, based on the specification, one or more execution paths leading to the given consumer from respective API producers, which deliver the information to the software application” is a mental process that can be performed in the mind, and therefore, the element is a mental process, as described in MPEP 2106.04(a)(2), subsection III, “Mental Processes”.
In claim 10, the claim recites similar limitations as claim 2 recited above, and as a result, are also rejected for similar rationale to claim 2 above under 35 U.S.C. 101.
In claim 11, the recitation of “wherein the API endpoints comprise producer and consumer API endpoints”, “wherein the producer API endpoints produce output”, and “wherein each of the consumer API endpoints consumes the output of a given producer API endpoint as an input parameter” merely amounts to selecting a particular data source or type of data to be manipulated, and therefore, the elements are grouped under data gathering as an insignificant extra-solution activity, as stated in MPEP 2106.05(g), “Insignificant Extra-Solution Activity”.
In claim 12, the recitation of “wherein each of the paths comprises a given consumer API endpoints and one or more producer API endpoints” merely amounts to selecting a particular data source or type of data to be manipulated, and therefore, the elements are grouped under data gathering as an insignificant extra-solution activity, as stated in MPEP 2106.05(g), “Insignificant Extra-Solution Activity”.
In claim 13, the recitation of “wherein the API specification comprises information for each of the API endpoints, and further comprising generating for each given path, a trimmed API specification comprising the information for the producer API endpoint and the one or more producer API endpoints in the given path”, and “wherein prompting the LLM to generate the test script for the given path comprises prompting the LLM to generate, based on the trimmed API specification, the test script for the given path” merely amounts to selecting a particular data source or type of data to be manipulated, and therefore, the elements are grouped under data gathering as an insignificant extra-solution activity, as stated in MPEP 2106.05(g), “Insignificant Extra-Solution Activity”.
In claim 14, the recitation of “comprising identifying dependencies between the test scripts”, “ranking the test scripts based on their respective dependencies”, and “executing the test scripts in order of their respective rankings” are mental processes that can be performed in the mind, and therefore, the elements are mental processes, as described in MPEP 2106.04(a)(2), subsection III, “Mental Processes”.
In claim 15, the recitation of “wherein ranking the test scripts comprises identifying, for each of the consumer API endpoints, a primary key comprising a consumer operation selected from a list consisting of a GET operation, a POST operation, a PUT operation and a DELETE operation, and ranking the test scripts based on a primary key, wherein, in the primary keys, the ranking for a given script whose respective consumer operation comprises a GET operation is greater than a given script whose respective consumer operation comprises a POST operation, wherein the ranking for a given script whose respective consumer operation comprises a POST operation is greater than a given script whose respective consumer operation comprises a PUT operation, and wherein the ranking for a given script whose respective consumer operation comprises a PUT operation is greater than a given script whose respective consumer operation comprises a DELETE operation” are mental processes that can be performed in the mind, and therefore, the elements are mental processes, as described in MPEP 2106.04(a)(2), subsection III, “Mental Processes”.
In claim 16, the recitation of “further comprising identifying a set of scripts having identical primary keys, identifying, for each of the producer API endpoints in the set, a secondary key comprising a producer operation selected from a list consisting of a POST operation, a GET operation, a PUT operation and a DELETE operation, and ranking the test scripts in the set based on the secondary key, wherein, in the secondary key, the ranking for a given script whose respective producer operation comprises a POST operation is greater than a given script whose respective producer operation comprises a GET operation, wherein the ranking for a given script whose respective producer operation comprises a GET operation is greater than a given script whose respective producer operation comprises a PUT operation, and wherein the ranking for a given script whose respective producer operation comprises a PUT operation is greater than a given script whose respective producer operation comprises a DELETE operation” are mental processes that can be performed in the mind, and therefore, the elements are mental processes, as described in MPEP 2106.04(a)(2), subsection III, “Mental Processes”.
In claim 17, “wherein upon detecting one of the scripts comprising multiple producer endpoints, assigning a delete operation to the secondary key of detected script if any of the multiple producer endpoints in the detected script comprises any DELETE operations, assigning a PUT operation to the secondary key of detected script if any of the multiple producer endpoints in the detected script comprises any PUT operations and does not comprise any DELETE operations, assigning a POST operation to the secondary key of detected script if any of the multiple producer endpoints in the detected script comprises any POST operations and does not comprise any DELETE operations or any PUT operations, and assigning a GET operation to the secondary key of detected script if any of the multiple producer endpoints in the detected script comprises any GET operations and does not comprise any DELETE operations any PUT operations or any POST operations” are mental processes that can be performed in the mind, and therefore, the elements are mental processes, as described in MPEP 2106.04(a)(2), subsection III, “Mental Processes”.
In claim 18, the claim recites similar limitations as claim 3 recited above, and as a result, are also rejected for similar rationale to claim 3 above under 35 U.S.C. 101.
In claim 19, the claim recites similar limitations as claim 4 recited above, and as a result, are also rejected for similar rationale to claim 3 above under 35 U.S.C. 101.
In claim 20, the independent claim 20 discloses similar limitations present in independent claim 9 above, and as a result, is also rejected for similar reasons to claim 9 above under 35 U.S.C. 101. See MPEP § 2106.05(a)(II), “IMPROVEMENTS TO ANY OTHER TECHNOLOGY OR TECHNICAL FIELD”. “Merely adding generic computer components to perform the method is not sufficient. Thus, the claim must include more than mere instructions to perform the method on a generic component or machinery to qualify as an improvement to an existing technology”.
In claim 21, the independent claim 21 discloses similar limitations present in independent claim 9 above, and as a result, is also rejected for similar reasons to claim 9 above under 35 U.S.C. 101. See MPEP § 2106.05(a)(II), “IMPROVEMENTS TO ANY OTHER TECHNOLOGY OR TECHNICAL FIELD”. “Merely adding generic computer components to perform the method is not sufficient. Thus, the claim must include more than mere instructions to perform the method on a generic component or machinery to qualify as an improvement to an existing technology”.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 4, 8-9, and 19-21 are rejected under 35 U.S.C. 103 as being unpatentable over Lal et al. (US 20240414190 A1), hereinafter “Lal”, in view of Jeevagunta (US 20240403444), hereinafter “Jeevagunta”.
Regarding claim 1, Lal discloses a “method for testing a software application, comprising: inputting, to a large language model (LLM), a specification of an application programming interface (API) of the software application” ([0040] LLM is provided with an API specification. [0264] API Specification includes those for software applications.);
“prompting the LLM to create, based on the specification, a set of artificial user identities” ([0028] LLM can generate summaries for users of cybersecurity appliances. [0244] Cyber-attack simulation engine 160 includes and cooperates with one or more AI models 987 trained with machine learning, such as to have its own separate model training with ML on contextual knowledge of organization and each user's and device's normal behavior pattern. [0085] AI models include LLMs.);
“and testing the software application with the created user identities to discover a security vulnerability” ([0244] Simulated attack module 950 in cyber-attack simulation engine 160 is implemented via a simulator to model the system OR a virtual clone of the system being protected to pen-test defenses. This includes, in paragraph [0246], generating a phishing email as part of a software attack to a specific user, and exploit security vulnerabilities.);
Lal does not appear to fully disclose or suggest, but Jeevagunta teaches the limitation of “security vulnerability in the software application” ([0021] Threat discovery 105 may implement API tests based on the normal operating behavior of APIs 112 to drive APIs 112 to perform unauthorized actions. Threat discovery 105 generates an API security report that inventories the discovered APIs and indicates and discovered API threats. API security service 102 transfers the security report for delivery to operator environment 120.);
Therefore, one of ordinary skill in the art would have been capable of applying this known method of "security vulnerability in the software application" in a method for testing a software application and the results would have been predictable to one of ordinary skill in the art. The one of ordinary skill in the art would have been motivated to identify security vulnerabilities in an API of a software application, which includes fraudulent user credentials, providing access to resources that should be non-accessible, providing unintended functionality, which need to be discovered and mitigated before real world harm to consumers can be done, with an API security service implements an API discovery process to identify APIs based on traffic logs stored by a data center (Jeevagunta [0019]).
Regarding claim 4, Lal in view of Jeevagunta teaches the limitations of claim 1 above. Lal does not appear to suggest, but Jeevagunta teaches “wherein the specification comprises an OpenAPI specification” ([0021] Commonly used API endpoints in publicly available open API specifications associated with organization 110.).
Therefore, one of ordinary skill in the art would have been capable of applying this known method of "wherein the specification comprises an OpenAPI specification" in a method for testing a software application and the results would have been predictable to one of ordinary skill in the art. The one of ordinary skill in the art would have been motivated to use commonly used API endpoints, which includes those publicly available, such as open API specifications, such as Swagger (Jeevagunta [0021], [0040]).
Regarding claim 8, Lal in view of Jeevagunta teaches similar limitations that are also present in claim 1 above. Lal also discloses “a computer software product for identifying a vulnerability in a software application, the computer software product comprising a non-transitory computer-readable medium, in which program instructions are stored, which instructions, when read by a computer” ([0262] Computer program product implements a computer readable medium such as a removable computer disk, a hard drive, or an optical disc. [0261] “Thus, any portions of the method, apparatus and system implemented as software can be stored in one or more non-transitory memory storage devices in an executable format to be executed by one or more processors”.);
Regarding claim 9, Lal in view of Jeevagunta teaches similar limitations that are also present in claim 1 above. Lal does not appear to suggest, but Jeevagunta teaches “for each given API consumer in the set, prompting the LLM to identify, based on the specification, one or more execution paths leading to the given consumer from respective API producers, which deliver the information to the software application” ([0021] Log analyzer 104 may determine API endpoints and paths for unmentioned ones of APIs 112 based on commonly used API endpoints in publicly available open API specifications associated with organization 110. Log analyzer 104 may identify ancillary endpoints that typically exist with these APIs even though they are not documented in API specifications. Examples of ancillary endpoints include /api/health, /api/version, /api/metrics.);
“prompting the LLM to generate, based on the specification, respective test scripts to test the identified execution paths” ([0021] Threat discovery 105 may implement API tests based on the normal operating behavior of APIs 112 to drive APIs 112 to perform unauthorized actions.).
Therefore, one of ordinary skill in the art would have been capable of applying this known method of "for each given API consumer in the set, prompting the LLM to identify, based on the specification, one or more execution paths leading to the given consumer from respective API producers, which deliver the information to the software application" and “prompting the LLM to generate, based on the specification, respective test scripts to test the identified execution paths” in an method for testing a software application and the results would have been predictable to one of ordinary skill in the art. The one of ordinary skill in the art would have been motivated to determine whether an API of a software application is capable of unauthorized or unwanted behavior that can harm users or devices, and to provide a report so that developers can remedy the malicious behaviors (Jeevagunta [0031], [0028]).
Regarding claim 19, Lal in view of Jeevagunta teaches similar limitations that are also present in claim 9 above. Lal in view of Jeevagunta teaches similar limitations present in claim 4 above.
Regarding claim 20, Lal in view of Jeevagunta teaches similar limitations that are also present in claims 1 and 9 above. Lal also discloses “An apparatus for testing a software application, comprising: a memory configured to store a large language model (LLM)” ([0006] Cybersecurity system can use LLMs as an orchestrator in detection of potential cyber threats. [0236] Fig. 8, computing device includes cybersecurity appliance 150, which includes the AI models 560, including the LLM. The computing device includes one or more processors 820, and one or more memories 830-832.);
“and a processor configured” ([0236] Fig. 8, computing device includes one or more processors 820.);
Regarding claim 21, Lal in view of Jeevagunta teaches similar limitations that are also present in claims 1, and 8-9 above. Lal also discloses the computer software product for identifying a vulnerability in a software application as described in claim 8 above.
Claims 2-3, 10-14, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Lal in view of Jeevagunta as applied to claims 1 and 9 above, and further in view of Lashvicher et al. (US 20250181756 A1), hereinafter Lashvicher.
Regarding claim 2, Lal in view of Jeevagunta teaches similar limitations that are also present in claim 1 above. Lal in view of Jeevagunta does not appear to teach or suggest, but Lashvicher teaches “wherein the API comprises multiple API endpoints, and wherein the specification of the API comprises a specification of the API endpoints” ([0013] The application generally makes API requests from the user computer to the host server to retrieve desired information. [0053] The API described herein may be implemented as one or more calls in program code that send or receive one or more parameters through a parameter list or other structure based on a call convention defined in an API specification document.);
Therefore, one of ordinary skill in the art would have been capable of applying this known method of “wherein the API comprises multiple API endpoints, and wherein the specification of the API comprises a specification of the API endpoints” in a method for testing a software application and the results would have been predictable to one of ordinary skill in the art. The one of ordinary skill in the art would have been motivated to provide the user computer with the resources of the server that utilizes an API once the user logs in to the service with their user ID and password (Lashvicher [0017]).
Regarding claim 3, Lal in view of Jeevagunta, further in view of Lashvicher teaches similar limitations that are also present in claims 1 and 2 above. Lal in view of Jeevagunta does not appear to teach or suggest, but Lashvicher teaches “wherein the security vulnerability comprises a broken object level authorization vulnerability” ([0026] The object level authorization (e.g., authorization of a JSON object) performed by sending the user account number from the user computer to the host to access the user profile information is broken because the user account number suffers from a weakness (e.g., a format that can be used to determine other user account numbers).);
Therefore, one of ordinary skill in the art would have been capable of applying this known method of “wherein the security vulnerability comprises a broken object level authorization vulnerability” in a method for testing a software application and the results would have been predictable to one of ordinary skill in the art. The one of ordinary skill in the art would have been motivated to address the issue of “broken” fields in an API communication, such as a user account number suffering from a weakness, including a format that is used to determine other user account numbers, and fixes information in the broken fields or introduces new security measures when making API requests to the server (Lashvicher [0026]).
Regarding claim 10, Lal in view of Jeevagunta teaches similar limitations that are also present in claim 9 above. Lal in view of Jeevagunta, further in view of Lashvicher teaches similar limitations present in claim 2 above.
Regarding claim 11, Lal in view of Jeevagunta, further in view of Lashvicher teaches the limitations of claims 9 and 10 above. Lal does not appear to suggest, but Jeevagunta teaches “wherein the API endpoints comprise producer and consumer API endpoints, wherein the producer API endpoints produce output, and wherein each of the consumer API endpoints consumes the output of a given producer API endpoint as an input parameter” ([0023] Fig. 1, APIs 112 comprises a system providing a cloud-based web service to a user, and comprises client-side APIs and server-side APIs. It is also stated that the API servers provide services and web resources to a client. [0029] Log analyzer 104 identifies API endpoints, and can add the discovered API endpoints to an API catalog, and is shown in Fig. 3.).
Therefore, one of ordinary skill in the art would have been capable of applying this known method of “wherein the API endpoints comprise producer and consumer API endpoints, wherein the producer API endpoints produce output, and wherein each of the consumer API endpoints consumes the output of a given producer API endpoint as an input parameter” in a method for testing a software application for and the results would have been predictable to one of ordinary skill in the art. The one of ordinary skill in the art would have been motivated to have an API contain multiple endpoints to provide services to end users that access services or other web resources (Jeevagunta [0023]).
Regarding claim 12, Lal in view of Jeevagunta, further in view of Lashvicher teaches the limitations of claims 9-11 above. Lal does not appear to suggest, but Jeevagunta teaches “wherein each of the paths comprises a given consumer API endpoints and one or more producer API endpoints” ([0021] Log analyzer 104 may determine API endpoints and paths for unmentioned ones of APIs 112 based on commonly used API endpoints in publicly available open API specifications associated with organization 110.).
Therefore, one of ordinary skill in the art would have been capable of applying this known method of "wherein each of the paths comprises a given consumer API endpoints and one or more producer API endpoints" in a method for testing a software application and the results would have been predictable to one of ordinary skill in the art. The one of ordinary skill in the art would have been motivated to determine API endpoints and paths of unmentioned systems or paths by retrieving and processing log data associated with API gateways, load balances, and API access logs, security service can efficiently discover APIs, including its endpoints, without first needing to deploy software in organization (Jeevagunta [0021]).
Regarding claim 13, Lal in view of Jeevagunta, further in view of Lashvicher teaches the limitations of claims 9-12 above. Lal discloses “prompting the LLM to generate, based on the trimmed API specification, the test script for the given path” ([0081] LLM generated attacks are utilized to perform attack path validation, with the LLM generated attacks corresponding to test scripts, as they are utilized for pen-testing of the software.).
Lal does not appear to suggest, but Jeevagunta teaches “wherein the API specification comprises information for each of the API endpoints, and further comprising generating for each given path, a trimmed API specification comprising the information for the producer API endpoint and the one or more producer API endpoints in the given path, and wherein prompting the LLM to generate the test script for the given path” ([0021] As the specification of the API can determine endpoints and paths in the open API specifications associated with the organization, the threat discovery 105 component implements API tests based on normal operating behavior of the APIs 112 to determine behaviors that are unintended and malicious. In addition, paragraph [0028], the testing of the discovered APIs is utilized to determine attack surfaces, as described in step 205 of Fig. 2.);
Therefore, one of ordinary skill in the art would have been capable of applying this known method of "wherein the API specification comprises information for each of the API endpoints, and further comprising generating for each given path, a trimmed API specification comprising the information for the producer API endpoint and the one or more producer API endpoints in the given path, and wherein prompting the LLM to generate the test script for the given path" in a method for testing a software application and the results would have been predictable to one of ordinary skill in the art. The one of ordinary skill in the art would have been motivated to detect security threats to the API based on the specifications described for the respective API (Jeevagunta [0021]).
Regarding claim 14, Lal in view of Jeevagunta, further in view of Lashvicher teaches the limitations of claims 9-12 above. Lal discloses “comprising identifying dependencies between the test scripts, ranking the test scripts based on their respective dependencies, and executing the test scripts in order of their respective rankings” ([0252] Fig. 10, AI-based simulations of cyber-attacks are comprised of, and depend on normal behavior of a device, security settings of the network devices in the different nodes of the network, for instance, and with paragraph [0176] ranking the alerts of the cyber threats based on the severity and type of attack that is identified.).
Regarding claim 18, Lal in view of Jeevagunta teaches similar limitations that are also present in claim 9 above. Lal in view of Jeevagunta, further in view of Lashvicher teaches similar limitations present in claim 3 above.
Claims 5-7 are rejected under 35 U.S.C. 103 as being unpatentable over Lal in view of Wang et al. (CN 117667741 A, using translation included in this Office Action).
Regarding claim 5, Lal in view of Jeevagunta teaches the limitations of claims 1 and 4 above. Lal discloses “promoting [sic] the LLM to identify, based on the specification, a first set of information required to register each given artificial user identity with the software application” ([0028] LLM can generate summaries for users of cybersecurity appliances.);
Lal does not appear to suggest, but Wang teaches “and generating, using the first sets of information, a registration test script to register the artificial user identities with the software application” ([page 7, lines 41-44] Application scene can test the registration page using test data that includes a user name, password, an email address, and so on.);
“and wherein testing the software application comprises executing the registration test script” ([page 9, lines 45-47] Test script generates a user registration page, and then obtains the corresponding test data.).
Therefore, one of ordinary skill in the art would have been capable of applying this known method of "generating, using the first sets of information, a registration test script to register the artificial user identities with the software application" and “wherein testing the software application comprises executing the registration test script” in a method for testing a software application and the results would have been predictable to one of ordinary skill in the art. The one of ordinary skill in the art would have been motivated to test the registration information so that if there is a deviation in the understanding of the test case for registering, the corresponding element mapping relationship may be caused to have an error (Wang [page 8, lines 21-23]).
Regarding claim 6, Lal in view of Jeevagunta, further in view of Wang teaches the limitations of claims 1 and 5 above. Lal discloses “promoting the LLM to identify, based on the specification” ([0028] LLM can generate summaries for users of cybersecurity appliances. [0036]-[0038] Cybersecurity system uses LLM to make decisions using vast amounts of context, and the cybersecurity system detects a login from an IP in Russia, as well as a location in Cambridge in the United Kingdom, with decisions to be made.);
Lal in view of Jeevagunta does not appear to suggest, but Wang teaches “a second set of information required to log each given artificial user identity into the software application” ([page 9, line 49-page 10, lines 7] Form data is submitted, and contains the user information to login to the website after registration.);
“and generating, using the second sets of information, a login test script to log the artificial user identities into the software application, wherein the second set comprises a subset of the first set” ([page 7, lines 41-44] Application scene can test the registration page using test data that includes a user name, password, an email address, and so on. [page 9, line 49-page 10, lines 7] Form data is submitted, and contains the user information to login to the website after registration, where form data corresponds to a subset of the test data.);
“and wherein testing the software application comprises executing the registration test script” ([page 9, lines 45-47] Test script generates a user registration page, and then obtains the corresponding test data.);
Therefore, one of ordinary skill in the art would have been capable of applying this known method of “a second set of information required to log each given artificial user identity into the software application”, “generating, using the second sets of information, a login test script to log the artificial user identities into the software application, wherein the second set comprises a subset of the first set”, and “wherein testing the software application comprises executing the registration test script” in a method for testing a software application and the results would have been predictable to one of ordinary skill in the art. The one of ordinary skill in the art would have been motivated so that when invalid information is entered, the user is informed of invalid entries or a failure to register the user or users (Wang [page 10, lines 8-14]).
Regarding claim 7, Lal in view of Jeevagunta, further in view of Wang teaches the limitations of claims 1 and 6 above. Lal in view of Jeevagunta does not appear to suggest, but Wang teaches “wherein the subset comprises a proper subset” ([page 9, line 49-page 10, lines 7] Form data is submitted, and contains the user information to login to the website after registration, where form data corresponds to a proper subset.);
Therefore, one of ordinary skill in the art would have been capable of applying this known method of "wherein the subset comprises a proper subset" in a method for testing a software application and the results would have been predictable to one of ordinary skill in the art. The one of ordinary skill in the art would have been motivated so that when invalid information is entered, the user is informed of invalid entries or a failure to register the user or users (Wang [page 10, lines 8-14]).
Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over Lal in view of Jeevagunta, further in view of Lashvicher as applied to claim 14 above, and further in view of Xu et al. (CN 117851259 A, using translation included in this Office Action), hereinafter “Xu”.
Regarding claim 15, Lal in view of Jeevagunta, further in view of Lashvicher teaches the limitation of claim 14 above. Lal in view of Jeevagunta, and further in view of Lashvicher does not appear to teach or suggest, but Xu teaches “wherein ranking the test scripts comprises identifying, for each of the consumer API endpoints, a primary key comprising a consumer operation selected from a list consisting of a GET operation, a POST operation, a PUT operation and a DELETE operation, and ranking the test scripts based on a primary key, wherein, in the primary keys, the ranking for a given script whose respective consumer operation comprises a GET operation is greater than a given script whose respective consumer operation comprises a POST operation, wherein the ranking for a given script whose respective consumer operation comprises a POST operation is greater than a given script whose respective consumer operation comprises a PUT operation, and wherein the ranking for a given script whose respective consumer operation comprises a PUT operation is greater than a given script whose respective consumer operation comprises a DELETE operation” ([page 11, lines 30-34] Flow of generating a test sequence, according to Fig. 7, is done according to a fixed template and CRUD semantics, such as (GET-POST-PUT-PATCH-DELETE) and is ordered to the resource identifier set RIColface, the order of the API operations is performed in sequence, which corresponds to a ranking of the operations.).
Therefore, one of ordinary skill in the art would have been capable of applying this known method of "wherein ranking the test scripts comprises identifying, for each of the consumer API endpoints, a primary key comprising a consumer operation selected from a list consisting of a GET operation, a POST operation, a PUT operation and a DELETE operation, and ranking the test scripts based on a primary key, wherein, in the primary keys, the ranking for a given script whose respective consumer operation comprises a GET operation is greater than a given script whose respective consumer operation comprises a POST operation, wherein the ranking for a given script whose respective consumer operation comprises a POST operation is greater than a given script whose respective consumer operation comprises a PUT operation, and wherein the ranking for a given script whose respective consumer operation comprises a PUT operation is greater than a given script whose respective consumer operation comprises a DELETE operation" in a method for testing a software application and the results would have been predictable to one of ordinary skill in the art. The one of ordinary skill in the art would have been motivated to ensure that API requests are performed in a sequence by “creating resources for subsequent API request operation templates OT, while at the same time data can be prepared for testing at the next stage, and then the cloned API request operation templates OT will be placed in the test sequence TS” (Xu [page 11, lines 36-39]).
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Lal in view of Jeevagunta, further in view of Lashvicher and Xu as applied to claim 15 above, further in view of Bosch et al. (US 20230229811 A1), hereinafter “Bosch”.
Regarding claim 16, Lal in view of Jeevagunta, further in view of Lashvicher and Xu teaches the limitation of claim 14 above. Lal in view of Jeevagunta, and further in view of Lashvicher and Xu does not appear to teach or suggest, but Bosch teaches “identifying a set of scripts having identical primary keys, identifying, for each of the producer API endpoints in the set, a secondary key comprising a producer operation selected from a list consisting of a POST operation, a GET operation, a PUT operation and a DELETE operation, and ranking the test scripts in the set based on the secondary key, wherein, in the secondary key, the ranking for a given script whose respective producer operation comprises a POST operation is greater than a given script whose respective producer operation comprises a GET operation, wherein the ranking for a given script whose respective producer operation comprises a GET operation is greater than a given script whose respective producer operation comprises a PUT operation, and wherein the ranking for a given script whose respective producer operation comprises a PUT operation is greater than a given script whose respective producer operation comprises a DELETE operation” ([0053]-[0058] CRUD semantics follow the order of POST, GET, PUT, and then DELETE, when utilizing the OpenAPI specifications for this service, as shown in paragraph [0058]. CRUD stands for "create", "read", "update", and "delete", respectively, as stated in paragraph [0044], where POST is in the create position, being greater than any other operation in this instance.);
Therefore, one of ordinary skill in the art would have been capable of applying this known method of "identifying a set of scripts having identical primary keys, identifying, for each of the producer API endpoints in the set, a secondary key comprising a producer operation selected from a list consisting of a POST operation, a GET operation, a PUT operation and a DELETE operation, and ranking the test scripts in the set based on the secondary key, wherein, in the secondary key, the ranking for a given script whose respective producer operation comprises a POST operation is greater than a given script whose respective producer operation comprises a GET operation, wherein the ranking for a given script whose respective producer operation comprises a GET operation is greater than a given script whose respective producer operation comprises a PUT operation, and wherein the ranking for a given script whose respective producer operation comprises a PUT operation is greater than a given script whose respective producer operation comprises a DELETE operation" in a method for testing a software application and the results would have been predictable to one of ordinary skill in the art. The one of ordinary skill in the art would have been motivated to add this into the invention of Xu above, as the sequence of commands in the CRUD format for the operations described is “first occurrence of an object reference is likely the result of a “create” operation, and subsequent operations are likely read, update, and delete operations”, so that objects created and managed by software and API services adhere to the CRUD model, especially when handling transactions such as in a pet store as shown in a table showing methods being executed using the API operations (Bosch [0051]-[0052]).
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Lal in view of Jeevagunta, further in view of Lashvicher, Xu, and Bosch as applied to claim 16 above, further in view of Khambay et al. (US 20180165070 A1), hereinafter “Khambay”.
Regarding claim 17, Lal in view of Jeevagunta, further in view of Lashvicher, Xu and Bosch teaches the limitation of claim 16 above. Lal in view of Jeevagunta, and further in view of Lashvicher, Xu and Bosch does not appear to teach or suggest, but Khambay teaches “wherein upon detecting one of the scripts comprising multiple producer endpoints, assigning a delete operation to the secondary key of detected script if any of the multiple producer endpoints in the detected script comprises any DELETE operations, assigning a PUT operation to the secondary key of detected script if any of the multiple producer endpoints in the detected script comprises any PUT operations and does not comprise any DELETE operations, assigning a POST operation to the secondary key of detected script if any of the multiple producer endpoints in the detected script comprises any POST operations and does not comprise any DELETE operations or any PUT operations, and assigning a GET operation to the secondary key of detected script if any of the multiple producer endpoints in the detected script comprises any GET operations and does not comprise any DELETE operations any PUT operations or any POST operations” ([0061] Fig. 6 performs the method of Fig. 5, and missing operations include POST, PUT, and DELETE endpoints in the generated service broker code for a service of a cloud platform. [0052] The broker code template includes a REST GET endpoint by default, with the other endpoints being added if the developer wishes to. However, in the event they are not added, only the operations which are used are counted.);
Therefore, one of ordinary skill in the art would have been capable of applying this known method of "wherein upon detecting one of the scripts comprising multiple producer endpoints, assigning a delete operation to the secondary key of detected script if any of the multiple producer endpoints in the detected script comprises any DELETE operations, assigning a PUT operation to the secondary key of detected script if any of the multiple producer endpoints in the detected script comprises any PUT operations and does not comprise any DELETE operations, assigning a POST operation to the secondary key of detected script if any of the multiple producer endpoints in the detected script comprises any POST operations and does not comprise any DELETE operations or any PUT operations, and assigning a GET operation to the secondary key of detected script if any of the multiple producer endpoints in the detected script comprises any GET operations and does not comprise any DELETE operations any PUT operations or any POST operations" in a method for testing a software application and the results would have been predictable to one of ordinary skill in the art. The one of ordinary skill in the art would have been motivated to provide code that fills in the gaps for the missing operations of the service broker code, such that if one or more of the REST API operations of “POST, PUT, and/or DELETE” operations are missing, the service broker can enable code customization for the code, and when an operation is added, an operation is added to the code, as shown in Figs. 4 and 5 (Khambay [0038], [0057]-[0058]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Agarwal et al. (US 20250322328 A1, “NEXT BEST AGENT SELECTION IN AN ADAPTIVE WORKFLOW”)
Zhang et al. (US 20130262934 A1, “METHOD AND APPARATUS FOR AUTOMATICALLY GENERATING A TEST SCRIPT FOR A GRAPHICAL USER INTERFACE”)
O'DELL et al. (US 20230088655 A1, “AUTOMATIC NON-CODE TEST SUITE GENERATION FROM API SPECIFICATION”)
Moon et al. ("A probabilistic model for API contract specification retrieval focusing on the openAPI standard", 2025, NPL)
Pasca et al. ("Enhancing API Security Testing Against BOLA and Authentication Vulnerabilities Through an LLM-Enhanced Framework", 2024, NPL)
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TOMMY MARTINEZ whose telephone number is (703)756-5651. The examiner can normally be reached Monday thru Friday 8AM-4PM ET.
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, Jorge L. Ortiz-Criado can be reached at (571) 272-7624 on Monday thru Friday 7AM-7PM ET. 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.
/T.M./ Examiner, Art Unit 2496
/JORGE L ORTIZ CRIADO/ Supervisory Patent Examiner, Art Unit 2496
Prosecution Insights