Prosecution Insights
Last updated: July 17, 2026
Application No. 18/180,313

Computer-Implemented Registration Authority, System and Method for Issuing a Certificate

Non-Final OA §103
Filed
Mar 08, 2023
Priority
Mar 10, 2022 — EU 22161420
Examiner
LE, CANH
Art Unit
2439
Tech Center
2400 — Computer Networks
Assignee
Siemens Aktiengesellschaft
OA Round
3 (Non-Final)
73%
Grant Probability
Favorable
3-4
OA Rounds
4m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 73% — above average
73%
Career Allowance Rate
308 granted / 421 resolved
+15.2% vs TC avg
Strong +72% interview lift
Without
With
+72.4%
Interview Lift
resolved cases with interview
Typical timeline
3y 9m
Avg Prosecution
15 currently pending
Career history
449
Total Applications
across all art units

Statute-Specific Performance

§101
0.5%
-39.5% vs TC avg
§103
95.5%
+55.5% vs TC avg
§102
3.0%
-37.0% vs TC avg
§112
0.8%
-39.2% vs TC avg
Black line = Tech Center average estimate • Based on career data from 421 resolved cases

Office Action

§103
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 . DETAILED ACTION Continued Examination Under 37 CFR 1.114 A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant’s submission filed on 03/09/2026 has been entered. This Office Action is in response to the communication and claim amendment filed on 02/23/2026. Claims 1, 7, 13, and 15 have been amended; claim 2 have been canceled. Claim 1, 13, and 15 are independent claims. Claims 1 and 3-15 have been examined and are pending. This Action is made Non-FINAL Information Disclosure Statement The information disclosure statement (IDS), submitted on 03/13/2026 is being considered by the examiner. Response Arguments The objection to drawings (figures 1-2) is maintained. Applicant indicates that replacement drawings were submitted; however, no drawings were found in 02/23/2026. Applicant is invited to resubmit the replacement drawings. The rejection of claim 2 under 35 U.S.C. § 112(d) is withdrawn as the claim has been canceled. Applicants’ arguments in the instant Amendment, filed on 02/23/2026., with respect to limitations listed below, have been fully considered but they are not persuasive. Applicants argue: Evanitsky fails to teach or suggest the conditional submission of a certificate application to a registration authority (Applicant Remarks /Arguments, pages 9-12) The Examiner respectfully disagrees with the Applicants. Applicant's argument improperly attacks Evanitsky individually. The rejection relies on the combined teachings of Lutz, Gunjal, and Evanitsky. Lutz already teaches a device/application transmitting a certificate request (CSR) to a local registration service (i.e., a registration authority). Gunjal teaches automated certificate checking.Evanitsky is relied upon solely for the additional teaching that a device performs a self-assessment and determines, based upon the assessment result, whether to proceed with a requested action. Thus, Evanitsky supplies the missing concept that subsequent communication/request behavior is conditioned upon successful completion of a device-side assessment. The Examiner respectfully submits that the combination ofLutz, Gunjal, and Evanitsky discloses the aforementioned limitations as follows: The Examiner respectfully submits that the combination of Lutz, Gunjal, and Evanitsky does disclose the aforementioned limitations as the following: Under the broadest reasonable interpretation, the limitation requires that the plant component only SUBMITS (i.e., proceeds with) the certificate application when the check is successful. The claim does NOT preclude the component from taking other actions (such as generating an error, logging the failure, or sending a negative response) when the check fails. Evanitsky teaches at paragraph [0050]: "if the device(s) cannot meet the job requirements, then the device(s) send a negative response...if the self-assessment indicates that the device can perform the job...then a positive response can be automatically sent" In Evanitsky, the device ONLY PROCEEDS with accepting/performing the job when the self-assessment is successful (positive response). When the self-assessment fails, the device does NOT proceed with the job (negative response = rejection/declining the job). The "positive response" in Evanitsky corresponds to proceeding with the request (analogous to submitting the certificate application). The "negative response" in Evanitsky corresponds to NOT proceeding (analogous to not submitting the certificate application). In the combination with Lutz's certificate management system: PASS self-assessment → positive response → submit CSR (proceed) FAIL self-assessment → negative response → do NOT submit CSR This is precisely the gating behavior required by limitation (a1). The fact that Evanitsky's device sends a "negative response" when the check fails does not negate the teaching. The claim language "only submits... in an event of... successful" means: IF successful → submit IF not successful → do not submit The claim does NOT require silence upon failure. The claim only requires that submission is CONDITIONED on success, which Evanitsky clearly teaches. It is clear that the combination of Lutz, Gunjal, and Evanitsky as a whole does teach the aforementioned the aforementioned limitations. The Examiner respectfully suggests that the claim be further amended; details in the specification be incorporated, to distinguish the claimed invention over prior art of record. Should the Applicant desire an interview to further clarify the claim interpretation/rejections, please contact the Examiner at (571) 270 1380 to schedule an interview. Drawings The drawings are objected to because they are not informative, Block diagram and flowchart of figures 1-2 should include texts to describe names and/or labels of each block/box. Corrected drawing sheets in compliance with 37 CFR 1.121(d) 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. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. 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. Claim Interpretation The following is a quotation of 35 U.S.C. 112(f): (f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof. The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph: An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof. Regarding claims 13-15, The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked. As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph: (A) the claim limitation uses the term "means" or "step" or a term used as a substitute for "means" that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function; (B) the term "means" or "step" or the generic placeholder is modified by functional language, typically, but not always linked by the transition word "for" (e.g., "means for") or another linking word or phrase, such as "configured to" or "so that"; and (C) the term "means" or "step" or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function. Use of the word "means" (or "step") in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function. Absence of the word "means" (or "step") in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function. Claim limitations in this application that use the word "means" (or "step") are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word "means" (or "step") are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. This application includes one or more claim limitations that do not use the word "means," but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “registration authority [] receives /checks / transmits / performs …” recited in claims 13-14; “the system is configured to performs” and “the certification authority which [] issues” recited in claim 15. Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof. If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. 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-2, 6, 8-9, 13-14, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Lutz et al. (“Lutz,” US 2018/0322274) in view of Gunjal et al. (“Gunjal,” US 2023/0112261), further in view of Evanitsky (“Evanitsky,” US 2012/0127511) Regarding claim 1, Lutz teaches a method for issuing a certificate with a specific certificate profile to a plant component of an industrial plant by a certification authority of the industrial plant (Lutz: par. 0017, As a result, the certificates can be allocated still more specifically to the individual devices/applications, whereby the overall number of certificates to be allocated can be reduced; par. 0018, In the event of the check being successful, the local registration service can forward the request to a certification body or “Certification Authority” (CA), which issues an operating certificate for the devices/applications and provides it to the local registration service. The local registration service then forwards the operating certificate to the respective device or application), before a certificate application of a certification made by the plant component is transmitted to the certification authority (Lutz: par.0036, To this end, the devices/applications 8 send a request 21 for creation of a certificate or "Certificate Signing Request" (CSR). The request from the devices or applications 8 is forwarded via the registration service 18 of the local registration service 17 of the Engineering System 2 to the Certification Authority 5; par. 0039), the method comprising: performing check to determine whether the specific certificate profile is usable by the plant component Lutz: par. 0037, Here, local registration service 17 of the Engineering System 2 initially checks, with the assistance of information from the Inventory 10 of the Process Historian 3, which devices/applications 5 are registered as trustworthy communication participants and the certificates to which the devices/applications 8 are entitled. This presupposes that the protocols and applications that are actively supported by the devices / applications 8 integrated in the industrial plant are stored in the Inventory 10. This check has the consequence that only those certificates that are required for use of a specific protocol, such as HTTPS, Secure Syslog or Open Platform Communications Unified Architecture ( OPC UA), or for use of a specific application are provided to each device or application 8; par. 0017, the local registration service checks whether the devices/applications make active use of the communication relationships between the individual participants and thus also actually require the corresponding certificates; par. 0012, “certificates that are required for use of specific protocol”; par, 0017, “certificates can be allocated still more specifically to individual devices/applications”), and performing a check to determine whether may be assigned the specific certificate profile in the industrial plant is assignable to the plant component (Lutz: par. 0038, The local registration service 17 of the Engineering System 2 then additionally checks whether the devices or applications 8 also actually require the certificates which they support in principle. To this end, the configuration service 19 of the local registration service 17 of the Engineering System 2 determines a network configuration of the industrial plant, including the communication relationships between individual components of the industrial plant, and checks whether the devices/applications 8 also make active use of the communication relationships and thus also actually require the corresponding certificates; par. 0015, check...which operating certificate can be assigned to the respective device" ; par. 0017, As a result, the certificates can be allocated still more specifically to the individual devices/applications, whereby the overall number of certificates to be allocated can be reduced; pars. 0012, 0017; par. 0038: Assignment decisions based on "network configuration" and "communication relationships") ; wherein, in an event both checks are successful, the certificate application is transmitted to the certification authority which, in an event of a successful check of the certificate application, issues a requested certificate with the specific certificate profile for the plant component (Lutz: par. 0039, Only if the check is successful does the local registration service 17 of the Engineering System 2 obtain the corresponding certificate on behalf of each device or application 8 via a corresponding Certification Signing Request 22 and an assignment 23 from the Certification Authority 5. The certificate is finally transferred by the distribution service 20 of the local registration service 17 of the Engineering System 2 via an assignment 24 to the respective devices/applications 8. The certificates are thus only assigned as required, thereby distinctly reducing the volume of communication generated by certificate management; par. 0064, The Certification Authority 5 checks whether the certificate request originates from a trustworthy local registration service 11 and, if so, provides the distribution service 15 with an operating certificate for the newly added replacement device 8; see also pars. 0042-0043). Lutz teaches “perform check to determine whether the specific certificate profile is usable by the plant component” but does not explicit disclose “automated checking.” However, in an analogous art, Gunjal teaches automated certificate validation process in micro automation codes (Gunjal: par. 0020, “micro automation codes that operate to automatically gather and check the certificate ...; See also pars. 0029, 0024, 0051, 0062). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Gunjal with the method and system of Lutz to include perform automated check to determine whether the specific certificate profile. One would have been motivated to reduce manual workload and improve validation accuracy. The combination of Lutz and Gunjal teaches wherein said check to determine whether the specific certificate profile is useable by the plant component is performed by the plant component in an automated manner and send to local registration service (Lutz: par. 0017: par. 0017, the local registration service checks whether the devices /applications make active use of the communication relationships between the individual participants and thus also actually require the corresponding certificates) but does not explicitly disclose “such that the plant component only submits a certificate application to a registration authority in the event of the automated check being successful.” However, in an analogous art, Evanitsky discloses component self-assessment (Evanitsky: Abstract, "A device can perform a self-assessment based on particular criteria"; par. [0050], "the device(s) can be instructed to automatically determine whether or not they can meet the job ticket requirements") with conditional request behavior (Evanitsky: Abstract, "A device can perform a self-assessment...and then determine, based on such criteria, whether to request assistance"; par. [0050], "if the device(s) cannot meet the job requirements, then the device(s) send a negative response...if the self-assessment indicates that the device can perform the job...then a positive response can be automatically sent") Therefore, it would have been obvious to one skilled in the art to modify the certificate validation system of Lutz and Gunjal to include Evanitsky 's component self-assessment and conditional request approach. One would have been motivated to implement such self-validation because Evanitsky demonstrates that device self-assessment reduces network traffic and improves system efficiency by preventing inappropriate service requests (Evanitsky: Abstract, provides "workload balancing" and "re-routing" capabilities). Applying this self-filtering approach to certificate management would provide the predictable benefit of reducing unnecessary certificate requests and improving overall system efficiency. Regarding claim 6, the combination of Lutz, Gunjal, and Evanitsky teaches the method as claimed in claim 1. The combination of Lutz, Gunjal, and Evanitsky further discloses, wherein said checks to determine whether the specific certificate profile is usable by the plant component (Lutz: par. 0037, Here, local registration service 17 [i.e. registration authority] of the Engineering System 2 initially checks, with the assistance of information from the Inventory 10 of the Process Historian 3, which devices/applications 5 are registered as trustworthy communication participants and the certificates to which the devices/applications 8 are entitled. This presupposes that the protocols and applications that are actively supported by the devices/applications 8 integrated in the industrial plant are stored in the Inventory 10. This check has the consequence that only those certificates that are required for use of a specific protocol, such as HTTPS, Secure Syslog or Open Platform Communications Unified Architecture ( OPC UA), or for use of a specific application are provided to each device or application 8; par. 0017, the local registration service checks whether the devices/applications make active use of the communication relationships between the individual participants and thus also actually require the corresponding certificates; par. 0012, “certificates that are required for use of specific protocol”; par, 0017, “certificates can be allocated still more specifically to individual devices/applications”) and to determine whether the specific certificate profile in the industrial plant is assignable to the plant component are performed by the registration authority of the industrial plant (Lutz: par. 0038, The local registration service 17 of the Engineering System 2 then additionally checks whether the devices or applications 8 also actually require the certificates which they support in principle. To this end, the configuration service 19 of the local registration service 17 of the Engineering System 2 determines a network configuration of the industrial plant, including the communication relationships between individual components of the industrial plant, and checks whether the devices/applications 8 also make active use of the communication relationships and thus also actually require the corresponding certificates; par. 0015, par. 0017, As a result, the certificates can be allocated still more specifically to the individual devices/applications, whereby the overall number of certificates to be allocated can be reduced; pars. 0012, 0017). wherein the registration authority performs the checks in response to the certificate application addressed to the registration authority by the plant component (Lutz: pars. 0037-0038, Local registration service performs both check); and wherein the registration authority only transmits the certificate application to the certification authority in the event of both checks being successful (Lutz: par. 0039, Only if the check is successful does the local registration service 17 of the Engineering System 2 obtain the corresponding certificate on behalf of each device or application 8 via a corresponding Certification Signing Request 22 and an assignment 23 from the Certification Authority 5. The certificate is finally transferred by the distribution service 20 of the local registration service 17 of the Engineering System 2 via an assignment 24 to the respective devices/applications 8. The certificates are thus only assigned as required, thereby distinctly reducing the volume of communication generated by certificate management; par. 0064, The Certification Authority 5 checks whether the certificate request originates from a trustworthy local registration service 11 and, if so, provides the distribution service 15 with an operating certificate for the newly added replacement device 8; see also pars. 0042-0043). Regarding claim 8, the combination of Lutz, Gunjal, and Evanitsky teaches the method as claimed in claim 1. The combination of Lutz, Gunjal, and Evanitsky further teaches, wherein said check to determine whether the specific certificate profile in the industrial plant is assignable to the plant component occurs based on specifications from an operator (Lutz: par. 0014, the information may be read from an engineering component, i.e., an Engineering Station (ES), of the control system; par. 0050, operators of the control system 1 or maintenance personnel are notified via a corresponding output in "Alarm Controls" of the Clients 7 to subsequently take appropriate action; par. 0024). Regarding claim 9, the combination of Lutz, Gunjal, and Evanitsky teaches the method as claimed in claim 1. The combination of combination of Lutz, Gunjal, and Evanitsky further teaches, wherein said check to determine whether the specific certificate profile in the industrial plant is assignable to the plant component occurs based on automation of the industrial plant (Lutz: par. 0037, the basis for test include information on automation of the system from the “inventory 10”; pars. 0055, reflected in the Operator System Server 4 by the configuration process 27 of the runtime environment 28; pars. 0055-0065). Regarding claim 13, Lutz teaches a computer-implemented registration authority for a control system of an industrial plant, comprising: a processor (Lutz: par. 0004, Automated management of operating certificates is conventionally achieved in the context of a plant using a standard protocol, such as the Certificate Management Protocol (CMP). Here, devices and applications request the necessary operating certificates on a situational basis from a local registration service known as the Local Registration Authority (LRA); par. 0034, local registration service known as Local Registration Authority (LRA); par. 0034, The local registration service 11 further comprises a local data memory 17; par. 0032, processor and memory; par. 0035, local registration service 17); and memory (Lutz: par. 0004, Automated management of operating certificates is conventionally achieved in the context of a plant using a standard protocol, such as the Certificate Management Protocol (CMP). Here, devices and applications request the necessary operating certificates on a situational basis from a local registration service known as the Local Registration Authority (LRA); par. 0034, local registration service known as Local Registration Authority (LRA); par. 0034, The local registration service 11 further comprises a local data memory 17; par. 0032, processor and memory; par. 0035, local registration service 17); wherein the registration authority receives from a plant component of the industrial plant a certificate application submitted by the plant component and, before transmission of the certificate application to a certificate authority of the industrial plant (Lutz: par.0036, To this end, the devices/applications 8 send a request 21 for creation of a certificate or "Certificate Signing Request" (CSR) The request from the devices or applications 8 is forwarded via the registration service 18 of the local registration service 17 of the Engineering System 2 to the Certification Authority 5), checks whether a specific certificate profile usable by the plant component (Lutz: par. 0037, Here, local registration service 17 of the Engineering System 2 initially checks, with the assistance of information from the Inventory 10 of the Process Historian 3, which devices/applications 5 are registered as trustworthy communication participants and the certificates to which the devices/applications 8 are entitled. This presupposes that the protocols and applications that are actively supported by the devices/applications 8 integrated in the industrial plant are stored in the Inventory 10. This check has the consequence that only those certificates that are required for use of a specific protocol, such as HTTPS, Secure Syslog or Open Platform Communications Unified Architecture ( OPC UA), or for use of a specific application are provided to each device or application 8; par. 0017, the local registration service checks whether the devices/applications make active use of the communication relationships between the individual participants and thus also actually require the corresponding certificates; As a result, the certificates can be allocated still more specifically to the individual devices/applications, whereby the overall number of certificates to be allocated can be reduced; par. 0012, “certificates that are required for use of specific protocol”; par, 0017, “certificates can be allocated still more specifically to individual devices/applications”) and whether the specific certificate profile in the industrial plant is assignable to the plant component (Lutz: par. 0038, The local registration service 17 of the Engineering System 2 then additionally checks whether the devices or applications 8 also actually require the certificates which they support in principle. To this end, the configuration service 19 of the local registration service 17 of the Engineering System 2 determines a network configuration of the industrial plant, including the communication relationships between individual components of the industrial plant, and checks whether the devices/applications 8 also make active use of the communication relationships and thus also actually require the corresponding certificates; par. 0015; Lutz: par. 0017, As a result, the certificates can be allocated still more specifically to the individual devices/applications, whereby the overall number of certificates to be allocated can be reduced; pars. 0012, 0017); and wherein the registration authority, in an event of both checks being successful, transmits the certificate application to the certification authority (Lutz: par. 0039, Only if the check is successful does the local registration service 17 of the Engineering System 2 obtain the corresponding certificate on behalf of each device or application 8 via a corresponding Certification Signing Request 22 and an assignment 23 from the Certification Authority 5. The certificate is finally transferred by the distribution service 20 of the local registration service 17 of the Engineering System 2 via an assignment 24 to the respective devices/applications 8. The certificates are thus only assigned as required, thereby distinctly reducing the volume of communication generated by certificate management []; see also pars. 0042-0043). Lutz teaches “checks whether a specific certificate profile usable by the plant component” but does not explicitly teach “automated checking.” However, in an analogous art, Gunjal teaches automated certificate validation process in micro automation codes (Gunjal: par. 0020, “micro automation codes that operate to automatically gather and check the certificate ..; See also pars. 0029, 0024, 0051, 0062). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Gunjal with the method and system of Lutz to include “checks whether the specific certificate profile usable by the plant component.” One would have been motivated to reduce manual workload and improve validation accuracy. The combination of Lutz and Gunjal teaches “checks in an automated manner whether a specific certificate profile usable by the plant component and whether the specific certificate profile in the industrial plant is assignable to the plant component in an automated manner and send to local registration service (Lutz: par. 0017) but does not explicitly disclose “such that the plant component only sends a certificate application in the event of the automated check being successful.” However, in an analogous art, Evanitsky discloses component self-assessment (Evanitsky: Abstract, "A device can perform a self-assessment based on particular criteria"; par. [0050], "the device(s) can be instructed to automatically determine whether or not they can meet the job ticket requirements") with conditional request behavior (Evanitsky: Abstract, "A device can perform a self-assessment...and then determine, based on such criteria, whether to request assistance"; par. [0050], "if the device(s) cannot meet the job requirements, then the device(s) send a negative response...if the self-assessment indicates that the device can perform the job...then a positive response can be automatically sent") Therefore, it would have been obvious to one skilled in the art to modify the certificate validation system of Lutz and Gunjal to include Evanitsky 's component self-assessment and conditional request approach. One would have been motivated to implement such self-validation because Evanitsky demonstrates that device self-assessment reduces network traffic and improves system efficiency by preventing inappropriate service requests (Evanitsky: Abstract, provides "workload balancing" and "re-routing" capabilities). Applying this self-filtering approach to certificate management would provide the predictable benefit of reducing unnecessary certificate requests and improving overall system efficiency. Regarding claim 14, the combination of Lutz, Gunjal, and Evanitsky teaches the computer-implemented registration authority as claimed in claim 13. Lutz teaches wherein the computer-implemented registration authority is configured to perform the check to determine whether the specific certificate profile in the industrial plant is assignable to the component based on specifications from at least one of (i) an operator (Lutz: par. 0014, the information may be read from an engineering component, i.e., an Engineering Station (ES), of the control system; par. 0050, operators of the control system 1 or maintenance personnel are notified via a corresponding output in "Alarm Controls" of the Clients 7 to subsequently take appropriate action; par. 0024) and (ii) automation of the industrial plant. Regarding claim 15, Lutz teaches a system comprising: a computer-implemented registration authority including a processor and memory (Lutz: par. 0004, Automated management of operating certificates is conventionally achieved in the context of a plant using a standard protocol, such as the Certificate Management Protocol (CMP). Here, devices and applications request the necessary operating certificates on a situational basis from a local registration service known as the Local Registration Authority (LRA); par. 0034, local registration service known as Local Registration Authority (LRA); par. 0034, The local registration service 11 further comprises a local data memory 17; par. 0032, processor and memory; pars. 0034, 0035, local registration service 17); a certification authority (Lutz: par. 0032, Certificate authority 5); and at least one plant component (Lutz: par. 0033, device 8 is connected via a plant bus 9 to the Operator System Server 4. Here, the connected device 8 may alternatively also be an application, in particular a web application. For the purposes of the invention, any desired number of devices and/or applications can be connected to the Operator System Server 4; par. 0013, the devices and/or applications authenticate themselves to the local registration service upon start-up of the industrial plant to register themselves as trustworthy communication participants in the industrial plant. The devices and/or applications can also be authenticated at runtime of the industrial plant. This may be necessary if devices or applications are replaced during runtime of the industrial plant); wherein, before a certificate application of a certification made by the plant component is transmitted to the certification authority (Lutz: par.0036, To this end, the devices/applications 8 send a request 21 for creation of a certificate or "Certificate Signing Request" (CSR) The request from the devices or applications 8 is forwarded via the registration service 18 of the local registration service 17 of the Engineering System 2 to the Certification Authority 5. Note that certificate application is known as CSR) the system: performs a check to determine whether a specific certificate profile is usable by the plant component (Lutz: par. 0037, Here, local registration service 17 of the Engineering System 2 initially checks, with the assistance of information from the Inventory 10 of the Process Historian 3, which devices/applications 5 are registered as trustworthy communication participants and the certificates to which the devices/applications 8 are entitled. This presupposes that the protocols and applications that are actively supported by the devices/applications 8 integrated in the industrial plant are stored in the Inventory 10. This check has the consequence that only those certificates that are required for use of a specific protocol, such as HTTPS, Secure Syslog or Open Platform Communications Unified Architecture ( OPC UA), or for use of a specific application are provided to each device or application 8; par. 0017, the local registration service checks whether the devices/applications make active use of the communication relationships between the individual participants and thus also actually require the corresponding certificates; par. 0012, “certificates that are required for use of specific protocol”; par, 0017, “certificates can be allocated still more specifically to individual devices/applications”), and performs a check to determine whether the specific certificate profile in the industrial plant is assignable to the plant component (Lutz: par. 0038, The local registration service 17 of the Engineering System 2 then additionally checks whether the devices or applications 8 also actually require the certificates which they support in principle. To this end, the configuration service 19 of the local registration service 17 of the Engineering System 2 determines a network configuration of the industrial plant, including the communication relationships between individual components of the industrial plant, and checks whether the devices/applications 8 also make active use of the communication relationships and thus also actually require the corresponding certificates; par. 0015, Lutz: par. 0017, As a result, the certificates can be allocated still more specifically to the individual devices/applications, whereby the overall number of certificates to be allocated can be reduced; pars. 0012, 0017); wherein, in an event both checks are successful, the certificate application is transmitted to the certification authority which, in an event of a successful check of the certificate application, issues a requested certificate with the specific certificate profile for the plant component (Lutz: par. 0039, Only if the check is successful does the local registration service 17 of the Engineering System 2 obtain the corresponding certificate on behalf of each device or application 8 via a corresponding Certification Signing Request 22 and an assignment 23 from the Certification Authority 5. The certificate is finally transferred by the distribution service 20 of the local registration service 17 of the Engineering System 2 via an assignment 24 to the respective devices/applications 8. The certificates are thus only assigned as required, thereby distinctly reducing the volume of communication generated by certificate management; par. 0064, The Certification Authority 5 checks whether the certificate request originates from a trustworthy local registration service 11 and, if so, provides the distribution service 15 with an operating certificate for the newly added replacement device 8; see also pars. 0042-0043). Lutz teaches “performs a check to determine whether the specific certificate profile is usable by the plant component but does not explicit disclose “automated checking.” However, in an analogous art, Gunjal teaches automated certificate validation process in micro automation codes (Gunjal: par. 0020, “micro automation codes that operate to automatically gather and check the certificate ..; See also pars. 0029, 0024, 0051, 0062). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Gunjal with the method and system of Lutz to include “performs automated check to determine whether the specific certificate profile.” One would have been motivated to reduce manual workload and improve validation accuracy. The combination of Lutz and Gunjal teaches “checks int an automated manner whether a specific certificate profile usable by the plant component in an automated manner and send to local registration service (Lutz: par. 0017) but does not explicitly disclose “such that the plant component only submits a certificate application in the event of the automated check being successful.” However, in an analogous art, Evanitsky discloses component self-assessment (Evanitsky: Abstract, "A device can perform a self-assessment based on particular criteria"; par. [0050], "the device(s) can be instructed to automatically determine whether or not they can meet the job ticket requirements") with conditional request behavior (Evanitsky: Abstract, "A device can perform a self-assessment...and then determine, based on such criteria, whether to request assistance"; par. [0050], "if the device(s) cannot meet the job requirements, then the device(s) send a negative response...if the self-assessment indicates that the device can perform the job...then a positive response can be automatically sent"). Therefore, it would have been obvious to one skilled in the art to modify the certificate validation system of Lutz and Gunjal to include Evanitsky 's component self-assessment and conditional request approach. One would have been motivated to implement such self-validation because Evanitsky demonstrates that device self-assessment reduces network traffic and improves system efficiency by preventing inappropriate service requests (Evanitsky: Abstract, provides "workload balancing" and "re-routing" capabilities). Applying this self-filtering approach to certificate management would provide the predictable benefit of reducing unnecessary certificate requests and improving overall system efficiency. Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Lutz et al. (“Lutz,” US 2018/0322274) in view of Gunjal et al. (“Gunjal,” US 2023/0112261), and Evanitsky (“Evanitsky,” US 2012/0127511), and further in view of Chhuor et al. (“Chhuor,” US 2021/0334382) Regarding claim 3, the combination of Lutz, Gunjal, and Evanitsky teaches the method as claimed in claim 1. The combination of Lutz, Gunjal, and Evanitsky teaches, wherein the plant component performs the check to determine whether the specific certificate profile useable by the plant component in an automated manner but does not explicitly disclose “based on information previously deposited on the plant component by one of (i) a manufacturer of the plant component, (ii) an original equipment manufacturer of the plant component and (iii) an operator of the industrial plant.” However, in an analogous art, Chhuor discloses Information previously deposited by manufacturer (Chhuor: par. [0037], "the computing apparatus may be pre-configured by the manufacturer (e.g., in the factory) with data even before the computing apparatus is shipped out of the factory...The manufacturer is a trusted party and may thus be required by the customer to pre-configure the computing apparatus with specific data and/or settings"). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the component self-assessment system of Lutz, Gunjal, and Evanitsky to use pre-configured capability data as taught by Chhuor. One would have been motivated to implement manufacturer pre-configuration because Chhuor demonstrates that pre-configuring devices with specific data enables customization to customer needs and ensures trusted party control over device capabilities (Chhuor: par. [0037]). Applying this pre-configuration approach to certificate capability data would provide the predictable benefit of reliable, manufacturer-verified capability information for component self-assessment, eliminating the need for real-time capability lookup and ensuring accurate self-validation decisions. Claims 4-5 are rejected under 35 U.S.C. 103 as being unpatentable over Lutz et al. (“Lutz,” US 2018/0322274) in view of Gunjal et al. (“Gunjal,” US 2023/0112261), and Evanitsky (“Evanitsky,” US 2012/0127511), and Chhuor et al. (“Chhuor,” US 2021/0334382), and further in view of Armolavicius et al, (“Armolavicius,” US 2016/0182329) Regarding claim 4, the combination of Lutz, Gunjal, Evanisky, and Chhuor teaches the method as claimed in claim 3. The combination of Lutz, Gunjal, Evanisky, and Chhuor teaches wherein the information previously deposited on the plant component but does not explicit disclose “is updated on a regular or event-controlled basis; and “wherein the update is triggerable by an operator of the industrial plant or occurs in an automated manner.” However, in an analogous art, Armolavicius discloses Regular or event-controlled updates (Armolavicius: par. [0054], "scheduled trigger (periodicity is set by the operator e.g. monthly, weekly, daily, hourly)" for regular updates; "network configuration or capacity changes; introduction of new nodes or links...various congestion state triggers" for event-controlled updates) Operator-triggered or automated updates (Armolavicius: par. [0054], "manual trigger by network operator" for operator initiation; triggers including congestion detection, utilization thresholds) Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the capability information management system of Lutz, Gunjal, Evanitsky, and Chhuor to include Armolavicius's dynamic update mechanisms. One would have been motivated to implement such updating capability because Armolavicius demonstrates that both scheduled and event-driven updates enable systems to respond to changing network conditions and maintain optimal performance (Armolavicius: par. [0054]). Applying this update management approach to component capability information would provide the predictable benefit of keeping device specifications current as firmware updates occur, security requirements change, and plant configurations evolve, ensuring accurate self-assessment decisions throughout the device lifecycle (KSR, predictable results). Regarding claim 5, the combination of Lutz, Gunjal, Evanistsky, Chhuor, and Armolavicius eaches the method as claimed in claim 4. The combination of Lutz, Gunjal, Evanistsky, and Chhuor, and Armolavicius further discloses, wherein the information previously deposited on the plant component is updated in an event of a functional expansion of the plant component (Chhuor: par. 0054, network configuration or capacity changes: introduction pf new nodes or links). Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Lutz et al. (“Lutz,” US 2018/0322274) in view of Gunjal et al. (“Gunjal,” US 2023/0112261), and Evanitsky (“Evanitsky,” US 2012/0127511), further in view Seifert et al. (“Seifert,” US 6,505,170) Regarding claim 7, the combination of Lutz, Gunjal, and Evanitsky teaches the method as claimed in claim 1. The combination of Lutz, Gunjal, and Evanitsky further discloses, wherein said check to determine whether the specific certificate profile is useable by the plant component is performed by the plant component in an automated manner such that the plant component only submits a certificate application to the registration authority in the event of the check being successful (Lutz: par. 0037, 0017; Gunjal: par. 0020, “micro automation codes that operate to automatically gather and check the certificate ..; See also pars. 0029, 0024, 0051, 0062; Evanitsky: Abstract, "A device can perform a self-assessment based on particular criteria"; par. [0050], "the device(s) can be instructed to automatically determine whether or not they can meet the job ticket requirements") with conditional request behavior (Evanitsky: Abstract, "A device can perform a self-assessment...and then determine, based on such criteria, whether to request assistance"; par. [0050], "if the device(s) cannot meet the job requirements, then the device(s) send a negative response...if the self-assessment indicates that the device can perform the job...then a positive response can be automatically sent"). wherein said checks to determine whether the specific certificate profile is usable by the plant component (Lutz: para. 0037; pars. 0012, 0017) and to determine whether the specific certificate profile in the industrial plant is assignable to the plant component are performed by a registration authority of the industrial plant (Lutz: para. 0038; par. 0015; pars. 0012, 0017); wherein the registration authority performs the checks in response to the certificate application addressed to the registration authority by the plant component (Lutz: pars. 0037-0038, Local registration service performs both check); wherein the registration authority only transmits the certificate application to the certification authority in the event of both checks being successful (Lutz: par. 0039, Only if the check is successful does the local registration service 17 of the Engineering System 2 obtain the corresponding certificate on behalf of each device or application 8 via a corresponding Certification Signing Request 22 and an assignment 23 from the Certification Authority 5. The certificate is finally transferred by the distribution service 20 of the local registration service 17 of the Engineering System 2 via an assignment 24 to the respective devices/applications 8. The certificates are thus only assigned as required, thereby distinctly reducing the volume of communication generated by certificate management; par. 0064, The Certification Authority 5 checks whether the certificate request originates from a trustworthy local registration service 11 and, if so, provides the distribution service 15 with an operating certificate for the newly added replacement device 8; see also pars. 0042-0043; Evanitsky: Abstract, "A device can perform a self-assessment based on particular criteria"; par. [0050], "the device(s) can be instructed to automatically determine whether or not they can meet the job ticket requirements") with conditional request behavior (Evanitsky: Abstract, "A device can perform a self-assessment...and then determine, based on such criteria, whether to request assistance"; par. [0050], "if the device(s) cannot meet the job requirements, then the device(s) send a negative response...if the self-assessment indicates that the device can perform the job...then a positive response can be automatically sent"); The combination of Lutz, Gunjal, and Evanitsky teaches wherein said check to determine whether the specific certificate profile is useable by the plant component is performed by the plant component in an automated manner such that the plant component only submits a certificate application in the event of the check being successful but does not explicitly disclose “wherein the plant component notifies the registration authority that said check to determine whether the specific certificate profile is usable by the plant component has been successfully performed by the plant component itself.” However, in an analogous art, Seifert discloses component notification of self-check results (Seifert: Col. 13, lines 30-34, In some embodiments of the present invention, the POS device performs a periodic self-check and sends a status report to the host computer. The scheduler of the self-check and/or status report preferably are alterable by the host compute). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement Seifert’s status reporting mechanism in the system of Lutz, Gunjal, and Evanitsky to include wherein the plant component notifies the registration authority that said check to determine whether the specific certificate profile is usable by the plant component has been successfully performed by the plant component itself. One would have been motivated to have components communicate their self-assessment results to the managing system to provide visibility into the validation process and enable system coordination. Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Lutz et al. (“Lutz,” US 2018/0322274) in view of Gunjal et al. (“Gunjal,” US 2023/0112261), and Evanitsky (“Evanitsky,” US 2012/0127511, further in view of Dittmer et al. (“Dittmer,” US 2021/0149384) Regarding claim 10, the combination of Lutz, Gunjal, and Evanitsky teaches the method as claimed in claim 9. Lutz, Gunjal, and Evanitsky do not explicitly disclose, wherein changes to the automation of the industrial plant are captured by a system based on machine learning; and wherein the system automatically adapts a basis for the check to determine whether the specific certificate profile in the industrial plant is assignable to the plant component when necessary. However, in an analogous art, Dittmer discloses changes to the automation of the industrial plant are captured by a system based on machine learning (Dittmer: par. 0062, Based on the data gleaned from the machine learning component 142, the aggregate monitoring system 40may better assess the operating status (e.g., healthy, low memory, increased lag time) of the related industrial components 62; par. 0034, The PLC 58 may be an industrial solid-state computer that monitors inputs and outputs of the industrial automation system 10 and makes logic-based decisions for automated processes of the industrial automation system 10. Further, the SCADA 60 may analyze real or near real-time data from industrial components62 and subsequently control the industrial components 62); and wherein the system automatically adapts a basis for the check to determine whether the specific certificate profile in the industrial plant is assignable to the plant component when necessary (Dittmer: par. 0062, the aggregate monitoring system 40 may adjust operations of the industrial components 62 or the manufacturing application system 54 to prevent boundary conditions from being approached”). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Dittmer with the method and system of Lutz, Gunjal, and Evanitsky to include to the automation of the industrial plant are captured by a system based on machine learning; and wherein the system automatically adapts a basis for the check to determine whether the specific certificate profile in the industrial plant is assignable to the plant component when necessary. One would have been motivated to provide better assess the operating status and proactively operational adjustment (Dittmer: par. 0062), to the certificate management system of Lutz to achieve adaptive security policy management based on changing plant conditions. Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Lutz et al. (“Lutz,” US 2018/0322274) in view of Gunjal et al. (“Gunjal,” US 2023/0112261), and Evanitsky (“Evanitsky,” US 2012/0127511, further in view of Whang et al. (“Whang,” US 2017/0329616) Regarding claim 11, the combination of Lutz, Gunjal, and Evanitsky teaches the method as claimed in claim 1. The combination of Lutz, Gunjal, and Evanitsky teaches the automated check determine whether the specific certificate profile is usable by the plant component and whether the specific certificate profile in the industrial plant is assignable to the plant component but does not explicitly disclose “wherein a result of said checks to determine whether the specific certificate profile is usable by the plant component and whether the specific certificate profile in the industrial plant is assignable to the plant component is visually presented to an operator of the industrial plant.” However, in an analogous art, Whang discloses visual presentation to operator: Wang teaches a SCADA system that displays system data to operators though dashboard interfaces (Whang: Abstract, The SCADA system includes a server that acquires data from remote apparatuses for system control and monitoring, and a display device that displays the acquired data via a dashboard; pars. 0010, 0011, provide a SCADA system providing “dashboard” for users; par. 0023, windows and changing the size of already created windows depending on the content of a newly added window in a dashboard by a user). Whang SCADA dashboard system that displays system information to operators encompasses the capability to visual presentation validation results, as SCADA system routinely display various types of operational data and system status information to plant operators through dashboard interfaces. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Whang with the method and system of Lutz, Gunjal, and Evanitsky to include wherein a result of said checks to determine whether the specific certificate profile is usable by the plant component and whether the specific certificate profile in the industrial plant is assignable to the plant component is visually presented to an operator of the industrial plant. One would have been motivated to implement visual presentation because it is common knowledge that industrial plant operators require dashboard interfaces to monitor automated system operations. Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Lutz et al. (“Lutz,” US 2018/0322274) in view of Gunjal et al. (“Gunjal,” US 2023/0112261), and Evanitsky (“Evanitsky,” US 2012/0127511, further in view of Raju et al. (“Raju,” US 2023/0236802) Regarding claim 12, the combination of Lutz, Gunjal, and Evanitsky teaches the method as claimed in claim 1. The combination of Lutz, Gunjal, and Evanitsky teaches the automated check determine whether the specific certificate profile is usable by the plant component and whether the specific certificate profile in the industrial plant is assignable to the plant component but does not explicitly disclose, wherein a result of said checks to determine whether the specific certificate profile is usable by the plant component and whether the specific certificate profile in the industrial plant is assignable to the plant component is deposited in an archive of the industrial plant. However, in an analogous art, Raju discloses archival validation result (Raju: par. 0006, As the validation is performed, results of the validation may be stored to a log. The log may include information that identifies the various requirements that were tested during the validation, whether the deliverable passed or failed each of the requirements, par. 0007, logging the results of the compliance validations may enable information to be provided to a user; par. 0040, the results of validation may be recorded to log. For example. the log may track validation results for each of the requirements identified from the compliance specification.). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Raju with the method and system of Lutz, Gunjal, and Evanitsky to include herein a result of said checks to determine whether the specific certificate profile is usable by the plant component and whether the specific certificate profile in the industrial plant is assignable to the plant component is deposited in an archive of the industrial plant. One would have been motivated to implement such logging because Raju demonstrates that storing validation results enables users to quickly determine compliance status and identify failed requirement (Raju: par. 0007). Applying this logging approach to certificate validation would provide the predictable benefit of maintaining audit trails for security decisions, enabling compliance monitoring, and providing historical records for troubleshooting validation issues in industrial plant certificate management systems. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to CANH LE whose telephone number is (571)270-1380. The examiner can normally be reached on Monday to Friday 6:00AM to 3:30PM other Friday off. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Luu Pham, can be reached at telephone number 571-270-5002. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of an application may be obtained from Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center and Private PAIR for authorized users only. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form. /Canh Le/ Examiner, Art Unit 2439 June 16th, 2026 /LUU T PHAM/Supervisory Patent Examiner, Art Unit 2439
Read full office action

