CTFR 18/483,234 CTFR 90576 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/19/2026. Claims 1, 3, 5, 12-13, and 15 are amended. Claims 2, 11 and 14 are cancelled. Claims 1, 3-10, 12-13, and 15-18 are pending in this examination. 07-06 AIA 15-10-15 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/483,234. Specification 06-16 AIA Applicant is reminded of the proper language and format for an abstract of the disclosure. The abstract should be in narrative form and generally limited to a single paragraph on a separate sheet within the range of 50 to 150 words in length. The abstract should describe the disclosure sufficiently to assist readers in deciding whether there is a need for consulting the full patent text for details. The language should be clear and concise and should not repeat information given in the title. It should avoid using phrases which can be implied, such as, “The disclosure concerns,” “The disclosure defined by this invention,” “The disclosure describes,” etc. In addition, the form and legal phraseology often used in patent claims, such as “means” and “said,” should be avoided. Response to Arguments 07-37 AIA Applicant's arguments filed 03/19/2026 have been fully considered but they are not persuasive : Applicant submits on pages 7-11 of remarks filed on 02/22/2021 regarding claim 1 that Cruz does not disclose “ the request message is an enrollment request message , and the response enrollment message ” , and “ the instance identity of the requesting network function is a fully qualified domain name, instance identity or any other parameter of a network function profile identifying the network function. ” Examiner respectfully disagrees with applicant argument for claim 1 filed on 03/19/2026 on pages 10-12 of remarks. Cruz discloses the request message is an enrollment request message , and the response enrollment message [¶11, According to a first aspect, an apparatus configured to provide a network repository function, NRF, in a core network domain of a mobile communication network is provided, wherein the NRF is configured to register network function, NF( equated to enrollment request) , profiles for NF discovery, and wherein NF certificates have been issued to the NFs( equated to response to enrollment request) , each NF certificate including a public key of the respective NF and at least one signature of at least one certification authority, CA. The apparatus is configured to receive from a registering NF having an NF certificate, profile information comprising an NF identity of the registering NF, an NF type of the registering NF, and at least one CA certificate of at least one CA that signed the NF certificate issued to the registering NF. The apparatus is further configured to store the received profile information in a repository], and [¶13, In one variant, the NF certificate issued to the registering NF further includes an NF identifier that is different from the NF identity of the registering NF . In this variant, the received profile information may further comprise the NF identifier. As an example, the NF profiles of some or all NFs may each be extended by a further attribute that contains the NF identifier of the NF associated with the corresponding NF profile], and [¶15, As an example, the NF identifier may be the particular identifier that is included in a subject field of the NF certificate. In some cases, the NF identifier may take the form of one of a fully qualified domain name, FQDN, and a secure production identity framework for everyone, SPIFFE, identifier. ], and [ see Figs 2A- 2B, 3A-3B, [¶¶55-59, The processor 202 is adapted to receive, for example via the input interface 206 and from a registering NF having an NF certificate, profile information comprising an NF identity of the registering NF, an NF type of the registering NF, and at least one CA certificate of at least one CA that signed the NF certificate issued to the registering NF. The processor 202 is further configured to store the received profile information in the data repository 106 A as illustrated in FIG. 1. FIG. 2B shows an embodiment in which the NRF 106 is implemented in a modular configuration. As shown in FIG. 2B, the NRF 106 comprises a receiving module 210 configured to receive, from a registering NF, profile information comprising an NF identity of the registering NF, an NF type of the registering NF, and at least one CA certificate of at least one CA that signed the NF certificate issued to the registering NF. The NRF 106 further comprises a storing module 212 configured to store the received profile information in the data repository. FIGS. 3A and 3B illustrate two embodiments of an NF 107 of FIG. 1 that is configured to register its NF profile at the NRF 106 . In the embodiment illustrated in FIG. 3A, the NF 107 comprises a processor 302 and a memory 304 coupled to the processor 302 . The NF 107 further comprises an optional input interface 306 and an optional output interface 308 . The memory 304 stores program code that controls operation of the processor 302 . The memory 304 , or a different storage, may also store the CA certificate-related information for the NF 107 itself or as obtained from other NFs 107 . The processor 302 of the NF 107 is adapted to obtain, for example via the input interface 306 , at least one CA certificate of at least one CA that signed an NF certificate issued to the NF 107 . The processor 302 is further adapted to send, for example via the output interface 308 , profile information to the NRF 106 that is configured to register NF profiles for NF discovery in the core network domain 102 . The profile information that is sent comprises an NF identity of the registering NF 107 , an NF type of the registering NF 107 , and the at least one CA certificate. FIG. 3B shows an embodiment in which the NF 107 is implemented in a modular configuration. As shown in FIG. 3B, the NF 107 comprises an obtaining module 310 configured to obtain the at least one CA certificate of the at least one CA that signed the NF certificate issued to the NF 107 . The NF 107 further comprises a sending module 312 configured to send profile information to the NRF 106 that is configured to register NF profiles for NF discovery in the core network domain 102 . The profile information comprises the NF identity of the registering NF 107 , the NF type of the registering NF 107 , and the at least one CA certificate], and [ see FIG.4, [¶¶61-63, The method illustrated in flow diagram 400 comprises a step 402 of obtaining, by the registering NF 107 , the at least one CA certificate of the at least one CA that signed the NF certificate issued to the registering NF 107 . The at least one CA certificate has been obtained by the registering NF 107 as part of NF configuration. Although this configuration is vendor-specific, typically general-purpose Configuration Management (CM) interfaces such as NETCONF are used for this purpose. In step 404 , the registering NF 107 sends profile information to the NRF 106 so that its NF profile can be registered there for NF discovery in the core network domain 102 . The profile information comprises (at least) the NF identity of the registering NF 107 , the NF type of the registering NF 107 , and the at least one CA certificate obtained in step 402 . Turning now to the flow diagram 410 , the NRF 106 receives in step 406 , from the registering NF 107 , the profile information sent in step 404 . As explained above, the profile information comprises (at least) the NF identity of the registering NF 107 , the NF type of the registering NF 107 , and the at least one CA certificate of the at least one CA that signed the NF certificate issued to the registering NF 107 . Then, in step 408 , the NRF 106 stores the received profile information in its data repository 106 A], and [¶20]. Cruz discloses the instance identity of the requesting network function is a fully qualified domain name, instance identity or any other parameter of a network function profile identifying the network function [¶13, In one variant, the NF certificate issued to the registering NF further includes an NF identifier that is different from the NF identity of the registering NF. In this variant, the received profile information may further comprise the NF identifier. As an example, the NF profiles of some or all NFs may each be extended by a further attribute that contains the NF identifier of the NF associated with the corresponding NF profile], and [¶15, As an example, the NF identifier may be the particular identifier that is included in a subject field of the NF certificate. In some cases, the NF identifier may take the form of one of a fully qualified domain name, FQDN, and a secure production identity framework for everyone, SPIFFE, identifier.], and [¶17, The apparatus may be configured to receive a discovery request indicating at least an NF type . In such an implementation, the apparatus may further be configured to access the repository to identify one or more NF profiles matching at least the indicated NF type and to send a discovery response including discovery information from the one or more matching NF profiles], and [¶52, Each of the NFs 107 is associated with an NF profile. The NF profile of a particular NF defines a plurality of NF attributes, such as a unique identity of the particular NF 107 as well as its type (that will be indicative of e.g., by the type of service provided by that NF).], and [ see claim 6] . Claim Rejections - 35 USC § 112 07-30-02 AIA 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. 07-34-01 AIA Claim s 1, 3-10, 12-13, and 15-18 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. The independent claims recite “ store one or more key information elements, wherein each key information element comprises a stored key identifier and a stored key, or a certificate…. the request message is an enrolment request message… the second field is protected with the key or the certificate….” Which render the claim indefinite because , in the first scenario, if the stored key identifier and a stored key option was chosen, and enrollment request message is for certificate per specification, then what is the purpose of NF enrolling to get a certificate since the second field also can be protected with a key and later can be decrypted with the key? In the second scenario, If the certificate is chosen that is stored in the memory of apparatus and the network function is enrolling to get a certificate , then how the certificate is used to protect the second field? Since the NF is in the process to get a certificate! Furthermore, the key identifier and a stored key, or a certificate stored in the apparatus, are these key or certificate apparatus own key or certificate or are they network function key and certificate that the apparatus storing them to provide to network function with their enrollment request? Furthermore, “ and the first field comprises an instance identity of the requesting network function and the second field comprises the instance identity of the requesting network function” and furthermore “ the first field is a subject alt name field or a reference number field , the instance identity of the requesting network function is a fully qualified domain name, instance identity or any other parameter of a network function profile identifying the network function”. Does this mean that the first field comprises more information than second field? For the first field be a fully qualified domain name, the fully qualified domain name will include the reference number and instant identity. Claims 3-10, 12; 13; 16-17 do not cure the deficiency of claims 1, 13, and 15 and are rejected under 35 USC 112, 2 nd paragraph, for their dependency upon claims 1, 13, and 15. The claim 15 recites” transmit a request message comprising a first field and a second field…the first field comprises an instance identity of the requesting network function and the second field comprises the instance identity of the requesting network function, the first field is a subject alt name field or a reference number field, the instance identity of the requesting network function is a fully qualified domain name, instance identity or any other parameter of a network function profile identifying the network function, and the first field is unprotected and the second field is protected with a key or a certificate; and receive, in response to transmitting the request message, a response when the second field has been validated using the key or the certificate” which renders the claim limitations indefinite because the claimed limitations do not indicate the purpose of the first field , since the enrollment response is based on the validation of the second field and the first field has no involvement in the enrollment request and response. Claims 16-17 do not cure the deficiency of claim 15 and are rejected under 35 USC 112, 2 nd paragraph, for their dependency upon claim 15. Examiner maps the limitations under broadest reasonable interpretation. Claim Rejections - 35 USC § 102 07-07-aia AIA 07-07 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 – 07-12-aia AIA (a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention. 07-06 AIA 15-10-15 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. 07-15-03-aia AIA Claim s 1, 3-10, 12-13, and 15-18 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Martinez De La Cruz et al., (US 2022/0264301 A1) hereinafter referred to as “Cruz” . Regarding claim 1, Cruz discloses an apparatus comprising at least one processing core, at least one memory including computer program code, wherein the at least one memory and the computer program code are configured to, with the at least one processing core, cause the apparatus at least to [ see FIGs.1-3 and corresponding text for more details]; and store one or more key information elements, wherein each key information element comprises a stored key identifier and a stored key, or a certificate. wherein the request message is an enrolment request message, the first field is unprotected with the key or the certificate, and the second field is protected with the key or the certificate [¶11, According to a first aspect, an apparatus configured to provide a network repository function, NRF, in a core network domain of a mobile communication network is provided, wherein the NRF is configured to register network function, NF( equated to enrollment request) , profiles for NF discovery, and wherein NF certificates have been issued to the NFs( equated to response to enrollment request) , each NF certificate including a public key of the respective NF and at least one signature of at least one certification authority, CA. The apparatus is configured to receive from a registering NF having an NF certificate, profile information comprising an NF identity of the registering NF, an NF type of the registering NF, and at least one CA certificate of at least one CA that signed the NF certificate issued to the registering NF. The apparatus is further configured to store the received profile information in a repository], and [¶13, In one variant, the NF certificate issued to the registering NF further includes an NF identifier that is different from the NF identity of the registering NF . In this variant, the received profile information may further comprise the NF identifier. As an example, the NF profiles of some or all NFs may each be extended by a further attribute that contains the NF identifier of the NF associated with the corresponding NF profile], and [¶15, As an example, the NF identifier may be the particular identifier that is included in a subject field of the NF certificate. In some cases, the NF identifier may take the form of one of a fully qualified domain name, FQDN, and a secure production identity framework for everyone, SPIFFE, identifier. ], and [ see Figs 2A- 2B, 3A-3B, [¶¶55-59, The processor 202 is adapted to receive, for example via the input interface 206 and from a registering NF having an NF certificate, profile information comprising an NF identity of the registering NF, an NF type of the registering NF, and at least one CA certificate of at least one CA that signed the NF certificate issued to the registering NF. The processor 202 is further configured to store the received profile information in the data repository 106 A as illustrated in FIG. 1. FIG. 2B shows an embodiment in which the NRF 106 is implemented in a modular configuration. As shown in FIG. 2B, the NRF 106 comprises a receiving module 210 configured to receive, from a registering NF, profile information comprising an NF identity of the registering NF, an NF type of the registering NF, and at least one CA certificate of at least one CA that signed the NF certificate issued to the registering NF. The NRF 106 further comprises a storing module 212 configured to store the received profile information in the data repository. FIGS. 3A and 3B illustrate two embodiments of an NF 107 of FIG. 1 that is configured to register its NF profile at the NRF 106 . In the embodiment illustrated in FIG. 3A, the NF 107 comprises a processor 302 and a memory 304 coupled to the processor 302 . The NF 107 further comprises an optional input interface 306 and an optional output interface 308 . The memory 304 stores program code that controls operation of the processor 302 . The memory 304 , or a different storage, may also store the CA certificate-related information for the NF 107 itself or as obtained from other NFs 107 . The processor 302 of the NF 107 is adapted to obtain, for example via the input interface 306 , at least one CA certificate of at least one CA that signed an NF certificate issued to the NF 107 . The processor 302 is further adapted to send, for example via the output interface 308 , profile information to the NRF 106 that is configured to register NF profiles for NF discovery in the core network domain 102 . The profile information that is sent comprises an NF identity of the registering NF 107 , an NF type of the registering NF 107 , and the at least one CA certificate. FIG. 3B shows an embodiment in which the NF 107 is implemented in a modular configuration. As shown in FIG. 3B, the NF 107 comprises an obtaining module 310 configured to obtain the at least one CA certificate of the at least one CA that signed the NF certificate issued to the NF 107 . The NF 107 further comprises a sending module 312 configured to send profile information to the NRF 106 that is configured to register NF profiles for NF discovery in the core network domain 102 . The profile information comprises the NF identity of the registering NF 107 , the NF type of the registering NF 107 , and the at least one CA certificate], and [ see FIG.4, [¶¶61-63, The method illustrated in flow diagram 400 comprises a step 402 of obtaining, by the registering NF 107 , the at least one CA certificate of the at least one CA that signed the NF certificate issued to the registering NF 107 . The at least one CA certificate has been obtained by the registering NF 107 as part of NF configuration. Although this configuration is vendor-specific, typically general-purpose Configuration Management (CM) interfaces such as NETCONF are used for this purpose. In step 404 , the registering NF 107 sends profile information to the NRF 106 so that its NF profile can be registered there for NF discovery in the core network domain 102 . The profile information comprises (at least) the NF identity of the registering NF 107 , the NF type of the registering NF 107 , and the at least one CA certificate obtained in step 402 . Turning now to the flow diagram 410 , the NRF 106 receives in step 406 , from the registering NF 107 , the profile information sent in step 404 . As explained above, the profile information comprises (at least) the NF identity of the registering NF 107 , the NF type of the registering NF 107 , and the at least one CA certificate of the at least one CA that signed the NF certificate issued to the registering NF 107 . Then, in step 408 , the NRF 106 stores the received profile information in its data repository 106 A], and [¶20]; and receive, from a requesting network function, a request message comprising a first field and a second field, the first field comprises an instance identity of the requesting network function and the second field comprises the instance identity of the requesting network function, the first field is a subject alt name field or a reference number field, the instance identity of the requesting network function is a fully qualified domain name, instance identity or any other parameter of a network function profile identifying the network function [¶13, In one variant, the NF certificate issued to the registering NF further includes an NF identifier that is different from the NF identity of the registering NF. In this variant, the received profile information may further comprise the NF identifier. As an example, the NF profiles of some or all NFs may each be extended by a further attribute that contains the NF identifier of the NF associated with the corresponding NF profile], and [¶15, As an example, the NF identifier may be the particular identifier that is included in a subject field of the NF certificate. In some cases, the NF identifier may take the form of one of a fully qualified domain name, FQDN, and a secure production identity framework for everyone, SPIFFE, identifier.], and [¶17, The apparatus may be configured to receive a discovery request indicating at least an NF type . In such an implementation, the apparatus may further be configured to access the repository to identify one or more NF profiles matching at least the indicated NF type and to send a discovery response including discovery information from the one or more matching NF profiles], and [¶52, Each of the NFs 107 is associated with an NF profile. The NF profile of a particular NF defines a plurality of NF attributes, such as a unique identity of the particular NF 107 as well as its type (that will be indicative of e.g., by the type of service provided by that NF).], and [ see claim 6].t will be indicative of e.g., by the type of service provided by that NF).], and [ see claim 6]; and validate the second field using the key or the certificate; validate the request message when the instance identity of the requesting network function in the first field matches with the instance identity of the requesting network function in the validated second field; and transmit, after a successful validation of the second field and the request message, a response to the requesting network function, wherein the response is an enrollment response [¶¶6-7, A party receiving an X.509 certificate must validate it. The validation implies traversing the certificate chain and validating all the certificate signatures. When all signatures are valid, the certificate is considered to be valid. When a certificate of a service consumer NF is successfully validated by a service producer NF, the service producer NF authenticates the service consumer NF. Then, the service producer NF needs to authorize the service consumer NF, i.e., check that the service consumer NF is entitled to consume services offered by the service producer NF], and [¶12, As an example, the NF profiles of some or all NFs may each be extended by an attribute that contains one or more or all CA certificates that are required to validate the certificate of the NF associated with the corresponding NF profile. The validation may in particular occur during a mutual handshake procedure between a service consumer NF and a service producer NF. The handshake procedure may conform to the TLS protocol], and [¶17, The apparatus may be configured to receive a discovery request indicating at least an NF type. In such an implementation, the apparatus may further be configured to access the repository to identify one or more NF profiles matching at least the indicated NF type and to send a discovery response including discovery information from the one or more matching NF profiles. The discovery information includes in some cases at least the one or more CA certificates stored for the respective NF profile], and [¶¶24-25, In particular, the apparatus may be further configured to receive, from another NF for which discovery information has previously been received from the NRF, the NF certificate issued for that other NF, to read the at least one CA certificate included in the discovery information from the storage, and to validate the NF certificate using the CA certificate read from the storage. The NF certificate may be received in the context of a handshake procedure with the other NF (e.g., conforming to TLS). The apparatus of the second aspect may be configured to extract a first NF identifier from the received NF certificate, to extract a second NF identifier from the profile information, and to validate the first NF identifier based on the second NF identifier. As an example, it may be validated that the first NF identifier and the second NF identifier are identical.], and [¶81, and see FIG 5C, ¶¶ 99-110]. Regarding claim 3, Cruz discloses wherein the second field comprises a protected message, said protected message further comprising a subject alt name field and a reference number field identifying the ke y or the certificate used for protecting the second field [¶¶11, 13, 20, 55-59, see FIG.4, ¶¶61-63]. Regarding claim 4, wherein the determining the key used for protecting the second field further comprises causing the apparatus at least to: compare the reference number field to the key identifier comprised in each of at least one of the one or more key information elements; and determine the key used for protecting the second field as the stored key comprised in the key information element, based on the comparison further comprising a determination that the reference number field equals the stored key identifier comprised in the key information element. This claim is not mapped since it depends on claim 3, since the claim has a OR option between a key and a certificate and examiner has chosen the certificate option in claim 3. Regarding claim 5, Cruz discloses, wherein the second field comprises the certificate, the certificate being is an initial certificate issued by the apparatus for the instance identity of the requesting network function [¶¶11, 13, 20, 55-59, see FIG.4, ¶¶61-63]. Regarding claim 6, Cruz discloses wherein the at least one memory and the computer program code are further configured to, with the at least one processing core, cause the apparatus at least to: ignore the first field; and transmit the response to the requesting network function according to the instance identity of the requesting network function in the second field [¶¶11, 13, 20, 55-59, see FIG.4, ¶¶61-63]. Regarding claim 7, wherein the key is a pre-shared key between the requesting network function and an operator, and the at least one memory and the computer program code are further configured to, with the at least one processing core, cause the apparatus at least to: receive the key from the operator. This claim is not mapped since it depends on claim 1, since the claim 1 has a OR option between a key and a certificate and examiner has chosen the certificate option in claim 3. Regarding claim 8, Cruz discloses wherein the certificate is an initial certificate issued by the apparatus, and the at least one memory and the computer program code are further configured to, with the at least one processing core, cause the apparatus at least to: retrieve the certificate from the memory of the apparatus after receiving the certificate request [¶¶11, 13, 20, 55-59, see FIG.4, ¶¶61-63]. Regarding claim 9, The apparatus according to claim 1, wherein the request message further comprises a third field comprising an expected hash value, and the validating the second field further comprises causing the apparatus at least to: obtain a decrypted second field by decrypting the second field with the key; calculate a hash value based on the decrypted second field; and determine that the second field is valid based on determining that the hash value equals the expected hash value . This claim is not mapped since it depends on claim 1, since the claim 1 has a OR option between a key and a certificate and examiner has chosen the certificate option in claim 1. Regarding claim 10, The apparatus according to claim 1, wherein the request message further comprises a third field comprising an expected message authentication code, and the validating the second field further comprises causing the apparatus at least to: calculate a message authentication code based on at least the second field and the key; and determine that the second field is valid based on determining that the message authentication code equals the expected message authentication code . This claim is not mapped since it depends on claim 1, since the claim 1 has a OR option between a key and a certificate and examiner has chosen the certificate option in claim 1. Regarding claim 12, Cruz discloses wherein the an enrolment request message, is a certificate request message, and the enrolment response, is a certificate response [¶11, According to a first aspect, an apparatus configured to provide a network repository function, NRF, in a core network domain of a mobile communication network is provided, wherein the NRF is configured to register network function, NF( equated to enrollment request) , profiles for NF discovery, and wherein NF certificates have been issued to the NFs( equated to response to enrollment request) , each NF certificate including a public key of the respective NF and at least one signature of at least one certification authority, CA. The apparatus is configured to receive from a registering NF having an NF certificate, profile information comprising an NF identity of the registering NF, an NF type of the registering NF, and at least one CA certificate of at least one CA that signed the NF certificate issued to the registering NF. The apparatus is further configured to store the received profile information in a repository], and [¶¶13, 20, 55-59, see FIG.4, ¶¶61-63]. Regarding claims 13, and 15, the claims are interpreted and rejected for the same rational set forth in claim 1. Regarding claim 17, The apparatus according to claim 16, wherein the transmitting the request message further comprises causing the apparatus at least to: obtain an encrypted second field based on the second field and the key ; and replace the second field with the encrypted second field in the request message before transmitting the request message. This claim is not mapped since it depends on claim 16 and claim 16 does not mention any key in its limitation and furthermore since the claim 15 has a OR option between a key and a certificate and examiner has chosen the certificate option in claim 15. Regarding claim 18, The apparatus according to claim 17, wherein the transmitting the request message further comprises causing the apparatus at least to: calculate an expected message authentication code based on the second field and the key ; and include the expected message authentication code as a third field in the request message before transmitting the request message. This claim is not mapped since it depends on claim 16, since the claim 15 has a OR option between a key and a certificate and examiner has chosen the certificate option in claim 15 . Claim Rejections - 35 USC § 103 07-20-aia AIA 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. 07-23-aia AIA 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. 07-21-aia AIA Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over US Patent (US 2022/0264301 A1) issued to Martinez De La Cruz et al., hereinafter referred to as “Cruz”, and in view of Helfinstine (US2022/0353233) . Regarding claim 16, Cruz does not explicitly disclose, however, Helfinstine discloses wherein the transmitting the request message further comprises causing the apparatus at least to: calculate an expected hash value based on the second field; and include the expected hash value as a third field in the request message before transmitting the request message [ see FIG2, 3 and corresponding text, [¶¶ 0061-68, At 230 , the network device 104 may acknowledge the request, determine the network address, and determine a hash value for the FQDN.The network device 104 may use a hash algorithm such as SHA256, BLAKE3, SipHash, and/or the like to determine the hash value for the FQDN… [0064] At 240 , the network device may reply to the user device 102 . The reply may be, for example, a DoH HTTPS Response with DNS records for the FQDN. For example, the response may include the hash value for the FQDN, the network address, and an indication of the hash value for the FQDN. The indication of the hash value for the FQDN may be in the DNS EDNS0 Header of the reply to the user device 102 … At 310 , the user device 102 , based on receiving a reply from the network device 106 including the hash value for the FQDN, the network address, and an indication of the hash value for the FQDN (e.g., in the DNS EDNS0 Header of the reply to the user device 102 under Option Code (OPT) 17 (EDNS-Server-Tag), etc.), the user device 102 may establish as transmission control protocol (TCP) session with the service management device 106 . For example, the user device 102 and the service management device 106 may execute a handshaking communication process (e.g., a three-way handshake, etc.) … At 320 , the user device 102 and the service management device 106 may establish a TLS session, for example, based on symmetric and asymmetric cryptography with appropriate session keys (e.g., public keys, private keys, etc.) and certificate authority. The user device 102 and the service management device 106 may execute a TLS handshake. The user device 102 may include the hash value for the FQDN received from the network device 104 in a TLS Client Hello SNI field instead of a clear-text FQDN when sending a TLS/HTTPS request to the service management device 106 (e.g., a resolved domain, etc.). At 330 , the service management device 106 may determine the hash value for the FQDN from the TLS Client Hello message received from the user device 102 . The service management device 106 may use a pre-calculated and/or pre-determined list of modified versions of identifiers, such as hashed identifier values, encrypted identifiers, scrambled identifiers, and/or the like, that correspond to services hosted by the service management device 106 . The service management device 106 may determine an appropriate service for the request from the user device 102 based on the hash value for the FQDN in the Client Hello SNI field of an eSNI message. For example, the service management device 106 may determine that the hash value for the FQDN from the TLS Client Hello message received from the user device 102 corresponds to a stored and/or pre-determined hash value for an FQDN and that the stored and/or pre-determined hash value for the FQDN is associated with the service. The service may be associated with a service device (e.g., service devices 106 a , 106 b , 106 b , etc.). 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 Cruz by incorporating “hash value for the FQDN”, as taught by Helfinstine. One could have been motivated to do so in order for a desired and/or provisioned level of security and or performance. For example, a complex hashing algorithm may provide enhanced security but reduce performance due to an extended hash computation period. A simple hash may be used for high performance (e.g., a reduced computational duration, etc.) and lower security. For high performance and lower security, the network device may use a simpler hash algorithm such as CRC-32. For lower performance and higher security, the network device may use a keyed hash algorithm that uses rotating keys. Any hashing algorithm and/or technique may be used [Helfinstine, ¶63] . Conclusion 07-96 AIA The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See submitted 892 for more relevant references. Shulman (US20070294539 ) 0050] FIG. 5 shows a non-limiting and exemplary flowchart 500 describing the method for decrypting sensitive information in accordance with one embodiment of the present invention. The sensitive information is decrypted as it flows from DB server 130 to client 110 and only if the client is authorized to view the information. The method is configured to detect an encrypted field (e.g., field 400) in data traffic sent form DB server 130. In step S520, a check is performed to determine if such field was found, and if so execution continues with step S530; otherwise, execution ends. In step S530, another check takes place to determine if a client 110 to which the connection belongs to is permitted to view the sensitive information. For each client 110, a policy is defined that specifies which attributes and information type a client may view. This is opposed to related art solutions where the content to which a client is exposed is defined using external tagging. For example, a user may view only his credit card number and personal identification number (PIN), whereas a security manager may view the PINs and credit card numbers of all user registered in database 140. If step S530 results with a negative answer, execution proceeds to step S540 where the encrypted data is sent to the requesting client; otherwise, execution continues with step S550. It should be noted that if the requesting client is not allowed to view the information, then the connection between the client and the DB server may be blocked. [0051] In step S550, the detected encryption field is decrypted and verified. Specifically, if the encryption field has the same structure as field 400, then the following steps are taken: a) start sentinel cell 410 is identified; b) the value of text length cell 430 is obtained and compared to a known length of the ciphered text; c) the value of the ciphered text cell 440 is read and decrypted; d) the unencrypted text is verified against the value of the checksum; e) the SIP identifier is extracted from cell 420; and, f) the unencrypted text is decoded according to the CCT table corresponding to the SIP. At S560, the decrypted sensitive information is relayed to the client. [0026] More specifically, the encrypted string comprises an encrypted field. [0027] More specifically, the encrypted field includes a start sentinel cell, a sensitive information pattern identifier cell, a text length cell, and a ciphered text cell. [0028] More specifically, decrypting the encrypted string further comprises identifying the start sentinel cell in the encrypted stream. A value of the text length cell is obtained. The text length's value is compared to a length of a ciphered text in the ciphered text cell. The ciphered text is decrypted. (CN117997541) A certificate management related topic in a 3rd Generation Partnership Project (3 GPP) defines a Certificate Application Management Framework (CEMAF), where the CEMAF includes a Certificate Management Function (CEF), a Certificate Authority Function (CEEF), and a Network Function (NF) that needs to request a service certificate. Specifically, the communication interface between the NF and the CEEF is configured to register a program related to the certificate allocation and update; and the communication interface between the NF and the CEF is used for certificate status check. S 411: The first NF sends a service certificate request message to the CEF, or the CEF receives the service certificate request message from the first NF. Specifically, the service certificate request message is used to request to obtain the service certificate. The first NF and the CEF are network elements in the same trust domain and may be understood as that the first NF is replaced with a service certificate by using the CEF. The service certificate request message carries the first NFID, the first NF ID refers to an ID used when the first NF applies for the service certificate, and the instance ID of the first NF may be a sender identity field in the service certificate request message or any information used to identify the first NF. Optionally, the service certificate request message may further carry at least one of the following information: a public key, a private key, an initialization certificate, or a service type. The public key and the private key are generated when the first NF requests the service certificate and are carried in the service certificate request message by the first NF. For example, when the first NF requests the service certificate, the first NF generates a public key and a private key (or referred to as a public and private key pair PK SK) pair, the first NF may carry the public key and the private key corresponding to the first NF in the service certificate request message requesting the service certificate; or, for example, when the first NF requests the service certificate, the first NF generates the public key, and the first NF may carry the public key corresponding to the first NF in the service certificate request message requesting the service certificate. With reference to the first aspect, in some implementations of the first aspect, the first information includes at least one of the following information : a network element identifier list, a domain identifier, or an initialization certificate list, where the network element identifier list is used to indicate at least one network element managed by the certificate application network element, the domain identifier is used to indicate a domain where the certificate application network element is located, and the initialization certificate list is used to indicate at least one initialization certificate configured by at least one network element managed by the certificate application network element. Based on the foregoing solution, the certificate application network element may request information for assisting verification carried in the message for verifying the certificate application network element, which may improve the flexibility of the solution. With reference to the first aspect, in some implementations of the first aspect, the determining, by the certificate issuing network element, whether the certificate application network element is a trusted network element based on the first indication information includes: when the first indication information indicates that the first information passes verification, determining, by the certificate issuing network element, that the certificate application network element is a trusted network element ; Alternatively, in a case that the first indication information indicates that the first information does not pass the verification, the certificate issuing network element determines that the certificate application network element is an untrusted network element. Shani (US10356039) [Abstract, an apparatus, computer program, and method are provided for utilizing a data structure to access fully qualified domain name information. A data structure is stored including a plurality of pairs. Each pair has a first element including information associated with a fully qualified domain name, and a second element including a result of a hash function performed on the information associated with the fully qualified domain name. In use, the data structure is utilized to access the information associated with the fully qualified domain name of at least one of the pairs, based on the result of the hash function performed on the information associated with the fully qualified domain name.], and [see Claim 1]. WO 2019133434 A1 0086] In some embodiments, the security attribute of an endpoint may be included in the certificate 500. The security attribute may be embedded in any field of the certificate. For example, as part of the X.509 certificate standard, the security attribute may be included in the Subject Alternative Name (SAN) field of the certificate. As shown in the example, the security attribute may be the security group (e.g., security group with name or identifier WebGroup.dcl) that endpoint 311 belongs to and is included in the certificate as SAN extension. [0087] An endpoint may be created by obtaining a certificate issued to the endpoint. The endpoint certificate may be signed or issued by the certificate authority in response to receiving a CSR from the agent. For example, agent 313 may generate and send a CSR to the certificate authority 301 for creating endpoint 311. The CSR may comprise security attribute (e.g., security group) and other packet attributes such as IP address uniquely associated with the endpoint. The certificate authority 301 may sign the certificate and send it to the agent 313. The agent 313 may then manage and store the certificate associated with the endpoint 311 in a local database such as the endpoint database 315. The certificate associated with a workload or network flow may be identified by the packet attribute (e.g., endpoint ID, IP) as described elsewhere herein. For instance, a packet with source IP address (e.g., IP1) may be identified to be issued certificate Cerfl having security attribute SG1 in the SAN field of the certificate. THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action. 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 Application/Control Number: 18/483,234 Page 2 Art Unit: 2496 Application/Control Number: 18/483,234 Page 3 Art Unit: 2496 Application/Control Number: 18/483,234 Page 4 Art Unit: 2496 Application/Control Number: 18/483,234 Page 5 Art Unit: 2496 Application/Control Number: 18/483,234 Page 6 Art Unit: 2496 Application/Control Number: 18/483,234 Page 7 Art Unit: 2496 Application/Control Number: 18/483,234 Page 8 Art Unit: 2496 Application/Control Number: 18/483,234 Page 9 Art Unit: 2496 Application/Control Number: 18/483,234 Page 10 Art Unit: 2496 Application/Control Number: 18/483,234 Page 11 Art Unit: 2496 Application/Control Number: 18/483,234 Page 12 Art Unit: 2496 Application/Control Number: 18/483,234 Page 13 Art Unit: 2496 Application/Control Number: 18/483,234 Page 14 Art Unit: 2496 Application/Control Number: 18/483,234 Page 15 Art Unit: 2496 Application/Control Number: 18/483,234 Page 16 Art Unit: 2496 Application/Control Number: 18/483,234 Page 17 Art Unit: 2496 Application/Control Number: 18/483,234 Page 18 Art Unit: 2496 Application/Control Number: 18/483,234 Page 19 Art Unit: 2496 Application/Control Number: 18/483,234 Page 20 Art Unit: 2496 Application/Control Number: 18/483,234 Page 21 Art Unit: 2496 Application/Control Number: 18/483,234 Page 22 Art Unit: 2496 Application/Control Number: 18/483,234 Page 23 Art Unit: 2496
Prosecution Insights