Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
The instant application having Application No. 19/195,066 is presented for examination by the examiner.
Priority
Acknowledgment is made of applicant's claim for foreign priority under 35 U.S.C. 119(a)-(d). The certified copy has been received.
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 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.
Claims 21-25 and 29-40 are rejected under 35 U.S.C. 103 as being unpatentable over USP 9,432,356 to Johansson et al., hereinafter Johansson in view of USP Application Publication 2009/0205028 to Smeets et al., hereafter Smeets.
Regarding Claim 21
Johansson discloses:
A communication method, comprising:
sending, by a certificate application network element, a first request message to a certificate enrolment network element, wherein the first request message requests to authenticate the certificate application network element (Johansson Col 8, Line 52 - Col 10, Line 36: discloses host 138, a network element needing an identification certificate, initiating a new enrollment process with ICS 128, wherein the enrollment request is used to establish and authenticate the host's identity to the network.), the first request message comprises an identity of the certificate application network element and first information, and the first information is used to authenticate the certificate application network element (Johansson Col 9, Line 12 - Col 10, Line 36: Johansson discloses that the enrollment request from host 138 comprises HWID 610 as the identity of host 138, and a CSR containing signed key material as the first information used to authenticate host 138 to the network.);
sending, by the certificate enrolment network element, a second request message to a management network element, wherein the second request message requests to verify the first information, and the second request message comprises the first information (Johansson Col 9, Line 47 - Col 10, Line 36: discloses ICS 128, acting as the certificate enrolment network element, sending a host validity check request to PKI 130 as the management network element, wherein the validity check request comprises the host identity information received from host 138 and is used to request verification of that information.);
verifying, by the management network element, the first information based on second information locally recorded by the management network element, wherein the second information is information related to the certificate application network element (Johansson Col 3, Lines 25-37 and Col 6, Lines 6-14: discloses PKI 130, acting as the management network element, verifying the host identity information received from ICS 128 based on locally recorded host status and HWID values stored in HMDB 120, wherein the locally recorded information is related to host 138 as the certificate application network element.);
determining, by the certificate enrolment network element based on the first indication information, whether the certificate application network element is a trusted network element. (Johansson Col 7, Lines 27-65: discloses ICS 128, acting as the certificate enrolment network element, determining whether host 138 is a trusted network element based on the verification result received from PKI 130, wherein the certificate process proceeds upon successful verification and is denied otherwise.).
Johansson teaches automating the provisioning and certificate enrollment process for network hosts, including sending enrollment requests, checking host validity, and determining whether to issue a certificate based on locally recorded host status and HWID information. However, Johansson is silent in explicitly teaching sending, by the management network element, first indication information to the certificate enrolment network element, wherein the first indication information indicates whether the first information is successfully verified. On the other hand, Smeet teaches an authentication server 20 acting as an independent certification authority that provides trusted certificate verification services to a credentialing server 10, wherein the authentication server 20 returns a verification result to the credentialing server 10 indicating whether the device certificate was successfully verified (Smeet ¶[0015]). Smeet further teaches that the credentialing server 10 acts on the verification result received from authentication server 20 to determine whether to proceed with credentialing, establishing a clear pass/fail indication flowing from the verification authority back to the enrolling server (Smeet ¶[0027]). Smeet further teaches that it is advantageous for the verifying actor to be an independent entity whose business is to verify devices, making the return of a discrete verification result a natural and predictable design choice (Smeet ¶[0015]).
It would have been obvious to a POSITA to modify Johansson to incorporate Smeet's external verification result signaling mechanism in order to enable a clear and discrete trust indication to flow from the management network element back to the certificate enrolment network element, since returning a pass/fail verification result from an independent verification authority to an enrolling server is a well known and predictable technique in PKI and certificate enrollment systems. The combination merely applies a known technique of external verification server returning a discrete verification result to a known system to improve trust establishment, yielding predictable results.
Regarding Claim 22
Johansson discloses:
The method according to claim 21, wherein the first information comprises at least one of the following information:
a network element identity list, a domain identity, or an initialization certificate list, wherein the network element identity list indicates at least one network element managed by the certificate application network element, the domain identity indicates a domain in which the certificate application network element is located, and the initialization certificate list indicates at least one initialization certificate configured for the at least one network element managed by the certificate application network element (Johansson Col 7, Lines 53-65: discloses that the CSR submitted by host comprises a hostname indicating the domain in which host is located, wherein the hostname is used as part of the verification process to authenticate host to the network.).
Regarding Claim 23
Johansson teaches automating the provisioning and certificate enrollment process for network hosts, including sending enrollment requests, checking host validity, and determining whether to issue a certificate based on locally recorded host status and HWID information. However, Johansson is silent in explicitly teaching that when the first indication information indicates that the first information is successfully verified, the certificate enrolment network element determines that the certificate application network element is a trusted network element, and when the first indication information indicates that the first information fails to be verified, the certificate enrolment network element determines that the certificate application network element is an untrusted network element. On the other hand, Smeet teaches that credentialing server 10, acting as the certificate enrolment network element, explicitly determines whether a communication device is trusted or untrusted based on the verification result received from authentication server 20, wherein a successful verification results in the device being determined trusted and credentialing proceeding (Smeet ¶[0027]). Smeet further teaches that the credentialing server 10 uses an independent CA to verify the device certificate and determine whether the device can be trusted by the operator, establishing a clear binary trust determination directly driven by the verification result received from the external verification authority (Smeet ¶[0043]).
It would have been obvious to a POSITA to modify Johansson to incorporate Smeet's explicit binary trust determination mechanism in order to provide a clear and actionable trust outcome at the certificate enrolment network element based on the verification result received from the management network element, since determining whether a device is trusted or untrusted based on an external verification result is a well known and predictable design choice in PKI and certificate enrollment systems. The combination merely applies a known technique of binary trust determination based on an external verification result to a known system to improve trust establishment clarity, yielding predictable results.
Regarding Claim 24
Johansson teaches automating the provisioning and certificate enrollment process for network hosts, including sending enrollment requests, checking host validity, and determining whether to issue a certificate based on locally recorded host status and HWID information. However, Johansson is silent in explicitly teaching that the first indication information further comprises a signature of the management network element, and the signature of the management network element is used to verify whether the first indication information is trustworthy. On the other hand, Smeet teaches that authentication server 20 implements online certificate status protocol (OCSP) to return verification results to credentialing server 10, wherein the authentication server 20 correspondingly is a third-party, independent OCSP server (Smeet ¶[0015]). Smeet further teaches that OCSP is an Internet protocol used for obtaining the revocation status of X.509 digital certificates, and that a common PKI may be used for operator and device certificates (Smeet ¶[0016]). As is well known to a POSITA, OCSP responses are digitally signed by the responding server under RFC 2560, and the recipient must validate the signature on the response before accepting it as valid, thereby ensuring the trustworthiness of the verification result returned by the authentication server 20 to the credentialing server 10.
It would have been obvious to a POSITA to modify Johansson to incorporate Smeet's OCSP verification result signaling, including the digital signature of the responding server, in order to ensure the trustworthiness of the first indication information flowing from the management network element back to the certificate enrolment network element, since digitally signing verification responses is a fundamental and well known requirement of the OCSP protocol and a predictable design choice in PKI and certificate enrollment systems. The combination merely applies a known technique of signed verification responses to a known system to improve the integrity and trustworthiness of the verification indication, yielding predictable results.
Regarding Claim 25
Johansson discloses:
The method according to claim 21, wherein the method further comprises:
sending, by the certificate enrolment network element, a first response message to the certificate application network element, wherein the first response message indicates whether the certificate application network element is a trusted network element (Johansson Col 9, Line 61 - Col 10, Line 36: discloses ICS 128, acting as the certificate enrolment network element, sending a response message back to host 138 as the certificate application network element following the validity check, wherein the response indicates that host 138 is approved as a trusted network element.).
Regarding Claim 29
Johansson discloses:
The method according to claim 21, wherein:
the first information is a network element identity list, and an identity that is of one or more network elements managed by the certificate application network element and that is locally recorded by the management network element constitutes the network element identity list, and the management network element determines that the first information is successfully verified; or
the first information is an initialization certificate list, an initialization certificate that corresponds to one or more network elements managed by the certificate application network element and that is locally recorded by the management network element constitutes the initialization certificate list, and all initialization certificates in the initialization certificate list are valid, and the management network element determines that the first information is successfully verified; or
the first information is a domain identity, and an identity that is of the domain to which the certificate application network element belongs and that is locally recorded by the management network element is the domain identity, and the management network element determines that the first information is successfully verified (Johansson Col 7, Line 53 - Col 8, Line 7: discloses that CAM 410 resolves the hostname indicated in the CSR against a locally recorded network address at a name server, wherein the hostname constitutes the domain identity of host 138, and the management network element determines the first information is successfully verified when the locally recorded domain identity matches the domain identity provided in the CSR.).
Regarding Claim 30
Johansson discloses:
The method according to claim 21, wherein the second information comprises at least one of the following information:
initialization information of the certificate application network element, configuration information of the certificate application network element, or management information of the certificate application network element (Johansson Col 7, Line 12 - Col 8, Lin 23: discloses that HMDB 120 locally records host status, HWID, and provisioning expiration date related to host 138 as the certificate application network element, wherein this locally recorded information constitutes management information of host 138 used to verify the enrollment request.).
Regarding Claim 31
Claim 31 is directed to a communication method corresponding to the method of claim 21. Claim 31 is similar in scope to claim 21 and is therefore rejected under similar rationale.
Regarding Claim 32 Claim 32 is directed to a communication method corresponding to the method of claim 22. Claim 32 is similar in scope to claim 22 and is therefore rejected under similar rationale.
Regarding Claim 33 Claim 32 is directed to a communication method corresponding to the method of claim 23. Claim 32 is similar in scope to claim 23 and is therefore rejected under similar rationale.
Regarding Claim 34 Claim 34 is directed to a communication method corresponding to the method of claim 24. Claim 34 is similar in scope to claim 24 and is therefore rejected under similar rationale.
Regarding Claim 35 Claim 35 is directed to a communication method corresponding to the method of claim 25. Claim 35 is similar in scope to claim 25 and is therefore rejected under similar rationale.
Regarding Claim 36
Claim 36 is directed to a certificate enrolment network element corresponding to the method of claim 21. Claim 36 is similar in scope to claim 21 and is therefore rejected under similar rationale.
Regarding Claim 37
Claim 37 is directed to a certificate enrolment network element corresponding to the method of claim 22. Claim 37 is similar in scope to claim 22 and is therefore rejected under similar rationale.
Regarding Claim 38
Claim 38 is directed to a certificate enrolment network element corresponding to the method of claim 23. Claim 38 is similar in scope to claim 23 and is therefore rejected under similar rationale.
Regarding Claim 39
Claim 39 is directed to a certificate enrolment network element corresponding to the method of claim 24. Claim 39 is similar in scope to claim 24 and is therefore rejected under similar rationale.
Regarding Claim 40
Claim 40 is directed to a certificate enrolment network element corresponding to the method of claim 25. Claim 40 is similar in scope to claim 25 and is therefore rejected under similar rationale.
Claims 26-27 are rejected under 35 U.S.C. 103 as being unpatentable over Johansson and Smeets as applied to claims 21, 31 and 36 above, and further in view of WO Application Publication 2020/082164 to Sau et al., hereafter Sau.
Regarding Claim 26
Johansson and Smeet teach automating the provisioning and certificate enrollment process for network hosts, including sending enrollment requests, checking host validity, and receiving a verification result indicating whether the device certificate was successfully verified. However, Johansson and Smeet are silent in explicitly teaching sending, by a first network element, a service certificate request message to the certificate application network element, wherein the service certificate request message requests the certificate application network element to apply for a service certificate on behalf of the first network element; and determining, by the certificate application network element according to a rule, whether to respond to a request of the first network element for applying for a service certificate. On the other hand, Sau teaches a network entity sending a certificate enrollment request to enrollment service 912 acting as a certificate application front-end, wherein enrollment service 912 issues a certificate enrollment request on behalf of the network entity to invoke issuance of a digital certificate from the certification authority (Sau ¶[0024]). Sau further teaches that enrollment service 912 enforces policies to determine whether to respond to a certificate request, wherein the request is authorized to proceed only when the authenticated request matches the intended user and subject defined by the augmented OTP policies (Sau ¶[0098]). Sau further teaches that when a mismatch is identified between the originating user and the policies, the enrollment service 912 automatically rejects the certificate request, establishing a rule determination of whether to respond to a certificate enrollment request (Sau ¶[0099]).
It would have been obvious to a POSITA to modify Johansson and Smeet to incorporate Sau's proxy certificate enrollment mechanism and rule determination in order to enable a first network element to delegate certificate enrollment to a certificate application network element that applies policies to determine whether to respond to the request, since proxy certificate enrollment with policy based authorization is a well known and predictable technique in PKI and certificate enrollment systems. The combination merely applies a known technique of proxy certificate enrollment with rule policy enforcement to a known system to improve certificate enrollment flexibility and security, yielding predictable results.
Regarding Claim 27
Johansson discloses:
The method according to claim 26, wherein the service certificate request message comprises an identity of the first network element and at least one of the following information:
a public key corresponding to the first network element, a private key corresponding to the first network element, an initialization certificate configured for the first network element, or service type indication information (Johansson Col 10, Lines 1-14: discloses that host 138 submits a CSR to PKI 130 comprising the HWID as the identity of host 138 and a CA certificate as an initialization certificate configured for host 138).
Claims 28 are rejected under 35 U.S.C. 103 as being unpatentable over Johansson, Smeets and Sau as applied to claims 26 above, and further in view of WO Application Publication 2014/123557 to Galehouse et al., hereafter Galehouse.
Regarding claim 28
Johansson and Smeet teach automating the provisioning and certificate enrollment process for network hosts, including sending enrollment requests, checking host validity, and receiving a verification result indicating whether the device certificate was successfully verified. Sau further teaches a proxy certificate enrollment mechanism wherein an enrollment service issues certificate requests on behalf of a network entity and applies policies to determine whether to respond to a certificate request. However, Johansson, Smeet, and Sau are silent in explicitly teaching that when a type of the service certificate requested is a first type, the certificate application network element verifies according to a rule whether the first network element can apply for a service certificate of that first type, and when verification fails, sends a failure indication to the first network element indicating that the request is invalid. On the other hand, Galehouse teaches that SCEP Server 12 determines whether the requester is allowed to request a particular certificate type by verifying the request against stored SCEP challenge datasets according to enforced policies (Galehouse ¶[0032]). Galehouse further teaches that when the SCEP Validation Service 22 indicates that the information does not match what is expected, the SCEP Enforcement Module 24 denies the request, establishing a clear rule-based certificate type verification mechanism (Galehouse ¶[0030]). Galehouse further teaches that when verification fails and a matching SCEP challenge dataset is not found, a negative response is returned to the requesting device indicating that the certificate request is invalid and a certificate is not provided (Galehouse ¶[0032]).
It would have been obvious to a POSITA to modify Johansson, Smeet, and Sau to incorporate Galehouse's certificate type verification and failure indication mechanism in order to enable the certificate application network element to verify whether the first network element is authorized to apply for a specific type of service certificate and return a failure indication when verification fails, since rule based certificate type verification with a negative response upon failure is a well known and predictable technique in PKI and certificate enrollment systems. The combination merely applies a known technique of certificate type verification with failure indication to a known system to improve certificate enrollment security and authorization control, yielding predictable results.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAAD ABDULLAH whose telephone number is 571-272-1531. The examiner can normally be reached on Monday-Friday 9am-5pm EST. If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, LYNN FIELD can be reached on 571-272-2092.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SAAD AHMAD ABDULLAH/ Examiner, Art Unit 2431
/MICHAEL R VAUGHAN/ Primary Examiner, Art Unit 2431
Prosecution Insights