DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
The information disclosure statement (IDS) submitted by applicant dated 06/12/2025 has been considered by the examiner.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claim 20 is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
As per claim 20, the claim recites a computer readable storage medium, which may be interpreted as a signal or carrier wave. This does not fall under one of the four statutory categories. The examiner suggests amending the claim to recite a non-transitory computer readable storage medium.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-6 and 18-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by 3GPP TR 33.876 V0.4.0 “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Study on Automated Certificate Management in SBA; (Release 18) (hereinafter 3GPP).
As per claim 1, 3GPP teaches a communication method, applied to a second entity, comprising: receiving a request message from a network function entity, wherein the request message comprises an initial certificate signed by a first entity for the network function entity and identity information of the network function entity, and the first entity is a trusted entity of the second entity (3GPP pgs 13, 23-24, CSRs contains a trusted and unique identity of the NF instance requesting the certificate. The public root certificate of the private CA is configured as trust anchor in the operator PKI. The NF, sends the signed certificate enrolment request to the operator CA. The request includes public key of NF, proof of possession of the public key, the Private CA signed initial certificate, and the certificate chain of the Private CA.);
verifying consistency between the initial certificate signed by the first entity for the network function entity and the identity information of the network function entity (3GPP pgs 23-24, The operator CA verifies the digital signature on the certificate enrolment request against the Private CA root certificate (trust anchor) using the initial certificate sent by the NF, and also verifies the proof of possession of the private key for the requested certificate); and
signing an end entity certificate for the network function entity in response to a verification result being that the verification succeeds (3GPP pgs 23-24, The operator CA generates the certificate for the NF and sends a signed response to the NF).
As per claim 2, 3GPP teaches the method according to claim 1, wherein the identity information of the network function entity is an instance identifier of the network function entity (3GPP pgs 13, CSRs contains a trusted and unique identity of the NF instance requesting the certificate.).
As per claim 3, 3GPP teaches the method according to claim 1, wherein that the first entity is a trusted entity of the second entity comprises: a root certificate of the first entity is stored in the second entity (3GPP pgs 23-24, The public root certificate of the private CA is configured as trust anchor in the operator PKI.).
As per claim 4, 3GPP teaches the method according to claim 1, wherein the first entity and the second entity are different certificate authorities (CAs) (3GPP pgs 23-24, private CA and operator CA).
As per claim 5, 3GPP teaches the method according to claim 1, wherein the initial certificate signed by the first entity for the network function entity comprises identity information of the network function entity, and the verifying consistency between the initial certificate signed by the first entity for the network function entity and the identity information of the network function entity includes: verifying whether the identity information of the network function entity that is included in the initial certificate is consistent with the identity information of the network function entity that is included in the request message (3GPP pg 13, CSRs contains a trusted and unique identity of the NF instance requesting the certificate. 3GPP TS 33.310 [3] in clause 6.1.3c describes that, as part of the SBA NF certificate profile, the subjectAltName (SAN) field should contain a URI-ID with the URI for the NF instance ID as an URN. This URI-ID must contain the identifier of the NF (e.g., SCP, SEPP, NRF, AF, etc.) instance (nfInstanceID), only using the format of clause 5.3.2 of TS 29.571 [7], what is a Universally Unique IDentifier (UUID). Thus, the flexibility that a service mesh could offer by integrating different types of services across heterogeneous environments (and in case of 5GS across different operator domains) is limited by the use of UUID as identifier. Operator RA/CA would need to keep track on UUIDs in order to be able to verify and accept the CSRs, only based on those identifiers. Pgs 23-24, The NF, sends the signed certificate enrolment request to the operator CA. The request includes public key of NF, proof of possession of the public key, the Private CA signed initial certificate, and the certificate chain of the Private CA. The operator CA verifies the digital signature on the certificate enrolment request against the Private CA root certificate (trust anchor) using the initial certificate sent by the NF. Pg 33, CA verifies the received parameters, including the NF profile signature.).
As per claim 6, 3GPP teaches the method according to claim 1, wherein the initial certificate further comprises usage information, and the usage information is usable to indicate a purpose of an end entity certificate that the initial certificate can be used to request (3GPP pgs 13, When a NF requests a X.509 certificate it sends a Certificate Signing Request (CSR) message to the CA. 3GPP TS 33.310 [3] in clause 6.1.3c describes a SBA NF certificate profile. NF certificates include a plurality of parameters that is usable to indicate a purpose).
As per claim 18, 3GPP teaches the method according to claim 1, wherein the method further comprises: sending, by the network function entity, the request message to the second entity; and receiving, by the network function entity, the end entity certificate from the second entity (3GPP pgs 13, 23-24, CSRs contains a trusted and unique identity of the NF instance requesting the certificate. The public root certificate of the private CA is configured as trust anchor in the operator PKI. The NF, sends the signed certificate enrolment request to the operator CA. The request includes public key of NF, proof of possession of the public key, the Private CA signed initial certificate, and the certificate chain of the Private CA. The operator CA generates the certificate for the NF and sends a signed response to the NF).
As per claims 19-20, the claims claim an apparatus and a computer-readable storage medium essentially corresponding to the method claim 1 above, and they are rejected, at least for the same reasons.
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, 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 8-10 are rejected under 35 U.S.C. 103 as being unpatentable over 3GPP, in view of Kodera et al. US 2019/0280882 (hereinafter Kodera).
As per claim 8, 3GPP teaches the method according to claim 1.
3GPP does not explicitly disclose wherein the method further comprises: sending, by the second entity, a revocation request message to the first entity, wherein the revocation request message is usable to request to revoke the initial certificate.
Kodera teaches wherein method further comprises: sending, by second entity, a revocation request message to first entity, wherein the revocation request message is usable to request to revoke initial certificate (Kodera paragraph [0019], sending a certificate revocation request to revoke certificate).
Thus 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 invention of 3GPP of issuing certificates with the teachings of Kodera to include sending and verifying a certificate revocation request to revoke certificate in order to revoke the initial certificate when it’s no longer needed.
As per claim 9, 3GPP in view of Kodera teaches the method according to claim 8, wherein before the sending, by the second entity, a revocation request message to the first entity, the method further comprises: signing, by the second entity, the revocation request message, for the first entity to verify the second entity (3GPP pgs 23-24; Kodera paragraph [0024], verifying the signature of the revocation request).
As per claim 10, 3GPP in view of Kodera the method according to claim 8, wherein before the sending, by the second entity, a revocation request message to the first entity, the method further comprises: receiving, by the second entity, a response message from the network function entity, wherein the response message is usable to indicate that the network function entity has completed enrollment of the end entity certificate (3GPP pgs 21, 23-24, Initialization responses and key update responses are always followed by a Certificate Confirm request and Confirmation response message exchange; Kodera paragraph [0019], sending a certificate revocation request to revoke certificate).
Claims 11 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over 3GPP, in view of Whitfield USPN 7,209,889.
As per claim 11, 3GPP teaches the method according to claim 1, signing an end entity certificate for the network function entity (3GPP pgs 23-24, The operator CA generates the certificate for the NF and sends a signed response to the NF).
3GPP does not explicitly disclose wherein after using certificate, method further comprises: marking, by second entity, a status of initial certificate as used.
Whitfield teaches wherein after using certificate, method further comprises: marking, by second entity, a status of initial certificate as used (Whitfield col 9 lines 55-65, after using certificate, marking the certificate as used).
Thus 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 invention of 3GPP of issuing and using the initial certificate with the teachings of Whitfield to include after using a certificate, marking the certificate as used in order to provide single use of the initial certificate.
As per claim 14, 3GPP in view of Whitfield teaches the method according to claim 11, wherein the signing an end entity certificate for the network function entity in response to a verification result being that the verification succeeds includes: signing the end entity certificate for the network function entity in response to the verification result being that the verification succeeds, and the status of the initial certificate is determined to not be marked as used (3GPP pgs 23-24, The operator CA generates the certificate for the NF and sends a signed response to the NF; Whitfield col 9 lines 35-52, checking the validity of the certificate, such as it has not been used yet).
Allowable Subject Matter
Claims 7, 12-13 and 15-17 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HENRY TSANG whose telephone number is (571)270-7959. The examiner can normally be reached M-F 9am - 5pm EST.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Farid Homayounmehr can be reached at (571) 272-3739. 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.
/HENRY TSANG/ Primary Examiner, Art Unit 2495
Prosecution Insights