DETAILED ACTION
This non-final office action is in response to claims 1-20 filed on 01/15/2026 for examination. Claims 1-20 are being examined and are pending.
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 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.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 01/15/2025 and 05/13/2025 have been considered by the examiner.
Consideration Under 35 USC § 101
Note: the claims have been considered and analyzed by the Examiner under 35 USC § 101 with respect to statutory category and judicial exceptions, and appear to recite a form of subject matter statutorily compliant with § 101.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-2, 5-11, 14-16, and 19-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bommisetty et al. (WO2025094151A1; hereinafter “Bommisetty”) in view of Wendt et al. (NPL: “RFC 9448: TNAuthList Profile of Automated Certificate Management Environment (ACME) Authority Token”; September 12, 2023; Hereinafter “RFC 9448”).
Regarding claim 1, Bommisetty teaches a method performed via communications performed at least by a network function (NF) of a mobile core network (abstract; pg. 7, line 25-pg. 10, line 5 – network function “NF” of mobile core network performs communications), the method comprising:
obtaining, from a token authority service, an authority token that identifies at least an instance identifier (ID) of the NF (pg. 9, line 23-pg. 10, line 5; and pg. 13, line 6-pg.14, line 9 – OAM system <i.e., token authority service> provides an OAM-issued certificate/IAK/signature <i.e., authority token> to the NF. The OAM issued certificate includes an NF Instance ID), wherein the token authority service has a pre-established trust relationship with a certificate authority service (pg. 13, line 6-pg.14, line 9; and pg. 9, line 23-pg. 10, line 5 – OAM system <i.e., token authority service> is has preestablished trust with operator certificate authority <i.e., certificate authority service>);
for a certificate enrollment process, transmitting a certificate order to the certificate authority service that includes the instance ID of the NF identified in the authority token (pg. 12, line 13-pg. 14, line 9; pg. 16, lines 17-23; and pg. 20, line 19-pg. 21, line 2 – NF Instance ID from the OAM issued certificate/IAK/signature <i.e., authority token> goes into a CSR/certificate request <i.e., certificate order>. The CSR/certificate request <i.e., certificate order> is transmitted to the certificate authority/ACME server <i.e., certificate authority service>).
While Bommisetty further teaches issuing a certificate upon validation of the NF Instance ID (see, e.g., pg. 20, line 19-pg. 21, line 12; and pg. 22, lines 5-30), Bommisetty appears to fail to specifically disclose obtaining a response from the certificate authority service that includes an authorization internet address for the certificate authority service; transmitting a challenge query to the certificate authority service via the authorization internet address; obtaining a challenge response from the certificate authority service indicating an authority token challenge type for validating the authority token of the NF and including a challenge internet address; transmitting the authority token obtained from the token authority service to the certificate authority service via the challenge internet address; and upon validation of the authority token by the certificate authority service, obtaining, from the certificate authority service, a signed certificate or a certificate internet address from which the NF is to obtain the signed certificate for the certificate enrollment process.
However, RFC 9448 teaches a similar system for processing a certificate order with an ID (see, e.g., § 3-4), comprising obtaining a response from the certificate authority service that includes an authorization internet address for the certificate authority service (§ 3-4 – an ACME “new-order” is received. The ACME server creates an authorization object, and then adds an authorization object URL <i.e., authorization internet address> the ACME order response <i.e., response from the certificate authority service>);
transmitting a challenge query to the certificate authority service via the authorization internet address (§ 3-4 – upon receiving the response, the ACME client sends a POST request/query <i.e., challenge query> using the authorization object URL <i.e., authorization internet address);
obtaining a challenge response from the certificate authority service indicating an authority token challenge type for validating the authority token of the |ACME Client| and including a challenge internet address (§ 3-4 – the ACME server receives a POST request/query <i.e., challenge query>. A ”tkauth-01” with “tkauth-type:atc” <i.e., authority token challenge type> and a challenge URL <i.e., challenge internet address> go into the challenge response from the ACME server <i.e., certificate authority service> and is provided to the ACME client <i.e., obtaining challenge response>);
transmitting the authority token obtained from the token authority service to the certificate authority service via the challenge internet address (§ 3-4 – the ACME client response to the challenge by posting/transmitting the Authority Token to the challenge URL <i.e., challenge internet address>); and
upon validation of the authority token by the certificate authority service, obtaining, from the certificate authority service, a signed certificate or a certificate internet address from which the |ACME Client| is to obtain the signed certificate for the certificate enrollment process (§ 3-4 – the certificate authority validates the Authority Token by validating the atc claim/trusted issuer certificate/token signature/tkvalue/fingerprint. If successfully validated, the valid ACME order response includes a signed certificate URL/x5u URL <i.e., certificate internet address> where the ACME client can retrieve the signed certificate).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bommisetty with the teachings of RFC 9448, comprising obtaining a response from the certificate authority service that includes an authorization internet address for the certificate authority service; transmitting a challenge query to the certificate authority service via the authorization internet address; obtaining a challenge response from the certificate authority service indicating an authority token challenge type for validating the authority token of the NF and including a challenge internet address; transmitting the authority token obtained from the token authority service to the certificate authority service via the challenge internet address; and upon validation of the authority token by the certificate authority service, obtaining, from the certificate authority service, a signed certificate or a certificate internet address from which the NF is to obtain the signed certificate for the certificate enrollment process, to provide a standardized automated proof of authority over the requested NF Instance ID (see, e.g., Bommisetty at pg. 20, line 19-pg. 21, line 12 and pg. 22, lines 5-30; with RFC 9448 at § 3-4).
Regarding claim 2, the combination of Bommisetty and RFC 9448 teach the method of claim 1, wherein the communications between the NF and the token authority service and between the NF and the certificate authority service include Automated Certificate Management Environment (ACME) protocol communications (Bommisetty at pg. 14, lines 23-34; pg. 15 line 31-pg. 16 line 7, and pg. 16, line 17-pg. 17, line 26 – ACME client of the NF communicates using the ACME protocol with the certificate authority <i.e., certificate authority service>; with RFC 9448 at § 1, 4, 5.5 – the ACME client <i.e., NF as modified> communicates with the Token Authority <i.e., token authority service> to obtain the Authority Token as part of an ACME Authority Token/RFC framework <i.e., protocol communications>). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bommisetty with the teachings of RFC 9448, wherein the communications between the NF and the token authority service and between the NF and the certificate authority service include Automated Certificate Management Environment (ACME) protocol communications, to provide a standardized automated proof of authority over the requested NF Instance ID (see, e.g., Bommisetty at pg. 20, line 19-pg. 21, line 12 and pg. 22, lines 5-30; with RFC 9448 at § 3-4).
Regarding claim 5, the combination of Bommisetty and RFC 9448 teach the method of claim 1, wherein obtaining the authority token from the token authority service includes transmitting a Hypertext Transfer Protocol (HTTP) POST request communication to the token authority service that includes an account identifier corresponding to an account established between the NF and the token authority service and includes the instance ID of the NF (Bommisetty at pg. 13, line 21-pg. 14 line 9 – OAM system <i.e., token authority service> provides initial trust material <i.e., authority token> to NF where the credential identifies NF instance ID; with RFC 9448 at § 5.5 – account identifier <i.e., account ID corresponding to established account> and tkvalue <i.e., Instance ID> go into a HTTP POST token request for acquiring the authority token). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bommisetty with the teachings of RFC 9448, wherein obtaining the authority token from the token authority service includes transmitting a Hypertext Transfer Protocol (HTTP) POST request communication to the token authority service that includes an account identifier corresponding to an account established between the NF and the token authority service and includes the instance ID of the NF, to provide a standardized automated proof of authority over the requested NF Instance ID (see, e.g., Bommisetty at pg. 20, line 19-pg. 21, line 12 and pg. 22, lines 5-30; with RFC 9448 at § 3-4).
Regarding claim 6, the combination of Bommisetty and RFC 9448 teach the method of claim 1, wherein the token authority service is an Operations, Administration, and Maintenance (OAM) server (pg. 13, line 21-pg. 14 line 9 – the token authority service is an OAM server).
Regarding claim 7, the combination of Bommisetty and RFC 9448 teach the method of claim 1, wherein: the certificate order is included in a first Hypertext Transfer Protocol (HTTP) POST request communicated to the certificate authority service (RFC 9448 at §3 – identifier-containing ACME new-order request <i.e., certificate order> goes into HTTP POST/acme/new-order <i.e., first HTTP POST request> sent to the certificate authority); the challenge query is included in a second HTTP POST request communicated to the certificate authority service (RFC 9448 at §4 – authorization object query <i.e., challenge query> goes into HTTP POST/acme/authz/1234 <i.e., second HTTP POST request> communicated to the certificate authority service); and the authority token is included in a third HTTP POST request communicated to the certificate authority service (RFC 9448 at §4 – Authority token/tkauth value goes into POST/acme/chall <i.e., third HTTP POST request> communicated to the certificate authority). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bommisetty with the teachings of RFC 9448, wherein: the certificate order is included in a first Hypertext Transfer Protocol (HTTP) POST request communicated to the certificate authority service; the challenge query is included in a second HTTP POST request communicated to the certificate authority service; and the authority token is included in a third HTTP POST request communicated to the certificate authority service, to provide a standardized automated proof of authority over the requested NF Instance ID (see, e.g., Bommisetty at pg. 20, line 19-pg. 21, line 12 and pg. 22, lines 5-30; with RFC 9448 at § 3-4).
Regarding claim 8, the combination of Bommisetty and RFC 9448 teach the method of claim 1, further comprising: obtaining the signed certificate via the certificate internet address to enable the NF to securely communicate with one or more other network functions of the mobile core network (Bommisetty at pg. 11, line 3-pg. 13, line 5; and pg. 7, lines 25-31 – signed digital certificate is used by NF service provider/NF service consumer to enable encrypted TLS communications <i.e., secure communication> with the 5GC/SBA; with RFC9448 – certificate URL/x5u URL <i.e., certificate internet address> is used to obtain/reference the signed certificate). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bommisetty with the teachings of RFC 9448, comprising: obtaining the signed certificate via the certificate internet address to enable the NF to securely communicate with one or more other network functions of the mobile core network, to provide a standardized automated proof of authority over the requested NF Instance ID (see, e.g., Bommisetty at pg. 20, line 19-pg. 21, line 12 and pg. 22, lines 5-30; with RFC 9448 at § 3-4).
Regarding claim 9, the combination of Bommisetty and RFC 9448 teach the method of claim 1, wherein the mobile core network is a Third Generation Partnership Project (3GPP) Fifth Generation (5G) mobile core network or next Generation (nG) mobile core network (pg. 7, lines 25-31; and pg. 11, line 3-pg. 13, line 5 – mobile core network may be a 3GPP 5G mobile core network).
Regarding claim 10, Bommisetty teaches one or more non-transitory computer readable storage media encoded with instructions that, when executed by a processor, cause the processor to perform operations including communications (abstract; pg. 7, line 25-pg. 10, line 5 – network function of mobile core network performs communications. The system is implemented via computer processors executing code stored in memory), comprising:
obtaining, by a network function (NF) of a mobile core network from a token authority service, an authority token that identifies at least an instance identifier (ID) of the NF (pg. 9, line 23-pg. 10, line 5; pg. 13, line 6-pg.14, line 9 – OAM system <i.e., token authority service> provides an OAM-issued certificate/IAK/signature <i.e., authority token> to the NF. The OAM issued certificate includes an NF Instance ID), wherein the token authority service has a pre-established trust relationship with a certificate authority service (pg. 13, line 6-pg.14, line 9; pg. 9, line 23-pg. 10, line 5 – OAM system <i.e., token authority service> is has preestablished trust with operator certificate authority <i.e., certificate authority service>);
for a certificate enrollment process, transmitting a certificate order to the certificate authority service that includes the instance ID of the NF identified in the authority token (pg. 12, line 13-pg. 14, line 9; pg. 16, lines 17-23; and pg. 20, line 19-pg. 21, line 2 – NF Instance ID from the OAM issued certificate/IAK/signature <i.e., authority token> goes into a CSR/certificate request <i.e., certificate order>. The CSR/certificate request <i.e., certificate order> is transmitted to the certificate authority/ACME server <i.e., certificate authority service>).
While Bommisetty further teaches issuing a certificate upon validation of the NF Instance ID (see, e.g., pg. 20, line 19-pg. 21, line 12; pg. 22, lines 5-30), Bommisetty appears to fail to specifically disclose obtaining a response from the certificate authority service that includes an authorization internet address for the certificate authority service; transmitting a challenge query to the certificate authority service via the authorization internet address; obtaining a challenge response from the certificate authority service indicating an authority token challenge type for validating the authority token of the NF and including a challenge internet address; transmitting the authority token obtained from the token authority service to the certificate authority service via the challenge internet address; and upon validation of the authority token by the certificate authority service, obtaining, from the certificate authority service, a signed certificate or a certificate internet address from which the NF is to obtain the signed certificate for the certificate enrollment process.
However, RFC 9448 teaches a similar system for processing a certificate order with an ID (see, e.g., § 3-4), comprising obtaining a response from the certificate authority service that includes an authorization internet address for the certificate authority service (§ 3-4 – an ACME “new-order” is received. The ACME server creates an authorization object, and then adds an authorization object URL <i.e., authorization internet address> the ACME order response <i.e., response from the certificate authority service>);
transmitting a challenge query to the certificate authority service via the authorization internet address (§ 3-4 – upon receiving the response, the ACME client sends a POST request/query <i.e., challenge query> using the authorization object URL <i.e., authorization internet address);
obtaining a challenge response from the certificate authority service indicating an authority token challenge type for validating the authority token of the |ACME Client| and including a challenge internet address (§ 3-4 – the ACME server receives a POST request/query <i.e., challenge query>. A ”tkauth-01” with “tkauth-type:atc” <i.e., authority token challenge type> and a challenge URL <i.e., challenge internet address> go into the challenge response from the ACME server <i.e., certificate authority service> and is provided to the ACME client <i.e., obtaining challenge response>);
transmitting the authority token obtained from the token authority service to the certificate authority service via the challenge internet address (§ 3-4 – the ACME client response to the challenge by posting/transmitting the Authority Token to the challenge URL <i.e., challenge internet address>); and
upon validation of the authority token by the certificate authority service, obtaining, from the certificate authority service, a signed certificate or a certificate internet address from which the |ACME Client| is to obtain the signed certificate for the certificate enrollment process (§ 3-4 – the certificate authority validates the Authority Token by validating the atc claim/trusted issuer certificate/token signature/tkvalue/fingerprint. If successfully validated, the valid ACME order response includes a signed certificate URL/x5u URL <i.e., certificate internet address> where the ACME client can retrieve the signed certificate).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bommisetty with the teachings of RFC 9448, comprising obtaining a response from the certificate authority service that includes an authorization internet address for the certificate authority service; transmitting a challenge query to the certificate authority service via the authorization internet address; obtaining a challenge response from the certificate authority service indicating an authority token challenge type for validating the authority token of the NF and including a challenge internet address; transmitting the authority token obtained from the token authority service to the certificate authority service via the challenge internet address; and upon validation of the authority token by the certificate authority service, obtaining, from the certificate authority service, a signed certificate or a certificate internet address from which the NF is to obtain the signed certificate for the certificate enrollment process, to provide a standardized automated proof of authority over the requested NF Instance ID (see, e.g., Bommisetty at pg. 20, line 19-pg. 21, line 12 and pg. 22, lines 5-30; with RFC 9448 at § 3-4).
Regarding claim 11, the combination of Bommisetty and RFC 9448 teach the media of claim 10, wherein communications between the NF and the token authority service and between the NF and the certificate authority service include Automated Certificate Management Environment (ACME) protocol communications (Bommisetty at pg. 14, lines 23-34; pg. 15 line 31-pg. 16 line 7, and pg. 16, line 17-pg. 17, line 26 – ACME client of the NF communicates using the ACME protocol with the certificate authority <i.e., certificate authority service>; with RFC 9448 at § 1, 4, 5.5 – the ACME client <i.e., NF as modified> communicates with the Token Authority <i.e., token authority service> to obtain the Authority Token as part of an ACME Authority Token/RFC framework <i.e., protocol communications>). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bommisetty with the teachings of RFC 9448, wherein the communications between the NF and the token authority service and between the NF and the certificate authority service include Automated Certificate Management Environment (ACME) protocol communications, to provide a standardized automated proof of authority over the requested NF Instance ID (see, e.g., Bommisetty at pg. 20, line 19-pg. 21, line 12 and pg. 22, lines 5-30; with RFC 9448 at § 3-4).
Regarding claim 14, the combination of Bommisetty and RFC 9448 teach the media of claim 10, wherein:
the certificate order is included in a first Hypertext Transfer Protocol (HTTP) POST request communicated to the certificate authority service (RFC 9448 at §3 – identifier-containing ACME new-order request <i.e., certificate order> goes into HTTP POST/acme/new-order <i.e., first HTTP POST request> sent to the certificate authority);
the challenge query is included in a second HTTP POST request communicated to the certificate authority service (RFC 9448 at §4 – authorization object query <i.e., challenge query> goes into HTTP POST/acme/authz/1234 <i.e., second HTTP POST request> communicated to the certificate authority service); and
the authority token is included in a third HTTP POST request communicated to the certificate authority service (RFC 9448 at §4 – Authority token/tkauth value goes into POST/acme/chall <i.e., third HTTP POST request> communicated to the certificate authority). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bommisetty with the teachings of RFC 9448, wherein: the certificate order is included in a first Hypertext Transfer Protocol (HTTP) POST request communicated to the certificate authority service; the challenge query is included in a second HTTP POST request communicated to the certificate authority service; and the authority token is included in a third HTTP POST request communicated to the certificate authority service, to provide a standardized automated proof of authority over the requested NF Instance ID (see, e.g., Bommisetty at pg. 20, line 19-pg. 21, line 12 and pg. 22, lines 5-30; with RFC 9448 at § 3-4).
Regarding claim 15, Bommisetty teaches An apparatus comprising:
at least one memory element for storing data; and at least one processor for executing instructions associated with the data, wherein executing the instructions causes the apparatus to perform operations including communications (abstract; pg. 7, line 25-pg. 10, line 5 – network function of mobile core network performs communications. The system is implemented via computer processors executing code stored in memory), comprising:
obtaining, by a network function (NF) of a mobile core network from a token authority service, an authority token that identifies at least an instance identifier (ID) of the NF (pg. 9, line 23-pg. 10, line 5; pg. 13, line 6-pg.14, line 9 – OAM system <i.e., token authority service> provides an OAM-issued certificate/IAK/signature <i.e., authority token> to the NF. The OAM issued certificate includes an NF Instance ID), wherein the token authority service has a pre-established trust relationship with a certificate authority service (pg. 13, line 6-pg.14, line 9; pg. 9, line 23-pg. 10, line 5 – OAM system <i.e., token authority service> is has preestablished trust with operator certificate authority <i.e., certificate authority service>);
for a certificate enrollment process, transmitting a certificate order to the certificate authority service that includes the instance ID of the NF identified in the authority token (pg. 12, line 13-pg. 14, line 9; pg. 16, lines 17-23; and pg. 20, line 19-pg. 21, line 2 – NF Instance ID from the OAM issued certificate/IAK/signature <i.e., authority token> goes into a CSR/certificate request <i.e., certificate order>. The CSR/certificate request <i.e., certificate order> is transmitted to the certificate authority/ACME server <i.e., certificate authority service>).
While Bommisetty further teaches issuing a certificate upon validation of the NF Instance ID (see, e.g., pg. 20, line 19-pg. 21, line 12; pg. 22, lines 5-30), Bommisetty appears to fail to specifically disclose obtaining a response from the certificate authority service that includes an authorization internet address for the certificate authority service; transmitting a challenge query to the certificate authority service via the authorization internet address; obtaining a challenge response from the certificate authority service indicating an authority token challenge type for validating the authority token of the NF and including a challenge internet address; transmitting the authority token obtained from the token authority service to the certificate authority service via the challenge internet address; and upon validation of the authority token by the certificate authority service, obtaining, from the certificate authority service, a signed certificate or a certificate internet address from which the NF is to obtain the signed certificate for the certificate enrollment process.
However, RFC 9448 teaches a similar system for processing a certificate order with an ID (see, e.g., § 3-4), comprising obtaining a response from the certificate authority service that includes an authorization internet address for the certificate authority service (§ 3-4 – an ACME “new-order” is received. The ACME server creates an authorization object, and then adds an authorization object URL <i.e., authorization internet address> the ACME order response <i.e., response from the certificate authority service>);
transmitting a challenge query to the certificate authority service via the authorization internet address (§ 3-4 – upon receiving the response, the ACME client sends a POST request/query <i.e., challenge query> using the authorization object URL <i.e., authorization internet address);
obtaining a challenge response from the certificate authority service indicating an authority token challenge type for validating the authority token of the |ACME Client| and including a challenge internet address (§ 3-4 – the ACME server receives a POST request/query <i.e., challenge query>. A ”tkauth-01” with “tkauth-type:atc” <i.e., authority token challenge type> and a challenge URL <i.e., challenge internet address> go into the challenge response from the ACME server <i.e., certificate authority service> and is provided to the ACME client <i.e., obtaining challenge response>);
transmitting the authority token obtained from the token authority service to the certificate authority service via the challenge internet address (§ 3-4 – the ACME client response to the challenge by posting/transmitting the Authority Token to the challenge URL <i.e., challenge internet address>); and
upon validation of the authority token by the certificate authority service, obtaining, from the certificate authority service, a signed certificate or a certificate internet address from which the |ACME Client| is to obtain the signed certificate for the certificate enrollment process (§ 3-4 – the certificate authority validates the Authority Token by validating the atc claim/trusted issuer certificate/token signature/tkvalue/fingerprint. If successfully validated, the valid ACME order response includes a signed certificate URL/x5u URL <i.e., certificate internet address> where the ACME client can retrieve the signed certificate).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bommisetty with the teachings of RFC 9448, comprising obtaining a response from the certificate authority service that includes an authorization internet address for the certificate authority service; transmitting a challenge query to the certificate authority service via the authorization internet address; obtaining a challenge response from the certificate authority service indicating an authority token challenge type for validating the authority token of the NF and including a challenge internet address; transmitting the authority token obtained from the token authority service to the certificate authority service via the challenge internet address; and upon validation of the authority token by the certificate authority service, obtaining, from the certificate authority service, a signed certificate or a certificate internet address from which the NF is to obtain the signed certificate for the certificate enrollment process, to provide a standardized automated proof of authority over the requested NF Instance ID (see, e.g., Bommisetty at pg. 20, line 19-pg. 21, line 12 and pg. 22, lines 5-30; with RFC 9448 at § 3-4).
Regarding claim 16, the combination of Bommisetty and RFC 9448 teach The apparatus of claim 15, wherein communications between the NF and the token authority service and between the NF and the certificate authority service include Automated Certificate Management Environment (ACME) protocol communications (Bommisetty at pg. 14, lines 23-34; pg. 15 line 31-pg. 16 line 7, and pg. 16, line 17-pg. 17, line 26 – ACME client of the NF communicates using the ACME protocol with the certificate authority <i.e., certificate authority service>; with RFC 9448 at § 1, 4, 5.5 – the ACME client <i.e., NF as modified> communicates with the Token Authority <i.e., token authority service> to obtain the Authority Token as part of an ACME Authority Token/RFC framework <i.e., protocol communications>). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bommisetty with the teachings of RFC 9448, wherein the communications between the NF and the token authority service and between the NF and the certificate authority service include Automated Certificate Management Environment (ACME) protocol communications, to provide a standardized automated proof of authority over the requested NF Instance ID (see, e.g., Bommisetty at pg. 20, line 19-pg. 21, line 12 and pg. 22, lines 5-30; with RFC 9448 at § 3-4).
Regarding claim 19, the combination of Bommisetty and RFC 9448 teach the apparatus of claim 15, wherein:
the certificate order is included in a first Hypertext Transfer Protocol (HTTP) POST request communicated to the certificate authority service (RFC 9448 at §3 – identifier-containing ACME new-order request <i.e., certificate order> goes into HTTP POST/acme/new-order <i.e., first HTTP POST request> sent to the certificate authority);
the challenge query is included in a second HTTP POST request communicated to the certificate authority service (RFC 9448 at §4 – authorization object query <i.e., challenge query> goes into HTTP POST/acme/authz/1234 <i.e., second HTTP POST request> communicated to the certificate authority service); and
the authority token is included in a third HTTP POST request communicated to the certificate authority service (RFC 9448 at §4 – Authority token/tkauth value goes into POST/acme/chall <i.e., third HTTP POST request> communicated to the certificate authority). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bommisetty with the teachings of RFC 9448, wherein: the certificate order is included in a first Hypertext Transfer Protocol (HTTP) POST request communicated to the certificate authority service; the challenge query is included in a second HTTP POST request communicated to the certificate authority service; and the authority token is included in a third HTTP POST request communicated to the certificate authority service, to provide a standardized automated proof of authority over the requested NF Instance ID (see, e.g., Bommisetty at pg. 20, line 19-pg. 21, line 12 and pg. 22, lines 5-30; with RFC 9448 at § 3-4).
Regarding claim 20, the combination of Bommisetty and RFC 9448 teach the apparatus of claim 15, wherein the mobile core network is a Third Generation Partnership Project (3GPP) Fifth Generation (5G) mobile core network or next Generation (nG) mobile core network (Bommisetty at pg. 7, lines 25-31; and pg. 11, line 3-pg. 13, line 5 – mobile core network may be a 3GPP 5G mobile core network).
Claim(s) 3-4, 12-13, and 17-18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bommisetty in view of RFC 9448, further in view of Rajput et al. (US20220361085; Hereinafter “Rajput”).
Regarding claim 3, the combination of Bommisetty and RFC 9448 teach the method of claim 2, wherein the instance ID of the NF is an ACME identifier type that is formatted as a Universally Unique Identifier (UUID) [[version 4]] string and wherein the instance ID is assigned to the NF by the token authority service (Bomisetty at pg. 9 line 22-pg. 10, line 5; pg. 20, line 19-pg. 21, line 2; and pg. 16, lines 17-23 – the format of the NF Instance ID may be a UUID. The NF Instant ID is part of the certificate request; with RFC 9448 at § 3-4 – a resource identifier <i.e., the identifier received to be proven> is implemented as an ACME identifier object type <i.e., ACME identity type> in the certificate order).
Yet, the combination of Bommisetty and RFC 9448 appears to fail to specify the UUID may be a UUID version 4.
However, Rajput teaches a system for producing an Instance ID of an NF that is formatted as a UUID (see, e.g., [0090-092]), wherein the UUID may be a UUID version 4 ([0090-092]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the combination of Bommisetty and RFC 9448, wherein the UUID is a UUID version 4, to provide globally unique identifiers without requiring centralized coordination or embedding hardware/time-derived information and comply with standard protocol (see, e.g., Rajput at [0090-092]).
Regarding claim 4, the combination of Bommisetty, RFC 9448, and Rajput teach the method of claim 3, wherein the instance ID of the NF is one of a plurality of NF profile parameters included in the authority token that are signed by the token authority service (Bommisetty at pg. 13, line 6-pg. 14, line 9; and pg. 20, line 19-pg. 21, lime 2 – NF Instance ID is one of NF Instance ID, slice information, FQDN, IP address, NF slice list, and/or other NF profile parameters <i.e., a plurality of NF profile parameters>. The OAM response/issued signature of the NF profile parameters <i.e., authority token> is signed by the OAM system <i.e., token authority service>).
Regarding claim 12, the combination of Bommisetty, RFC 9448, and Rajput teach the media of claim 11, wherein the instance ID of the NF is an ACME identifier type that is formatted as a Universally Unique Identifier (UUID) [[version 4]] string and wherein the instance ID is assigned to the NF by the token authority service (Bomisetty at pg. 9 line 22-pg. 10, line 5; pg. 20, line 19-pg. 21, line 2; and pg. 16, lines 17-23 – the format of the NF Instance ID may be a UUID. The NF Instant ID is part of the certificate request; with RFC 9448 at § 3-4 – a resource identifier <i.e., the identifier received to be proven> is implemented as an ACME identifier object type <i.e., ACME identity type> in the certificate order).
Yet, the combination of Bommisetty and RFC 9448 appears to fail to specify the UUID may be a UUID version 4.
However, Rajput teaches a system for producing an Instance ID of an NF that is formatted as a UUID (see, e.g., [0090-092]), wherein the UUID may be a UUID version 4 ([0090-092]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the combination of Bommisetty and RFC 9448, wherein the UUID is a UUID version 4, to provide globally unique identifiers without requiring centralized coordination or embedding hardware/time-derived information and comply with standard protocol (see, e.g., Rajput at [0090-092]).
Regarding claim 13, the combination of Bommisetty, RFC 9448, and Rajput teach the media of claim 12, wherein the instance ID of the NF is one of a plurality of NF profile parameters included in the authority token that are signed by the token authority service (Bommisetty at pg. 13, line 6-pg. 14, line 9; and pg. 20, line 19-pg. 21, lime 2 – NF Instance ID is one of NF Instance ID, slice information, FQDN, IP address, NF slice list, and/or other NF profile parameters <i.e., a plurality of NF profile parameters>. The OAM response/issued signature of the NF profile parameters <i.e., authority token> is signed by the OAM system <i.e., token authority service>).
Regarding claim 17, the combination of Bommisetty, RFC 9448, and Rajput teach the apparatus of claim 16, wherein the instance ID of the NF is an ACME identifier type that is formatted as a Universally Unique Identifier (UUID) version 4 string and wherein the instance ID is assigned to the NF by the token authority service (Bomisetty at pg. 9 line 22-pg. 10, line 5; pg. 20, line 19-pg. 21, line 2; and pg. 16, lines 17-23 – the format of the NF Instance ID may be a UUID. The NF Instant ID is part of the certificate request; with RFC 9448 at § 3-4 – a resource identifier <i.e., the identifier received to be proven> is implemented as an ACME identifier object type <i.e., ACME identity type> in the certificate order).
Yet, the combination of Bommisetty and RFC 9448 appears to fail to specify the UUID may be a UUID version 4.
However, Rajput teaches a system for producing an Instance ID of an NF that is formatted as a UUID (see, e.g., [0090-092]), wherein the UUID may be a UUID version 4 ([0090-092]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the combination of Bommisetty and RFC 9448, wherein the UUID is a UUID version 4, to provide globally unique identifiers without requiring centralized coordination or embedding hardware/time-derived information and comply with standard protocol (see, e.g., Rajput at [0090-092]).
Regarding claim 18, the combination of Bommisetty, RFC 9448, and Rajput teach the apparatus of claim 17, wherein the instance ID of the NF is one of a plurality of NF profile parameters included in the authority token that are signed by the token authority service (Bommisetty at pg. 13, line 6-pg. 14, line 9; and pg. 20, line 19-pg. 21, lime 2 – NF Instance ID is one of NF Instance ID, slice information, FQDN, IP address, NF slice list, and/or other NF profile parameters <i.e., a plurality of NF profile parameters>. The OAM response/issued signature of the NF profile parameters <i.e., authority token> is signed by the OAM system <i.e., token authority service>).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Choyi et al. (US20210314171) teaches an NF in 5G network obtaining trust credentials and a certificate, as well as obtaining a PKI certificate to assure its identity (see, e.g., Choyi at abstract, [0013-016]). Sun et al. (US20250070988) teaches an OAM generating and signing information that includes an NF instance ID, NF type, and a certificate, providing it to an NF, and the NF using it to acquire a certificate from a certificate authority (see, Sun at e.g., abstract, [0006-008]).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOSHUA RAYMOND WHITE whose telephone number is (571)272-4365. The examiner can normally be reached Monday-Thursday, & Alternate Fridays.
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, Taghi Arani can be reached at 5712723787. 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.
/J.R.W./Examiner, Art Unit 2438 /TAGHI T ARANI/Supervisory Patent Examiner, Art Unit 2438
Prosecution Insights