DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response to Application No. 18/482,461 filed on 10/06/2023.
Claims 1-20 have been examined and are pending in this application.
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.
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.
Claim(s) 1-6, 8-16, and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Smeets et al. (US 2025/0220012; Hereinafter “Smeets”) in view of Chirala et al. (US 2024/0414144; Hereinafter “Chirala”).
Regarding claim 1, Smeets teaches a network traffic analysis system, comprising: one or more processors; and a memory having stored thereon instructions that, upon execution by the one or more processors, cause the one or more processors to:
receive, from a first network function (NF) on a 5G network, a copy of a message sent over a long-lived connection between the first NF and a second NF on the 5G network, the copy of the message including details for a transport layer security (TLS) certificate involved in the long-lived connection (Smeets: Para. [0016], The first set of operations includes receiving a first message about a NF LCM event performed by a first NF of the communication network. The first message includes an identifier of a second NF associated with the NF LCM event performed by the first NF and an event type associated with the NF LCM event. The first set of operations also includes performing a first certificate LCM event for one or more certificates associated with the second NF. The first certificate LCM event is based on the event type associated with the NF LCM event. Para. [0017], The second set of operations includes performing a second certificate LCM event for the one or more certificates associated with the second NF and sending to the first NF a second message about the second certificate LCM event. The second message includes an identifier of the second NF and an event type associated with the certificate LCM event. Para. [0012], 3GPP TS 33.501 (v17.5.0) section 13 specifies that TLS client and server certificates are used for authentication of consumer NFs (e.g., client) and producer NFs (e.g., server). Once mutually authenticated based on their respective certificates, two NFs can exchange encryption keys that facilitate secure communication between the two NFs. Para. [0083], In the arrangement shown in FIG. 4, CMNE may communicate with NRF via a service based interface (SBI) that uses HTTP/2 (over TLS) with JSON for application layer serialization. SBI lower layers include TCI, IP, and any appropriate layer 2 (L2). [HTTP/2 utilizes persistent long-lived connections]).
Smeets does not explicitly teach compare the details against a list of revoked certificates to determine whether the TLS certificate has been revoked; when the TLS certificate has been revoked, send a notification directing the first NF to close the long-lived connection.
In an analogous art, Chirala teaches compare the details against a list of revoked certificates to determine whether the TLS certificate has been revoked (Chirala: Para. [0066], In step 8, in response to the NF register request, NRF 100 sends a certificate status check request to CA 310. CA 310 responds in step 9 indicating that the certificate used by the hacker for the TLS handshake has been revoked. It should be noted that the certificate status check could be performed internally by NRF 100 if NRF 100 maintains a copy or list of certificates that have been revoked. In step 10, NRF 100 responds to hacker 400 with a TLS handshake failure, preventing hacker 400 from obtaining unauthorized access to network resources. Para. [0053]).
when the TLS certificate has been revoked, send a notification directing the first NF to close the long-lived connection (Chirala: Para. [0051], In response to successful completion of an NF deregister service operation, NRF 100 responds as indicated in step 2a with a 204 no content message. On failure of the NF deregister service operation or redirection of the NF deregister request to another NRF, NRF 100 responds as indicated in step 2b with a 4xx or 5xx message specifying problem details or a 3xx message indicating redirection.)
It would have been obvious to a person having ordinary skill in the art, before the effective filing date of the claimed invention, to combine the teachings of Chirala with the system and method of Smeets to include compare the details against a list of revoked certificates to determine whether the TLS certificate has been revoked; when the TLS certificate has been revoked, send a notification directing the first NF to close the long-lived connection because this functionality provides improved security by automatically revoking certificates utilized in SBI communication on NF deregistration thereby mitigating risks associated with deregistered NF certificates stolen without the owner’s knowledge (Chirala: Para. [0049])
Regarding claim 2, Smeets, in combination with Chirala, teaches the network traffic analysis system of claim 1, wherein the long-lived connection comprises a connection that remains open after an initial TLS handshake between the first NF and the second NF used to verify the TLS certificate, without a subsequent check of the TLS certificate (Chirala: Para. [0060], However, in step 5, a hacker who has obtained the deregistered NF's TLS certificate and keys attempts a TLS handshake with NRF 100 as part of an NF register request to NRF 100 impersonating NF 200. Because there is no check to see if the certificate or keys are revoked or stolen, the TLS handshake is successful, and NRF 100 registers hacker 400 as NF 200 in its NF profiles database.).
Regarding claim 3, Smeets, in combination with Chirala, teaches the network traffic analysis system of claim 2, wherein the long-lived connection comprises an HTTP/2 connection (Smeets: Para. [0083], In the arrangement shown in FIG. 4, CMNE may communicate with NRF via a service based interface (SBI) that uses HTTP/2 (over TLS) with JSON for application layer serialization. SBI lower layers include TCI, IP, and any appropriate layer 2 (L2). [HTTP/2 utilizes persistent long-lived connections]).
Regarding claim 4, Smeets, in combination with Chirala, teaches the network traffic analysis system of claim 2, wherein the instructions comprise further instructions that, upon execution by the one or more processors, cause the one or more processors to: access a public key infrastructure (PKI) system to obtain the list of revoked certificates (Chirala: Para. [0049], Transport layer security/public key infrastructure (TLS/PKI) provides the concept of revocation using a certificate revocation list (CRL) or online certificate status protocol (OCSP) for a certificate stolen with the owner's knowledge.).
Regarding claim 5, Smeets, in combination with Chirala, teaches the network traffic analysis system of claim 4, wherein the list of revoked certificates comprises a certificate revocation list (CRL) (Chirala: Para. [0053], 3GPP TS 33.310, Appendix F.2 recommends using an online certificate security protocol (OCSP) or certificate revocation list (CRL) to validate the status of the TLS certificate presented by a peer entity (e.g., in a TLS handshake) by fetching the certificate status from the CA. Once a TLS certificate is marked as revoked by the CA, usage of such a certificate in the authentication and authorization (e.g., in a TLS handshake) procedures will lead to failures.).
Regarding claim 6, Smeets, in combination with Chirala, teaches the network traffic analysis system of claim 4, wherein the list of revoked certificates comprises an online certificate status protocol (OCSP) (Chirala: Para, [0053], 3GPP TS 33.310, Appendix F.2 recommends using an online certificate security protocol (OCSP) or certificate revocation list (CRL) to validate the status of the TLS certificate presented by a peer entity (e.g., in a TLS handshake) by fetching the certificate status from the CA. Once a TLS certificate is marked as revoked by the CA, usage of such a certificate in the authentication and authorization (e.g., in a TLS handshake) procedures will lead to failures.).
Regarding claim 8, Smeets, in combination with Chirala, teaches the network traffic analysis system of claim 4, wherein the message includes a service-based interface (SBI) communication (Smeets: Para. [0073], Service Communication Proxy (SCP) is a 5GC NF that was introduced in Rel-16. SCP provides centralized capabilities such as service-based interface (SBI) routing, NF discovery and selection, failover, message screening, etc.).
Regarding claim 9, Smeets, in combination with Chirala, teaches the network traffic analysis system of claim 4, wherein the network traffic analysis system, the first NF, and the second NF are components of a 5GC (5G core) network (Smeets: Para. [0004], FIG. 1 illustrates a high-level view of an exemplary 5G wireless network 100, which includes a Next Generation Radio Access Network (NG-RAN, 199) and a 5G Core (5GC, 198). The NG-RAN can include one or more gNodeB's (gNBs, e.g., 100, 150) connected to the 5GC via one or more NG interfaces (e.g., 102, 152). More specifically, the gNBs can be connected to one or more Access and Mobility Management Functions (AMFs) in the 5GC via respective NG-C interfaces and to one or more User Plane Functions (UPFs) in the 5GC via respective NG-U interfaces. Various other network functions (NFs) can be included in the 5GC, as described in more detail below.).
Regarding claim 10, Smeets, in combination with Chirala, teaches the network traffic analysis system of claim 9, wherein the instructions comprise further instructions that, upon execution by the one or more processors, cause the one or more processors to: when the TLS certificate has been revoked, send a message to multiple NFs in the 5GC network indicating the TLS certificate has been revoked (Smeets: Para. [0089], Operations 5-6 can be viewed as a specific example of operations 1-2, respectively. In operation 5, when the CA revokes an NF certificate, the CA sends to CMNE a unique identifier of the NF and a type associated with the LCM event (revocation). In operation 6, based on the NRF's subscription covering the identified NF and certificate revocations (or covering all NFs and/or all certificate LCM events), the CMNE forwards the information received in operation 5 to the NRF using a notify procedure. [subscription may include multiple NF’s and/or multiple certificate LCM events]).
Regarding claim 11-16, Claims 11-16 are rejected under the same rational as claims 1-6, respectively.
Regarding claim 18-20, Claims 18-20 are rejected under the same rational as claims 8-10, respectively.
Claim(s) 7 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Smeets et al. (US 2025/0220012; Hereinafter “Smeets”) in view of Chirala et al. (US 2024/0414144; Hereinafter “Chirala”) in view of Sun et al. (US 2025/0119475; Hereinafter “Sun”).
Regarding claim 7, Smeets, in combination with Chirala, teaches the network traffic analysis system of claim 4. Smeets, in combination with Chirala, does not explicitly teach wherein the instructions comprise further instructions that, upon execution by the one or more processors, cause the one or more processors to: when the TLS certificate has not been revoked, send a notification to the first NF indicating that the TLS certificate is valid.
In an analogous art, Sun teaches wherein the instructions comprise further instructions that, upon execution by the one or more processors, cause the one or more processors to:
when the TLS certificate has not been revoked, send a notification to the first NF indicating that the TLS certificate is valid (Sun: Para. [0006], when determining that a first certificate of a first network function network element of the first type is valid, the service discovery function network element sends a service discovery response message including identification information of the first network function network element.).
It would have been obvious to a person having ordinary skill in the art, before the effective filing date of the claimed invention, to combine the teachings of Sun with the system and method of Smeets and Chirala to include wherein the instructions comprise further instructions that, upon execution by the one or more processors, cause the one or more processors to: when the TLS certificate has not been revoked, send a notification to the first NF indicating that the TLS certificate is valid because this functionality provides improved network efficiency and communication security (Sun: Para. [0003]-[0004])
Regarding claim 17, Claim 17 is rejected under the same rational as claim 7.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
U.S. Patent Application Publication No. US 2024/0163271 by Krishan.
U.S. Patent Application Publication No. US 2025/0310766 by Shang et al.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Nelson Giddins whose telephone number is (571)272-7993. The examiner can normally be reached on Monday - Friday, 9:00 AM - 5:00 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Linglan Edwards can be reached at (571) 270-5440. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/NELSON S. GIDDINS/ Primary Examiner, Art Unit 2408