Prosecution Timeline

Mar 08, 2023
Application Filed
Sep 08, 2025
Non-Final Rejection mailed — §103
Dec 08, 2025
Response Filed
Dec 22, 2025
Final Rejection mailed — §103
Feb 23, 2026
Response after Non-Final Action
Mar 09, 2026
Request for Continued Examination
Mar 18, 2026
Response after Non-Final Action
Jun 24, 2026
Non-Final Rejection mailed — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12683779
CALCULATION SYSTEM, CALCULATION METHOD, AND INFORMATION STORAGE MEDIUM
3y 2m to grant Granted Jul 14, 2026
Patent 12683971
MONITORING APPARATUS AND CONTROL METHOD THEREOF
2y 8m to grant Granted Jul 14, 2026
Patent 12626227
DYNAMIC MEETING SPACE CONFIGURATION BASED ON CONTENT
3y 1m to grant Granted May 12, 2026
Patent 12627651
SECURE PASSWORD LESS CRITICAL COMPUTING INFRASTRUCTURE ACCESS COMMUNICATION NETWORK PROTOCOL
2y 2m to grant Granted May 12, 2026
Patent 12621301
SCALABLE ARCHITECTURE OF SERVERS PROVIDING ACCESS TO DATA CONTENT
5y 4m to grant Granted May 05, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

3-4
Expected OA Rounds
73%
Grant Probability
99%
With Interview (+72.4%)
3y 9m (~4m remaining)
Median Time to Grant
High
PTA Risk
Based on 421 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

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

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

Free tier: 3 strategy analyses per month