DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response to the application 18/668316 filed on 05/20/2024.
Claims 1-20 have been examined and are pending in this application.
Information Disclosure Statement
The information disclosure statement (IDS), submitted on 05/20/2024, is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Interpretation - 35 USC § 112
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.
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 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: “the certificate management device is to: receive/analyze/process/send ...,” recited in claim 1; “the certificate management device is to: process/generate ...,” recited in claim 2; “the certificate management device is to: receive/authenticate/establish ...,” recited in claim 3; “the certificate management device is to: receive/analyze/process/generate/send ...,” recited in claim 4; “the certificate management device is to: authenticate/receive ...,” recited in claim 5; “the on-premise device is to: store/update …,” recited in claim 9.
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
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 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 of this title, 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-4, 8-15 and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Leblang et al. (“Leblang,” US 11240043) in view of Golden et al. (“Golden,” US 2025/0106044).
Regarding claim 1: Leblang discloses a system for obtaining signed certificates for on-premise devices, the system comprising:
an on-premise device, wherein the on-premise device includes a set of services, wherein each service corresponds to establishing communication with the on-premise device, wherein each service requires a certificate signed by a certificate authority for establishing secure communication with the on-premise device (Leblang: col. 2 lines 45-52 improve the ease and efficiency by which Internet of Things (IoT) devices, such as voice devices, may be connected to secure wireless networks [] voice devices and other IoT devices may be configured to provide specialized services and/or have specialized restrictions on network access based at least in part on their individual certificates; col. 12 lines 66-67 through col. 14 lines 1-2 the device certificate 120 [] may be signed by both the enterprise CA system(s) 114, as well as the subordinate CA system(s) 118);
a certificate management device in communication with the on-premise device (Leblang: col. 2 lines 61-64 the subordinate CA may be configured to cooperate with an enterprise CA that is maintained by the enterprise to issue device certificates that are based on root certificates issued by the enterprise CA), wherein the certificate management device is to:
receive, from the on-premise device, a request for obtaining a signed certificate corresponding to each of the set of services (Leblang: col. 3 lines 29-33 the IoT device, such as a voice device, may generate a private and public key pair and generate a CSR based at least in part on the key pair), wherein the request comprises a set of parameters corresponding to each of the set of services, the parameters being indicative of type of certificate and a unique identifier corresponding to the on-premise device (Leblang: col. 3 lines 15-25 the setup system may use this communicative connection to receive information about the IoT device, such as a device identifier, device serial number, model, software version, etc. The setup system may also receive information about [] the type of certificate that is to be issued (e.g., WPA2, X.509, etc.));
analyze the request for obtaining the signed certificate corresponding to each of the set of services (Leblang: col. 10 lines 14-21 the CSR may include a public key of a public-private key pair of a public key infrastructure (PKI) [] a CSR may include [] enterprise name, sub-organization name, location, email addresses, or the like. The CSR may be for generating any suitable certificate type, such as a X.509 format certificate);
process the request corresponding to each of the set of services based on the analysis to obtain an output for the request corresponding to each of the set of services (Leblang: col. 3 lines 40-41 the subordinate CA may sign the CSR to generate a device certificate associated with the IoT device; col. 4 lines 5-8 the subordinate CA may issue a device certificate for the IoT device using the root certificate and/or root certificate containing certificate chain, as provided by the enterprise CA when the subordinate CA was provisioned); and
send the output for the request corresponding to each of the set of services to the on-premise device (Leblang: col. 4 lines 25-32 the device certificate, as generated by the subordinate CA, may be sent to the setup system [] when the setup system receives the device certificate, the device certificate may be sent to the IoT device, such as via the P2P communicative connection).
Leblang does not explicitly wherein the output comprises one of: a signed certificate of a corresponding certificate authority along with an expiration period and a message to reject issuing of a signed certificate.
However, Golden discloses wherein the output comprises one of: a signed certificate of a corresponding certificate authority along with an expiration period and a message to reject issuing of a signed certificate (Golden: par. 0066 the certificate 414 may be digitally signed using a hash value generated using the certificate authority's 508 public key and verified based on the PKI public key stored in memory of the OT device; par. 0072 certificates 414 may be issued by the certificate authority 508 with an expiration date).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Golden with the system/method of Leblang to include a signed certificate of a corresponding certificate authority along with an expiration period. One would have been motivated to providing tools for managing public key infrastructure (PKI) in operational technology environments (Golden: par. 0001).
Regarding claim 2: Leblang in view of Golden discloses the system of claim 1.
Leblang further discloses wherein the certificate management device includes a plurality of local certificate authority certificates, each local certificate authority certificates being signed by a certificate authority’s root certificate (Leblang: col. 2 lines 59-64 an enterprise may provision a subordinate certificate authority (CA) that may be provided as a remote service. The subordinate CA may be configured to cooperate with an enterprise CA that is maintained by the enterprise to issue device certificates that are based on root certificates issued by the enterprise CA), the certificate management device includes a signing service for signing a certificate, wherein to obtain the output for the request corresponding to each of the set of services (Leblang: col. 17 lines 65-67 through col. 18 lines 1-3 the certificate manager 510 [] enables the subordinate certificate authority system(s) 118 to provide certificate signing services, such as by creating a chain certificate based on root certificates 116 from enterprise CA system(s) 114), the certificate management device is to:
process, by the signing service, the request corresponding to each of the set of services using at least one of the plurality of local certificate authority certificates (Leblang: col. 3 lines 49-57 the subordinate certificate authority system may provide subordinate CA services to a number of different enterprises and/or customers [] the subordinate CA [] may provide voice-based secure services (e.g., ASR, NLU, search and information provider) and/or other services to IoT devices).
Golden further discloses generate, by using the signing service, the output of one of: the signed certificate along with the expiration period and the message to reject issuing of a signed certificate (Golden: par. 0066 the certificate 414 may be digitally signed using a hash value generated using the certificate authority's 508 public key and verified based on the PKI public key stored in memory of the OT device; par. 0072 certificates 414 may be issued by the certificate authority 508 with an expiration date).
The motivation is the same that of claim 1 above.
Regarding claim 3: Leblang in view of Golden discloses the system of claim 1, wherein prior to receiving the request for obtaining the signed certificate corresponding to each of the set of services, the certificate management device is to:
receive, from the on-premise device, an on-boarding request (Leblang: col. 22 lines 29-33 request a new CSR from the IoT device 106 to attempt the issuance of a new device certificate 120 to enable the IoT device 106 to access the enterprise network and/or service outside of the enterprise environment 102);
authenticate the on-boarding request using an identification code (Leblang: col. 14 lines 20-24 the setup system 112 may register the IoT device 106 by sending an identifier of the IoT device 106 (e.g., unique device ID) and an identifier of the device certificate 120 (e.g., unique certificate ID) to the resource management system(s) 128); and
establish authorization with the on-premise device (Leblang: col. 14 lines 24-27 the resource management system(s) 128 may store the IoT device identifier associated with the certificate identifier for future access in providing IoT device 106 specific services).
Regarding claim 4: Leblang in view of Golden discloses the system of claim 1.
Leblang further discloses wherein if the output comprises the signed certificate along with the expiration period, upon sending the signed certificate along with the expiration period to the on-premise device, the certificate management device is to:
receive, from the on-premise device, a request for renewal of the signed certificate corresponding to the service, wherein the request comprises a set of parameters corresponding to the service, wherein the request for renewal of the signed certificate is to be received before a predetermined period of time prior to the expiration period (Leblang: col. 16 lines 12-21 at block 404, the rotation system(s) 126 may initiate device certificate renewal with the IoT device 106 [] and then request the IoT device 106 to send a certificate signing request (CSR) [] at block 406, a new CSR based on a new key pair may be generated and sent to the rotation system(s) 126; col. 6 lines 32-37 determination of whether a certificate is to be renewed may be made based at least in part on expiration date of the certificate [] certificates may be renewed around a half point of their life. In other cases, certificates may be renewed at a predetermined time (e.g., a month or a week) prior to their expiration);
analyze the request for renewal of the signed certificate corresponding to the service in response to receiving the request for renewal of the signed certificate corresponding to the service (Leblang: col. 16 lines 29-31 at block 410, a new device certificate for the IoT device 106 may be issued by the subordinate certificate system(s) 118 and sent to the rotation system(s) 126);
process, by a signing service, the request for renewal of the signed certificate corresponding to the service, wherein the certificate management device includes a plurality of local certificate authority certificates, each local certificate authority certificates being signed by a certificate authority’s root certificate, the certificate management device includes the signing service for signing a certificate (Leblang: col. 2 lines 61-64 the subordinate CA may be configured to cooperate with an enterprise CA that is maintained by the enterprise to issue device certificates that are based on root certificates issued by the enterprise CA; col. 6 lines 27-34 the rotation system(s) may cooperate with other remote service system(s), such as system(s) that may provide voice service(s) and/or resource management system(s) to determine the expiration dates and/or times for device certificates that are being used by IoT devices. A determination of whether a certificate is to be renewed may be made based at least in part on expiration date of the certificate); and
send the output for the request for renewal to the on-premise device (Leblang: col. 16 lines 36-37 at block 412, the rotation system(s) 126 may provide the new device certificate to the IoT device 106).
Golden discloses generate, by using the signing service, the output of one of: a signed certificate along with a new expiration period and a message to reject issuing of the signed certificate (Golden: par. 0066 the certificate 414 may be digitally signed using a hash value generated using the certificate authority's 508 public key and verified based on the PKI public key stored in memory of the OT device; par. 0072 certificates 414 may be issued by the certificate authority 508 with an expiration date).
The motivation is the same that of claim 1 above.
Regarding claim 8: Leblang in view of Golden discloses the system of claim 1.
Leblang further discloses wherein the signed certificate is one of: a X.509 certificate for use as a client certificate and a X.509 certificate for use as a server certificate (Leblang: col. 10 lines 20-21 the CSR may be for generating any suitable certificate type, such as a X.509 format certificate).
Regarding claim 9: Leblang in view of Golden discloses the system of claim 1.
Golden further discloses wherein if the output comprises the signed certificate along with the expiration period, the on-premise device is to:
store the signed certificate along with the expiration period upon receiving the output from the certificate management device (Golden: par. 0082 at block 608, the received certificate(s) are stored on the OT device (e.g., in memory)); and
update configuration corresponding to each of the set of the services to present the stored signed certificate (Golden: par. 0091 the certificate must be renewed or a new certificate obtained to use the industrial device after the certificate expires or has been revoked. The certificate may be stored on the industrial device along with a corresponding private key).
The motivation is the same that of claim 1 above.
Regarding claim 10: Leblang discloses a method for obtaining signed certificates for an on-premise device, the method comprising:
transmitting, by a first on-premise device, a first request for obtaining a signed certificate corresponding to each of a first set of services (Leblang: col. 16 lines 12-21 at block 404, the rotation system(s) 126 may initiate device certificate renewal with the IoT device 106 [] and then request the IoT device 106 to send a certificate signing request (CSR) [] at block 406, a new CSR based on a new key pair may be generated and sent to the rotation system(s) 126), wherein the first on-premise device includes the first set of services, wherein each of the first set of services correspond to establishing communication with the first on-premise device (Leblang: col. 2 lines 45-52 improve the ease and efficiency by which Internet of Things (IoT) devices, such as voice devices, may be connected to secure wireless networks [] voice devices and other IoT devices may be configured to provide specialized services and/or have specialized restrictions on network access based at least in part on their individual certificates; col. 12 lines 66-67 through col. 14 lines 1-2 the device certificate 120 [] may be signed by both the enterprise CA system(s) 114, as well as the subordinate CA system(s) 118), wherein the first request comprises a first set of parameters corresponding to each of the first set of services, the first set of parameters being indicative of type of certificate and an unique identifier corresponding to the first on-premise device (Leblang: col. 3 lines 15-25 the setup system may use this communicative connection to receive information about the IoT device, such as a device identifier, device serial number, model, software version, etc. The setup system may also receive information about [] the type of certificate that is to be issued (e.g., WPA2, X.509, etc.));
transmitting, by a second on-premise device, a second request for obtaining a signed certificate corresponding to each of a second set of services (Leblang: col. 16 lines 12-21 at block 404, the rotation system(s) 126 may initiate device certificate renewal with the IoT device 106 [] and then request the IoT device 106 to send a certificate signing request (CSR) [] at block 406, a new CSR based on a new key pair may be generated and sent to the rotation system(s) 126 [NOTE: relational terms such as first and second, top and bottom, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions]), wherein the second on-premise device includes the second set of services, wherein each of the second set of services correspond to establishing communication with the second on-premise device (Leblang: col. 2 lines 45-52 improve the ease and efficiency by which Internet of Things (IoT) devices, such as voice devices, may be connected to secure wireless networks [] voice devices and other IoT devices may be configured to provide specialized services and/or have specialized restrictions on network access based at least in part on their individual certificates; col. 12 lines 66-67 through col. 14 lines 1-2 the device certificate 120 [] may be signed by both the enterprise CA system(s) 114, as well as the subordinate CA system(s) 118), and wherein the second request comprises a second set of parameters corresponding to each of the second set of services, the second set of parameters being indicative of type of certificate and an unique identifier corresponding to the second on-premise device (Leblang: col. 3 lines 15-25 the setup system may use this communicative connection to receive information about the IoT device, such as a device identifier, device serial number, model, software version, etc. The setup system may also receive information about [] the type of certificate that is to be issued (e.g., WPA2, X.509, etc.));
analyzing, by a certificate management device, the first request and the second request, wherein the certificate management device is in communication with the first on-premise device and the second on-premise device (Leblang: col. 10 lines 14-21 the CSR may include a public key of a public-private key pair of a public key infrastructure (PKI) [] a CSR may include [] enterprise name, sub-organization name, location, email addresses, or the like. The CSR may be for generating any suitable certificate type, such as a X.509 format certificate);
processing, by the certificate management device, the first request corresponding to each of the first set of services and the second request corresponding to each of the second set of services to obtain an output for the first request corresponding to each of the first set of services and an output for the second request to each of the second set of services (Leblang: col. 3 lines 40-41 the subordinate CA may sign the CSR to generate a device certificate associated with the IoT device; col. 4 lines 5-8 the subordinate CA may issue a device certificate for the IoT device using the root certificate and/or root certificate containing certificate chain, as provided by the enterprise CA when the subordinate CA was provisioned);
transmitting the output for the first request corresponding to each of the first set of services to the first on-premise device (Leblang: col. 4 lines 25-32 the device certificate, as generated by the subordinate CA, may be sent to the setup system [] when the setup system receives the device certificate, the device certificate may be sent to the IoT device, such as via the P2P communicative connection); and
transmitting the output for the second request corresponding to each of the second set of services to the second on-premise device (Leblang: col. 4 lines 25-32 the device certificate, as generated by the subordinate CA, may be sent to the setup system [] when the setup system receives the device certificate, the device certificate may be sent to the IoT device, such as via the P2P communicative connection).
Leblang does not explicitly disclose wherein each of the first/second set of services requires a signed certificate signed by a certificate authority for establishing secure communication with the first/second on-premise device.
However, Golden discloses wherein each of the first/second set of services requires a signed certificate signed by a certificate authority for establishing secure communication with the first/second on-premise device (Golden: par. 0069 if the certificate is signed, the authenticity of the hash value of the digital signature of the certificate 414 may be verified using the PKI public key stored in device memory; par. 0070 with one or more certificates 414, one or more public keys 416, and the corresponding device private key 418 stored in memory of the device 308, the machine builder 502 may ship the OT device 308 to the end user 504, or some other party along the distribution chain, in a secure state).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Golden with the system/method of Leblang to include first/second set of services requires a signed certificate signed by a certificate authority for establishing secure communication with the first/second on-premise device. One would have been motivated to providing tools for managing public key infrastructure (PKI) in operational technology environments (Golden: par. 0001).
Regarding claims 11-13: Claims 11-13 are similar in scope to claims 2-3, respectively, and are therefore rejected under similar rationale [NOTE: relational terms such as first and second, top and bottom, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions]).
Regarding claim 14: Leblang in view of Golden discloses the method of claim 10.
Leblang further discloses requesting, by the first on-premise device, the output for the first request corresponding to each of the first set of services to the first on-premise device (Leblang: col. 4 lines 25-32 the device certificate, as generated by the subordinate CA, may be sent to the setup system [] when the setup system receives the device certificate, the device certificate may be sent to the IoT device, such as via the P2P communicative connection);
transmitting, by the certificate management device, the output for the first request corresponding to each of the first set of services to the first on-premise device in response to the requesting by the first on-premise device (Leblang: col. 16 lines 36-37 at block 412, the rotation system(s) 126 may provide the new device certificate to the IoT device 106);
requesting, by the second on-premise device, the output for the second request corresponding to each of the second set of services (Leblang: col. 4 lines 25-32 the device certificate, as generated by the subordinate CA, may be sent to the setup system [] when the setup system receives the device certificate, the device certificate may be sent to the IoT device, such as via the P2P communicative connection [NOTE: relational terms such as first and second, top and bottom, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions]); and
transmitting, by the certificate management device, the output for the second request corresponding to each of the second set of services to the second on-premise device in response to the requesting by the second on-premise device (Leblang: col. 16 lines 36-37 at block 412, the rotation system(s) 126 may provide the new device certificate to the IoT device 106).
Regarding claim 15: Claim 15 is similar in scope to claims 4, and is therefore rejected under similar rationale.
Regarding claim 18: Leblang discloses a non-transitory computer-readable medium comprising instructions for obtaining signed certificates for on-premise devices, the instructions being executable by a processing resource to:
transmit, by an on-premise device, a request for obtaining a signed certificate corresponding to each of a set of services, wherein the on-premise device includes the set of services, wherein each of the set of services correspond to establishing communication with the on-premise device (Leblang: col. 2 lines 45-52 improve the ease and efficiency by which Internet of Things (IoT) devices, such as voice devices, may be connected to secure wireless networks [] voice devices and other IoT devices may be configured to provide specialized services and/or have specialized restrictions on network access based at least in part on their individual certificates; col. 12 lines 66-67 through col. 14 lines 1-2 the device certificate 120 [] may be signed by both the enterprise CA system(s) 114, as well as the subordinate CA system(s) 118), wherein each of the set of services requires a signed certificate signed by a certificate authority for establishing secure communication with the on-premise device, wherein the request comprises a set of parameters corresponding to each of the set of services, the set of parameters being indicative of type of certificate and an unique identifier corresponding to the on-premise device (Leblang: col. 3 lines 15-25 the setup system may use this communicative connection to receive information about the IoT device, such as a device identifier, device serial number, model, software version, etc. The setup system may also receive information about [] the type of certificate that is to be issued (e.g., WPA2, X.509, etc.));
analyze, by a certificate management device, the request for obtaining the certificate corresponding to each of the set of services, wherein the certificate management device is in communication with the on-premise device (Leblang: col. 10 lines 14-21 the CSR may include a public key of a public-private key pair of a public key infrastructure (PKI) [] a CSR may include [] enterprise name, sub-organization name, location, email addresses, or the like. The CSR may be for generating any suitable certificate type, such as a X.509 format certificate);
process, by the certificate management device, the request corresponding to each of the set of services using at least one of a plurality of local certificate authority certificates (Leblang: col. 3 lines 40-41 the subordinate CA may sign the CSR to generate a device certificate associated with the IoT device; col. 4 lines 5-8 the subordinate CA may issue a device certificate for the IoT device using the root certificate and/or root certificate containing certificate chain, as provided by the enterprise CA when the subordinate CA was provisioned), wherein the certificate management device includes a plurality of local certificate authority certificates, each local certificate authority certificate being signed by a certificate authority’s root certificate (Leblang: col. 2 lines 59-64 an enterprise may provision a subordinate certificate authority (CA) that may be provided as a remote service. The subordinate CA may be configured to cooperate with an enterprise CA that is maintained by the enterprise to issue device certificates that are based on root certificates issued by the enterprise CA), the certificate management device including a signing service engine for signing a certificate (Leblang: col. 17 lines 65-67 through col. 18 lines 1-3 the certificate manager 510 [] enables the subordinate certificate authority system(s) 118 to provide certificate signing services, such as by creating a chain certificate based on root certificates 116 from enterprise CA system(s) 114);
send, by the certificate management device, the output for the request corresponding to each of the set of services to the on-premise device (Leblang: col. 4 lines 25-32 the device certificate, as generated by the subordinate CA, may be sent to the setup system [] when the setup system receives the device certificate, the device certificate may be sent to the IoT device, such as via the P2P communicative connection);
analyze, by the certificate management device, the request for renewal of the signed certificate corresponding to the service (Leblang: col. 16 lines 29-31 at block 410, a new device certificate for the IoT device 106 may be issued by the subordinate certificate system(s) 118 and sent to the rotation system(s) 126);
process, by the certificate management device, the request for renewal of the signed certificate corresponding to the service (Leblang: col. 6 lines 27-34 the rotation system(s) may cooperate with other remote service system(s), such as system(s) that may provide voice service(s) and/or resource management system(s) to determine the expiration dates and/or times for device certificates that are being used by IoT devices. A determination of whether a certificate is to be renewed may be made based at least in part on expiration date of the certificate); and
send, by the certificate management device, the output for the request for renewal corresponding to the service to the on-premise device (Leblang: col. 16 lines 36-37 at block 412, the rotation system(s) 126 may provide the new device certificate to the IoT device 106).
Leblang does not explicitly disclose generate, by the certificate management device, the output for the request corresponding to each of the set of services, wherein the output comprises one of: the signed certificate along with the expiration period and the message to reject issuing of a signed certificate for the request, transmit, from the on-premise device to the certificate management device, a request for renewal of the signed certificate corresponding to the service upon the sending of the output if the output comprises the signed certificate along with the expiration period, wherein the request comprises a set of parameters corresponding to the service and generate, by the certificate management device, an output for the request for renewal corresponding to the service, the output being one of: a signed certificate along with a new expiration period and a message to reject issuing of the renewed signed certificate.
However, Golden discloses generate, by the certificate management device, the output for the request corresponding to each of the set of services, wherein the output comprises one of: the signed certificate along with the expiration period and the message to reject issuing of a signed certificate for the request (Golden: par. 0066 the certificate 414 may be digitally signed using a hash value generated using the certificate authority's 508 public key and verified based on the PKI public key stored in memory of the OT device; par. 0072 certificates 414 may be issued by the certificate authority 508 with an expiration date);
transmit, from the on-premise device to the certificate management device, a request for renewal of the signed certificate corresponding to the service upon the sending of the output if the output comprises the signed certificate along with the expiration period, wherein the request comprises a set of parameters corresponding to the service (Golden: par. 0066 the certificate 414 may be digitally signed using a hash value generated using the certificate authority's 508 public key and verified based on the PKI public key stored in memory of the OT device; par. 0072 certificates 414 may be issued by the certificate authority 508 with an expiration date; par. 0021 the certificate must be renewed or a new certificate obtained to use the industrial device after the certificate expires or has been revoked); and
generate, by the certificate management device, an output for the request for renewal corresponding to the service, the output being one of: a signed certificate along with a new expiration period and a message to reject issuing of the renewed signed certificate (Golden: par. 0066 the certificate 414 may be digitally signed using a hash value generated using the certificate authority's 508 public key and verified based on the PKI public key stored in memory of the OT device; par. 0072 certificates 414 may be issued by the certificate authority 508 with an expiration date).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Golden with the system/method of Leblang to include generate, by the certificate management device, an output for the request for renewal corresponding to the service, the output being one of: a signed certificate along with a new expiration period and a message to reject issuing of the renewed signed certificate. One would have been motivated to providing tools for managing public key infrastructure (PKI) in operational technology environments (Golden: par. 0001).
Regarding claim 19: Leblang in view of Golden discloses the non-transitory computer-readable medium of claim 18.
Leblang further discloses the instructions being executable by the processing resource to:
transmit, from the on-premise device, the request for renewal of the signed certificate before a predetermined period of time prior to the expiration period (Leblang: col. 16 lines 12-21 at block 404, the rotation system(s) 126 may initiate device certificate renewal with the IoT device 106 [] and then request the IoT device 106 to send a certificate signing request (CSR); col. 6 lines 32-37 certificates may be renewed around a half point of their life. In other cases, certificates may be renewed at a predetermined time (e.g., a month or a week) prior to their expiration).
Regarding claim 20: Leblang in view of Golden discloses the non-transitory computer-readable medium of claim 18.
Leblang further discloses wherein if the output comprises the signed certificate along with the expiration period, the instructions being executable by the processing resource to:
determine, by the certificate management device, if the request for renewal of the signed certificate corresponding to the service is received from the on-premise device within a grace period of time after elapsing of the expiration period (Leblang: col. 6 lines 24-39 the rotation system(s) may provide certificate renewal services by determining whether a particular IoT device, such as a particular voice device, has a certificate that is to be renewed [] the rotation system(s) may cooperate [] to determine the expiration dates and/or times for device certificates that are being used by IoT devices [] in some cases, certificates may be renewed around a half point of their life. In other cases, certificates may be renewed at a predetermined time (e.g., a month or a week) prior to their expiration. Indeed, any suitable mechanism and/or threshold may be applied to determine whether a certificate is to be renewed based at least in part on its expiration date); and
analyze, by the certificate management device, the request for renewal of the signed certificate corresponding to the service if the request for renewal is received from the on-premise device within the grace period of time after elapsing of the expiration period (Leblang: col. 6 lines 39-46 when the rotation system(s) determine that a certificate is to be renewed, it may cooperate with the IoT device, such as a voice device, to renew that device's certificate. This may entail the rotation system(s) to obtain permissions to act on behalf of the IoT device and then request the IoT device to send a certificate signing request (CSR)).
Claims 5 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Leblang et al. (“Leblang,” US 11240043) in view of Golden et al. (“Golden,” US 2025/0106044) and Fu et al. (“Fu,” US 2011/0126002).
Regarding claim 5: Leblang in view of Golden discloses the system of claim 4.
Leblang in view of Golden does not explicitly disclose wherein prior to receiving the request for renewal of the signed certificate corresponding to the service, the certificate management device is to: authenticate the request for renewal using a token and receive, from the on-premise device, the request for renewal of the signed certificate corresponding to the service in response to a successful authentication.
However, Fu discloses wherein prior to receiving the request for renewal of the signed certificate corresponding to the service, the certificate management device is to:
authenticate the request for renewal using a token (Fu: 0036 receiving a token renewal request from a client application to renew an original certificate; par. 0037 the processing logic authenticating the token and the user associated with the token (block 306)); and
receive, from the on-premise device, the request for renewal of the signed certificate corresponding to the service in response to a successful authentication (Fu: 0037 the processing logic authenticates the user associated with the token at block 306; par. 0038 when the processing logic receives the renewed certificate from the certificate manager, the processing logic sends the renewed certificate back to the token to store the renewed certificate (block 310)).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Fu with the system/method of Leblang and Golden to include receive, from the on-premise device, the request for renewal of the signed certificate corresponding to the service in response to a successful authentication. One would have been motivated to providing token management and renewal of digital certificates using tokens (Fu: par. 0001).
Regarding claim 16: Claim 16 is similar in scope to claims 5, and is therefore rejected under similar rationale.
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Leblang et al. (“Leblang,” US 11240043) in view of Golden et al. (“Golden,” US 2025/0106044), Fu et al. (“Fu,” US 2011/0126002) and Krishan et al. (“Krishan,” US 2023/0171099).
Regarding claim 6: Leblang in view of Golden and Fu discloses the system of claim 5.
Leblang in view of Golden and Fu does not explicitly disclose wherein the token is a JavaScript Object Notation (JSON) web token.
However, Krishan discloses wherein the token is a JavaScript Object Notation (JSON) web token (Krishan: par. 0035 NRF 204 is configured to generate an access token that includes a plurality of appropriate JSON web token (JWT) claims).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Krishan with the system/method of Leblang, Golden and Fu to include the token is a JavaScript Object Notation (JSON) web token. One would have been motivated for sharing key identification and public certificate data for access token verification (Krishan: par. 0001).
Claims 7 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Leblang et al. (“Leblang,” US 11240043) in view of Golden et al. (“Golden,” US 2025/0106044) and Pouchak et al. (“Pouchak,” US 2020/0386436).
Regarding claim 7: Leblang in view of Golden discloses the system of claim 1.
Leblang in view of Golden does not explicitly disclose wherein the set of services is one of: a web server to enable running of a web page on the on-premise device, a Fox protocol server to enable the on-premise Niagara device to communicate with another on-premise Niagara device, platform management service to enable communication regarding management of an operating system corresponding to the on-premise device, external communication service to enable communication of the on-premise device outside the system.
However, Pouchak discloses wherein the set of services is one of: a web server to enable running of a web page on the on-premise device, a Fox protocol server to enable the on-premise Niagara device to communicate with another on-premise Niagara device, platform management service to enable communication regarding management of an operating system corresponding to the on-premise device, external communication service to enable communication of the on-premise device outside the system (Pouchak: par. 0023 a Niagara component 18 on board 12 may have a web server 19 and component 21 connected to remote comm/VPN connector 15; par. 0030 a USB host 47 may have a FOXs & HTTPS connection to a wireless encrypted dongle 48 with ECC 508. An HTTPS, FOXs connection may go from dongle 48 to a wireless encrypted router 49 [] a FOXs connection may go from remote comm/VPN connector 15 to Niagara workbench 53; par. 0045 the internet protocol controller subsystem may incorporate a direct digital control module connected to a web server and a processing platform. The web server may be connected to a remote communication virtual private network (VPN) connector and a first serial communication manager module).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Pouchak with the system/method of Leblang and Golden to include platform management service to enable communication regarding management of an operating system corresponding to the on-premise device, external communication service to enable communication of the on-premise device outside the system. One would have been motivated for providing powerful direct digital control and integration control platform for a highly secure and robust technical solution (Pouchak: par. 0003).
Regarding claim 17: Claim 17 is similar in scope to claim 7, and is therefore rejected under similar rationale.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Fahimeh Mohammadi whose telephone number is (571)270-7857. The examiner can normally be reached Monday - Friday 9:00 - 5:00.
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, Luu Pham can be reached at 5712705002. 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.
/FAHIMEH MOHAMMADI/ Examiner, Art Unit 2439
/LUU T PHAM/Supervisory Patent Examiner, Art Unit 2439