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 . In communications filed on 03/02/2026. Claims 1, and 17 are amended. Claims 2, 6-8, and 18 are cancelled. Claims 1, 3-5, 9-17, and 19 are pending in this examination.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. This examination is in response to US Patent Application No. 18/480,057.
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 has been entered.
Examiner Note
Applicant’s amendment to claim 1 obviates previously raised claims 1-13, 35 U.S.C 112(b) , second paragraph and 35 U.S.C 101 rejections.
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.
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: “ a first agent of the first component configured to…”,and “a second agent of the second component configured to…” in claim 1.
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.
A review of the specification shows that the following appears to be the corresponding structure described in the specification for the 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph limitation.
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 § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1, 3-5, and 9-13 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
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) are: “ a first agent of the first component configured to…”,and “a second agent of the second component configured to…” in claim 1.
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.
Claims limitation “ a first agent of the first component configured to…”,and “a second agent of the second component configured to…” in claim 1 invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Claims 2-13 do not cure the deficiency of claim 1 and are rejected under 35 USC 112, 2nd paragraph, for their dependency upon claim 1.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL. —The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1, 3-5, and 9-13 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The dependent claim 1 contains “a processor of the server configured to execute” which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention. In specification the Paragraph [0026] describes The PKI system 120 includes various components 122a-122n that provide and/or support the functionality of a public key infrastructure system, such as 120. The components 122a-122n can include a various servers, modules and/or other components. In an example embodiment, the components 122a-122n can include an Active Directory Certificate Services (ADCS) servers, Hardware Security Modules (HSM)…]. The specification does not contain “a processor, processing , CPU, and etc. and does not explain a processor of the server!
Applicant is kindly requested to show the examiner support in the original disclosure for the new or amended claims. See MPEP 714.02 and 2163.06 (“Applicant should specifically point out the support for any amendments made to the disclosure").
Claims 3-5, and 9-13 do not cure the deficiency of claim 1 and are rejected under 35 USC 112, 1st paragraph, for their dependency upon claim 1.
Response to Arguments
Applicant's arguments filed 03/02/2026 have been fully considered but they are not persuasive:
Applicant submits on page 8 of remarks filed on 03/02/2026 regarding claim 1 that Applicant respectfully submits that the Tempel and Zilinskas, individually or in combination, do not disclose or suggest any sort of "dependency query of the second component" as described Applicant's amended claim 1. Neither Tempel nor Zilinskas describes or implies any sort of "dependency query."
Examiner respectfully disagrees with applicant argument for claim 1 filed on 03/02/2026 on page 8 of remarks.
Tempel discloses:
[ Col. 4 lines 38-56, the managed nodes 126( multiple nodes) may each have an agent 136 installed. ( equated to first agent of first component, and second agent of second component, and etc.). As indicated above, the agents 136 running on the managed nodes 126 may perform tasks related to management of digital certificates. For example, an agent 136 may determine the lifetime of the current managed node certificate 134. In addition, as indicated above, agents 136 running on the managed nodes 126 may work together with the core servers 114 to perform management-related operations. For example, an agent 136 may communicate with a core server 114 to perform tasks related to management of digital certificates ( equated to dependency). Some of these tasks may be related to obtaining a managed node certificate 134, requesting that a new managed node certificate 134a be issued from the managing core server 114 when the current managed node certificate 134 is nearing expiration( equated to functionality)…]; and[Col.7 lines 52-67;Col. 8 lines 1-34, FIGS. 6A-C illustrate various key-pair and corresponding certificate-management operations performed by a managed node 526b and a core server 514 via an intermediary 550. Reference is initially made to FIG. 6A, which illustrates various operations 600A related to publishing a certificate request. An agent 136 on the managed node 526b may monitor 604 the lifetime of the managed node's current key pair (public key 128 and private key 130) and its corresponding current managed node certificate 134. When the agent 136 determines 606 that the managed node's current key pair and certificate 134 will expire within a threshold period of time, the agent 136 may create 608 a new public key 128a and a new private key 130a for the managed node 126. The agent 136 may then create 610 a certificate request, which may include the newly created public key 128a and identifying information 132 of the managed node 126. This certificate request may then be signed 612 by the agent 136 with the managed node's new private key 130a. The agent 136 and the intermediary 550 may establish 613 a direct connection. The agent 136 may authenticate 614 the connection to the intermediary 550 by negotiating a token using the managed node's current private key 130. The agent 136 may send 616 its signed certificate request and the negotiated token to the intermediary 550. The intermediary 550 may store 618 the signed certificate request… FIG. 6B illustrates various operations 600B pertaining to the retrieval of a certificate request stored by an intermediary 550. The core server 514 and the intermediary 550 may establish 619 a direct connection. The core server 514 may authenticate 620 the connection to the intermediary 550 by negotiating a token. The core server 514 may poll 621( equated query) the intermediary 550 for requests. Upon receiving a poll from the core server 514, the intermediary 550 may determine 622 that the poll corresponds to the stored certificate request. The intermediary 550 may then send 624 the certificate request to the core server 514. Upon receipt of the certificate request from the intermediary 550, the core server 514 may use the identifying information 132 and the new public key 128a provided by the certificate request to issue 628 a new digital certificate 134a for the managed node 126.(equated to dependency and functionality) The core server 514 may then sign 630 the new managed node certificate 134a with its private key 118 and send 632 the new managed node certificate 134a to the intermediary 550, which may store 634 the new managed node certificate 134a.], and [Col. 2 lines 13-40; Col. 3 lines 54-65; Col. 4 lines 38-56; Col. 5 lines 50-67, Col 6 lines; Col.6 lines 1-20, 56-67, Col. 7 lines 1-2; Col. 7 lines 33-47; Col. 7 lines 58-67- Col.8 lines 1-10; Col.8 lines 11-51].
Examiner maintain the rejection.
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 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 3-5, 9-17, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Temple (US9,252,958) and in view of Zilinskas (US2007/0005956).
Regarding claim 1, Temple discloses A public key infrastructure (PKI) monitoring system, comprising[ Col. 3 lines 66-67. Col. 4 lines 1-2, the enterprise management system 100 shown in FIG. 1 may implement a PKI system. The PKI system may be implemented using the core servers 114 and the agents 136 running on the managed nodes 126].
a plurality of PKI system components, including at least a first component and a second component[ Col. 3 lines 66-67. Col. 4 lines 1-2, the enterprise management system 100 shown in FIG. 1 may implement a PKI system. The PKI system may be implemented using the core servers 114 and the agents 136 running on the managed nodes 126].
a server that is communicatively coupled to the first and second components,
[ Col. 3 lines 66-67. Col. 4 lines 1-2, the enterprise management system 100 shown in FIG. 1 may implement a PKI system. The PKI system may be implemented using the core servers 114 and the agents 136 running on the managed nodes 126].
and a processor of the server configured to execute instructions to cause the server to at least output a functionality query and a dependency query[Col. 3 lines 34-65, Each of the computing devices shown in FIG. 1 may belong to an enterprise (e.g., a business, a university, a non-profit organization, a government agency, etc.). There are two different types of computing devices shown in FIG. 1: managed nodes 126 and core servers 114. The managed nodes 126 may be desktop computers, laptop computers, tablet computers, smartphones, etc. The core servers 114 may perform a variety of management-related operations with respect to the managed nodes 126. Agents 136 running on the managed nodes 126 may work together with the core servers 114 to perform management-related operations (equated to functionality query). Each core server 114 may be responsible for managing one or more managed nodes 126( equated to dependency query)].
a first agent of the first component configured to, at least collect data regarding a first functionality of the first component in response to a functionality query received from the server, and communicate the first functionality data to the server in response to the received functionality query[ Col. 4 lines 38-56, the managed nodes 126 may each have an agent 136 installed( equated to first agent of first component). As indicated above, the agents 136 running on the managed nodes 126 may perform tasks related to management of digital certificates. For example, an agent 136 may determine the lifetime of the current managed node certificate 134. In addition, as indicated above, agents 136 running on the managed nodes 126 may work together with the core servers 114 to perform management-related operations. For example, an agent 136 may communicate with a core server 114 to perform tasks related to management of digital certificates. Some of these tasks may be related to obtaining a managed node certificate 134, requesting that a new managed node certificate 134a be issued from the managing core server 114 when the current managed node certificate 134 is nearing expiration…]; and[Col.7 lines 52-67;Col. 8 lines 1-34, FIGS. 6A-C illustrate various key-pair and corresponding certificate-management operations performed by a managed node 526b and a core server 514 via an intermediary 550. Reference is initially made to FIG. 6A, which illustrates various operations 600A related to publishing a certificate request. An agent 136 on the managed node 526b may monitor 604 the lifetime of the managed node's current key pair (public key 128 and private key 130) and its corresponding current managed node certificate 134. When the agent 136 determines 606 that the managed node's current key pair and certificate 134 will expire within a threshold period of time, the agent 136 may create 608 a new public key 128a and a new private key 130a for the managed node 126. The agent 136 may then create 610 a certificate request, which may include the newly created public key 128a and identifying information 132 of the managed node 126. This certificate request may then be signed 612 by the agent 136 with the managed node's new private key 130a. The agent 136 and the intermediary 550 may establish 613 a direct connection. The agent 136 may authenticate 614 the connection to the intermediary 550 by negotiating a token using the managed node's current private key 130. The agent 136 may send 616 its signed certificate request and the negotiated token to the intermediary 550. The intermediary 550 may store 618 the signed certificate request… FIG. 6B illustrates various operations 600B pertaining to the retrieval of a certificate request stored by an intermediary 550. The core server 514 and the intermediary 550 may establish 619 a direct connection. The core server 514 may authenticate 620 the connection to the intermediary 550 by negotiating a token. The core server 514 may poll 621 the intermediary 550 for requests. Upon receiving a poll from the core server 514, the intermediary 550 may determine 622 that the poll corresponds to the stored certificate request. The intermediary 550 may then send 624 the certificate request to the core server 514. Upon receipt of the certificate request from the intermediary 550, the core server 514 may use the identifying information 132 and the new public key 128a provided by the certificate request to issue 628 a new digital certificate 134a for the managed node 126. The core server 514 may then sign 630 the new managed node certificate 134a with its private key 118 and send 632 the new managed node certificate 134a to the intermediary 550, which may store 634 the new managed node certificate 134a.], and [Col. 2 lines 13-40; Col. 3 lines 54-65; Col. 4 lines 38-56; Col. 5 lines 50-67, Col 6 lines; Col.6 lines 1-20, 56-67, Col. 7 lines 1-2; Col. 7 lines 33-47; Col. 7 lines 58-67- Col.8 lines 1-10; Col.8 lines 11-51].
a second agent of the second component configured to, at least collect data regarding a second functionality of the second component in response to a dependency query received from the server, the first functionality of the first component being dependent, at least in part, on the second functionality of the second component, and communicate the second functionality data to the server in response to the received dependency query [ Col. 4 lines 38-56, the managed nodes 126 may each have an agent 136 installed. ( equated to second agent of second component). As indicated above, the agents 136 running on the managed nodes 126 may perform tasks related to management of digital certificates. For example, an agent 136 may determine the lifetime of the current managed node certificate 134. In addition, as indicated above, agents 136 running on the managed nodes 126 may work together with the core servers 114 to perform management-related operations. For example, an agent 136 may communicate with a core server 114 to perform tasks related to management of digital certificates. Some of these tasks may be related to obtaining a managed node certificate 134, requesting that a new managed node certificate 134a be issued from the managing core server 114 when the current managed node certificate 134 is nearing expiration…]; and[Col.7 lines 52-67;Col. 8 lines 1-34, FIGS. 6A-C illustrate various key-pair and corresponding certificate-management operations performed by a managed node 526b and a core server 514 via an intermediary 550. Reference is initially made to FIG. 6A, which illustrates various operations 600A related to publishing a certificate request. An agent 136 on the managed node 526b may monitor 604 the lifetime of the managed node's current key pair (public key 128 and private key 130) and its corresponding current managed node certificate 134. When the agent 136 determines 606 that the managed node's current key pair and certificate 134 will expire within a threshold period of time, the agent 136 may create 608 a new public key 128a and a new private key 130a for the managed node 126. The agent 136 may then create 610 a certificate request, which may include the newly created public key 128a and identifying information 132 of the managed node 126. This certificate request may then be signed 612 by the agent 136 with the managed node's new private key 130a. The agent 136 and the intermediary 550 may establish 613 a direct connection. The agent 136 may authenticate 614 the connection to the intermediary 550 by negotiating a token using the managed node's current private key 130. The agent 136 may send 616 its signed certificate request and the negotiated token to the intermediary 550. The intermediary 550 may store 618 the signed certificate request… FIG. 6B illustrates various operations 600B pertaining to the retrieval of a certificate request stored by an intermediary 550. The core server 514 and the intermediary 550 may establish 619 a direct connection. The core server 514 may authenticate 620 the connection to the intermediary 550 by negotiating a token. The core server 514 may poll 621 the intermediary 550 for requests. Upon receiving a poll from the core server 514, the intermediary 550 may determine 622 that the poll corresponds to the stored certificate request. The intermediary 550 may then send 624 the certificate request to the core server 514. Upon receipt of the certificate request from the intermediary 550, the core server 514 may use the identifying information 132 and the new public key 128a provided by the certificate request to issue 628 a new digital certificate 134a for the managed node 126. The core server 514 may then sign 630 the new managed node certificate 134a with its private key 118 and send 632 the new managed node certificate 134a to the intermediary 550, which may store 634 the new managed node certificate 134a.], and [Col. 2 lines 13-40; Col. 3 lines 54-65; Col. 4 lines 38-56; Col. 5 lines 50-67, Col 6 lines; Col.6 lines 1-20, 56-67, Col. 7 lines 1-2; Col. 7 lines 33-47; Col. 7 lines 58-67- Col.8 lines 1-10; Col.8 lines 11-51].
and a functionality module of the server generating a functionality status of the first component based, at least in part, on the response to the functionality query of the first component and the response to the dependency query of the second component.
While Temple discloses this limitation as[ Col. 4 lines 38-56, the managed nodes 126 may each have an agent 136 installed. As indicated above, the agents 136 running on the managed nodes 126 may perform tasks related to management of digital certificates. For example, an agent 136 may determine the lifetime of the current managed node certificate 134. In addition, as indicated above, agents 136 running on the managed nodes 126 may work together with the core servers 114 to perform management-related operations. For example, an agent 136 may communicate with a core server 114 to perform tasks related to management of digital certificates. Some of these tasks may be related to obtaining a managed node certificate 134, requesting that a new managed node certificate 134a be issued from the managing core server 114 when the current managed node certificate 134 is nearing expiration…]; and[Col.7 lines 52-67;Col. 8 lines 1-34, FIGS. 6A-C illustrate various key-pair and corresponding certificate-management operations performed by a managed node 526b and a core server 514 via an intermediary 550. Reference is initially made to FIG. 6A, which illustrates various operations 600A related to publishing a certificate request. An agent 136 on the managed node 526b may monitor 604 the lifetime of the managed node's current key pair (public key 128 and private key 130) and its corresponding current managed node certificate 134. When the agent 136 determines 606 that the managed node's current key pair and certificate 134 will expire within a threshold period of time, the agent 136 may create 608 a new public key 128a and a new private key 130a for the managed node 126. The agent 136 may then create 610 a certificate request, which may include the newly created public key 128a and identifying information 132 of the managed node 126. This certificate request may then be signed 612 by the agent 136 with the managed node's new private key 130a. The agent 136 and the intermediary 550 may establish 613 a direct connection. The agent 136 may authenticate 614 the connection to the intermediary 550 by negotiating a token using the managed node's current private key 130. The agent 136 may send 616 its signed certificate request and the negotiated token to the intermediary 550. The intermediary 550 may store 618 the signed certificate request… FIG. 6B illustrates various operations 600B pertaining to the retrieval of a certificate request stored by an intermediary 550. The core server 514 and the intermediary 550 may establish 619 a direct connection. The core server 514 may authenticate 620 the connection to the intermediary 550 by negotiating a token. The core server 514 may poll 621 the intermediary 550 for requests. Upon receiving a poll from the core server 514, the intermediary 550 may determine 622 that the poll corresponds to the stored certificate request. The intermediary 550 may then send 624 the certificate request to the core server 514. Upon receipt of the certificate request from the intermediary 550, the core server 514 may use the identifying information 132 and the new public key 128a provided by the certificate request to issue 628 a new digital certificate 134a for the managed node 126. The core server 514 may then sign 630 the new managed node certificate 134a with its private key 118 and send 632 the new managed node certificate 134a to the intermediary 550, which may store 634 the new managed node certificate 134a.], and [Col. 2 lines 13-40; Col. 3 lines 54-65; Col. 4 lines 38-56; Col. 5 lines 50-67, Col 6 lines; Col.6 lines 1-20, 56-67, Col. 7 lines 1-2; Col. 7 lines 33-47; Col. 7 lines 58-67- Col.8 lines 1-10; Col.8 lines 11-51].
Furthermore, Zilinskas discloses this limitation as: [¶26, FIG. 1 is a system block diagram of a certificate management system 100. The certificate management system 100 can be used to perform such tasks as verifying a status of a security certificate or security credential, installing new security certificates or security credentials, and deleting corrupted, expired, or revoked security certificates or security credentials. The certificate management system 100 can manage such security certificates or security credentials across a group of machines with each machine having one or more user accounts], and [¶¶30-31, One possible example of a mode of operation of the certificate management system 100 follows. The user, who can be a system administrator or another user having sufficient administrative or access privileges to perform certificate management tasks, accesses the certificate management system 100 by using the certificate manager 110. The certificate manager 110 can query each of the computers 120, 130, 140 to obtain a list of all security certificates or security credentials installed on each computer 120, 130, 140, for the desired accounts. The user can cause the certificate manager 110 to verify each security certificate or security credential in the list of selected computers and accounts. A verification of a certificate includes operations such as a check of the expiration date and validity for each security certificate or security credential by contacting an issuing authority or a trusted authority, usually referred to as a certificate authority], and [¶44, It should be appreciated that the components and methods described provide general frameworks for device configuration management. Among the uses for such components and methods are initial and updated configuration of groups of homogeneous or heterogeneous devices having security certificate or security credential capabilities. Also possible is an ability to query a device (or group of devices) to determine a current configuration state and based upon that state, determine whether to send new or additional configuration information to the device. One additional benefit is the ability to automatically configure large numbers of devices using batch processing techniques].
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 teaching of Temple by incorporating “certificate management system by using the certificate manager, and device configuration management”, as taught by Zilinskas. One could have been motivated to do so in order to query each computer for security certificate and verify and validate the security certificate, and an ability to query a device (or group of devices) to determine a current configuration state and based upon that state, determine whether to send new or additional configuration information to the device [ Zilinskas, ¶¶30-31, 44].
Regarding claim 3, Temple discloses, The PKI monitoring system of claim 2, wherein the functionality module causes an alert to be output, the alert indicative of status of a non-functional as the functionality status of the first component [ Col. 3 lines 25-35, A key pair and its corresponding digital certificate (i.e., a digital certificate that includes the public key of the key pair) have a limited lifetime. When a key pair and its corresponding digital certificate expire, a new key pair and a new digital certificate should be issued. In many known PKI systems, the process of issuing new key pairs/digital certificates may require manual intervention from a human operator and may also require some external form of authentication to complete. One aspect of the present disclosure relates to improved techniques for issuing new key pairs and corresponding digital certificates within a PKI system], and [Col. 5 lines 28-49, as indicated above, a key pair and its corresponding digital certificate have a limited lifetime. The agent 136 may monitor 302 the lifetime of the managed node's current key pair (the managed node's current public key 128 and current private key 130) and its corresponding current managed node certificate 134. When the agent 136 determines 304 that the managed node's current key pair and corresponding current managed node certificate 134 will expire within a period of time that is less than a defined threshold (e.g., fewer than six months), the agent 136 may create 306 a new public key 128a and a new private key 130a for the managed node 126. The agent 136 may then create 308 a request for a new managed node certificate 134a. This certificate request may include the new public key 128a and identifying information 132 of the managed node 126. This certificate request may then be signed 310 by the agent 136 using the managed node's new private key 130a. The agent 136 and the core server 114 may establish 312 a direct connection. The agent 136 may authenticate 314 the connection to the core server 114 by negotiating a token using the managed node's current private key 130. The agent 136 may then send 316 its signed certificate request accompanied by the negotiated token to the core server 114], and Col.6 lines 39-55, The core server 114 and the managed node 126 may establish 412 a connection. The agent 136 and the core server 114 may authenticate 413 the connection by negotiating a token. The agent 136 may periodically poll 414 the core server 114 for updates. In response to receiving a poll from the agent 136 at some point after the core server 114 has installed 410 the new root certificate 106a, the core server 114 may notify the agent 136 that the new root certificate 106a is available and should be installed. In particular, the core server 114 may send 416 the new root certificate 106a to the agent 136 along with a notification signed by the current root certificate 106 that the new root certificate 106a should be installed. The agent 136 trusts the notification to install the new root certificate 106a because of the signature of the notification. Thus, the new root certificate 106a is authenticated using the current root certificate 106. The agent 136 may install 420 the new root certificate 106a for future secure communication].
Regarding claim 4, Temple discloses, wherein the functionality module initiates one or more diagnostic tools determine one or more causes a status of non-functional as the functionality status of the first component [ Col. 3 lines 25-35, A key pair and its corresponding digital certificate (i.e., a digital certificate that includes the public key of the key pair) have a limited lifetime. When a key pair and its corresponding digital certificate expire, a new key pair and a new digital certificate should be issued. In many known PKI systems, the process of issuing new key pairs/digital certificates may require manual intervention from a human operator and may also require some external form of authentication to complete. One aspect of the present disclosure relates to improved techniques for issuing new key pairs and corresponding digital certificates within a PKI system], and [Col. 5 lines 28-49, as indicated above, a key pair and its corresponding digital certificate have a limited lifetime. The agent 136 may monitor 302 the lifetime of the managed node's current key pair (the managed node's current public key 128 and current private key 130) and its corresponding current managed node certificate 134. When the agent 136 determines 304 that the managed node's current key pair and corresponding current managed node certificate 134 will expire within a period of time that is less than a defined threshold (e.g., fewer than six months), the agent 136 may create 306 a new public key 128a and a new private key 130a for the managed node 126. The agent 136 may then create 308 a request for a new managed node certificate 134a. This certificate request may include the new public key 128a and identifying information 132 of the managed node 126. This certificate request may then be signed 310 by the agent 136 using the managed node's new private key 130a. The agent 136 and the core server 114 may establish 312 a direct connection. The agent 136 may authenticate 314 the connection to the core server 114 by negotiating a token using the managed node's current private key 130. The agent 136 may then send 316 its signed certificate request accompanied by the negotiated token to the core server 114], and Col.6 lines 39-55, The core server 114 and the managed node 126 may establish 412 a connection. The agent 136 and the core server 114 may authenticate 413 the connection by negotiating a token. The agent 136 may periodically poll 414 the core server 114 for updates. In response to receiving a poll from the agent 136 at some point after the core server 114 has installed 410 the new root certificate 106a, the core server 114 may notify the agent 136 that the new root certificate 106a is available and should be installed. In particular, the core server 114 may send 416 the new root certificate 106a to the agent 136 along with a notification signed by the current root certificate 106 that the new root certificate 106a should be installed. The agent 136 trusts the notification to install the new root certificate 106a because of the signature of the notification. Thus, the new root certificate 106a is authenticated using the current root certificate 106. The agent 136 may install 420 the new root certificate 106a for future secure communication].
Regarding claim 5, Temple discloses, wherein the functionality module determines one or more remedies to remedy at least one of the one or more determined causes of the non-functional functionality status of the first component, an implementation of the one or more remedies causing the functionality status of the first component to be a functional status [ Col. 3 lines 25-35, A key pair and its corresponding digital certificate (i.e., a digital certificate that includes the public key of the key pair) have a limited lifetime. When a key pair and its corresponding digital certificate expire, a new key pair and a new digital certificate should be issued. In many known PKI systems, the process of issuing new key pairs/digital certificates may require manual intervention from a human operator and may also require some external form of authentication to complete. One aspect of the present disclosure relates to improved techniques for issuing new key pairs and corresponding digital certificates within a PKI system], and [Col. 5 lines 28-49, as indicated above, a key pair and its corresponding digital certificate have a limited lifetime. The agent 136 may monitor 302 the lifetime of the managed node's current key pair (the managed node's current public key 128 and current private key 130) and its corresponding current managed node certificate 134. When the agent 136 determines 304 that the managed node's current key pair and corresponding current managed node certificate 134 will expire within a period of time that is less than a defined threshold (e.g., fewer than six months), the agent 136 may create 306 a new public key 128a and a new private key 130a for the managed node 126. The agent 136 may then create 308 a request for a new managed node certificate 134a. This certificate request may include the new public key 128a and identifying information 132 of the managed node 126. This certificate request may then be signed 310 by the agent 136 using the managed node's new private key 130a. The agent 136 and the core server 114 may establish 312 a direct connection. The agent 136 may authenticate 314 the connection to the core server 114 by negotiating a token using the managed node's current private key 130. The agent 136 may then send 316 its signed certificate request accompanied by the negotiated token to the core server 114], and Col.6 lines 39-55, The core server 114 and the managed node 126 may establish 412 a connection. The agent 136 and the core server 114 may authenticate 413 the connection by negotiating a token. The agent 136 may periodically poll 414 the core server 114 for updates. In response to receiving a poll from the agent 136 at some point after the core server 114 has installed 410 the new root certificate 106a, the core server 114 may notify the agent 136 that the new root certificate 106a is available and should be installed. In particular, the core server 114 may send 416 the new root certificate 106a to the agent 136 along with a notification signed by the current root certificate 106 that the new root certificate 106a should be installed. The agent 136 trusts the notification to install the new root certificate 106a because of the signature of the notification. Thus, the new root certificate 106a is authenticated using the current root certificate 106. The agent 136 may install 420 the new root certificate 106a for future secure communication].
Regarding claim 9, Temple discloses at least a portion of the one or more components of the PKI system are within a private PKI system [Col. 3 lines 43-52, FIG. 1, which illustrates an enterprise management system 100 that includes a plurality of computing devices that are in electronic communication with one another via one or more computer networks 102. The network(s) 102 may include one or more Local Area Networks (LANs), Wide Area Networks (WANs), Wireless Local Area Networks (WLANs), the Internet, etc.], and [ see FIG. 5, Internet or private network (552), and Managed nodes (526b)].
Regarding claim 10, Temple discloses at least a portion of the one or more components of the PKI system are within a public PKI system [Col. 3 lines 43-52, FIG. 1, which illustrates an enterprise management system 100 that includes a plurality of computing devices that are in electronic communication with one another via one or more computer networks 102. The network(s) 102 may include one or more Local Area Networks (LANs), Wide Area Networks (WANs), Wireless Local Area Networks (WLANs), the Internet, etc.], and [ see FIG. 5, Internet or private network (552), and Managed nodes (526b)].
Regarding claim 11, Temple discloses, The PKI monitoring system of claim 1, wherein the one or more components include one of a certificate authority or a hardware security module (HSM) [ see FIG 1, and corresponding text for more details, Col. 3 lines 66-67-Col. 4 lines 1-10, the enterprise management system 100 shown in FIG. 1 may implement a PKI system. The PKI system may be implemented using the core servers 114 and the agents 136 running on the managed nodes 126. One of the core servers 114 may be designated as a root core server 114a. The root core server 114a may include a certificate authority 146. A digital certificate 106 that identifies the certificate authority 146 may be referred to as a root certificate 106. The root certificate 106 may include a public key 110 of the certificate authority 146 and information 108 identifying the certificate authority 146. The root certificate 106 may be associated with a private key 112 of the certificate authority 146].
Regarding claim 12, Temple discloses, wherein the controller is installed on a server that is communicatively coupled to the PKI system and the one or more components thereof [ see FIG.1 and corresponding text for more details].
Regarding claim 13, Temple discloses, The PKI monitoring system of claim 1, wherein the controller includes one or more user interfaces through which the functionality module can be interacted with to instruct the generation of the functionality status of the first component [ see FIGS.1, 5, 6B and corresponding text for more details].
Regarding claim 14, this claim is interpreted and rejected for the same rational set forth in claim 1.
The method of claim 15, wherein the first check of the first component includes determining a first availability status of a first functionality of the first component, and wherein the functionality status of the first component is based at least in part on the determination of the first availability status [Col. 2 lines 13-40; Col. 4 lines 38-56; Col. 5 lines 50-67; Col.6 lines 56-67- Col. 7 lines 1-2; Col. 7 lines 33-47; Col. 7 lines 58-67- Col.8 lines 1-10; Col.8 lines 11-51].
Regarding claim 16, Temple discloses, wherein the second check of the first component includes determining a second availability status of a second functionality of the first component, and wherein the functionality status of the first component is based at least in part on the determination of the second availability status [Col. 2 lines 13-40; Col. 4 lines 38-56; Col. 5 lines 50-67; Col.6 lines 56-67- Col. 7 lines 1-2; Col. 7 lines 33-47; Col. 7 lines 58-67- Col.8 lines 1-10; Col.8 lines 11-51].
Regarding claim 17, Temple discloses, wherein the dependency check of the first component includes determining an availability of a functionality of the first component that relies on a second component of the PKI system, and wherein the functionality status of the first component is based at least in part on the determination of the availability of the functionality of the first component that relies on the second component of the PKI system [Col. 2 lines 13-40; Col. 4 lines 38-56; Col. 5 lines 50-67; Col.6 lines 56-67- Col. 7 lines 1-2; Col. 7 lines 33-47; Col. 7 lines 58-67- Col.8 lines 1-10; Col.8 lines 11-51].
Regarding claim 19, Temple discloses, further including generating an alert based on the functionality status of the first component [Col. 3 lines 25-35, A key pair and its corresponding digital certificate (i.e., a digital certificate that includes the public key of the key pair) have a limited lifetime. When a key pair and its corresponding digital certificate expire, a new key pair and a new digital certificate should be issued. In many known PKI systems, the process of issuing new key pairs/digital certificates may require manual intervention from a human operator and may also require some external form of authentication to complete. One aspect of the present disclosure relates to improved techniques for issuing new key pairs and corresponding digital certificates within a PKI system], and [Col. 5 lines 28-49, as indicated above, a key pair and its corresponding digital certificate have a limited lifetime. The agent 136 may monitor 302 the lifetime of the managed node's current key pair (the managed node's current public key 128 and current private key 130) and its corresponding current managed node certificate 134. When the agent 136 determines 304 that the managed node's current key pair and corresponding current managed node certificate 134 will expire within a period of time that is less than a defined threshold (e.g., fewer than six months), the agent 136 may create 306 a new public key 128a and a new private key 130a for the managed node 126. The agent 136 may then create 308 a request for a new managed node certificate 134a. This certificate request may include the new public key 128a and identifying information 132 of the managed node 126. This certificate request may then be signed 310 by the agent 136 using the managed node's new private key 130a. The agent 136 and the core server 114 may establish 312 a direct connection. The agent 136 may authenticate 314 the connection to the core server 114 by negotiating a token using the managed node's current private key 130. The agent 136 may then send 316 its signed certificate request accompanied by the negotiated token to the core server 114], and Col.6 lines 39-55, The core server 114 and the managed node 126 may establish 412 a connection. The agent 136 and the core server 114 may authenticate 413 the connection by negotiating a token. The agent 136 may periodically poll 414 the core server 114 for updates. In response to receiving a poll from the agent 136 at some point after the core server 114 has installed 410 the new root certificate 106a, the core server 114 may notify the agent 136 that the new root certificate 106a is available and should be installed. In particular, the core server 114 may send 416 the new root certificate 106a to the agent 136 along with a notification signed by the current root certificate 106 that the new root certificate 106a should be installed. The agent 136 trusts the notification to install the new root certificate 106a because of the signature of the notification. Thus, the new root certificate 106a is authenticated using the current root certificate 106. The agent 136 may install 420 the new root certificate 106a for future secure communication].
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
See 892 for more relevant references submitted with this office action.
Medvinsky (US2023/0370270). [0069] The origin certificate may also be transmitted by the update server 168 to the client device 132 in the previous operation. In this case, the origin certificate may be persistently saved in the client device 132 along with the device certificate and the encrypted device private key. The origin certificate may have a longer lifetime than the matching device certificate derived from the origin certificate and may be utilized in the future to request other or additional device certificates. [0070] Device certificates that had been generated by update server 168 can be optionally copied back to the central PKI repository 136 for archival and for subsequent queries and reports.[0071] An authorized administrator using a key generation facility administrative processor (for example, an individual working for a network operator which had deployed the client devices 132 may want to run some queries or reports on the device certificates that had been installed on client devices 132 in their network. The queries may count numbers of client devices 132 of various models that had been provisioned with client device certificates, run reports for specific time periods, for specific factory locations (if certificate provisioning took place in a factory), etc. This report may be optionally generated based on the contents of the central credential repository 136 and/or the certificate and CRL repositories 154 and 182 and returned back to the requesting administrator via key monitoring utilities 108 and 166
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHAHRIAR ZARRINEH whose telephone number is (571)272-1207. The examiner can normally be reached Monday-Friday, 8:30am-5:30pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jorge Ortiz-Criado can be reached at 571-272-7624. 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.
/SHAHRIAR ZARRINEH/Primary Examiner, Art Unit 2496