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 .
Response to Arguments
Applicant’s arguments, see Remarks, filed 02/27/2026, with respect to the rejection(s) of claims 1-17 under 35 USC § 103 have been fully considered but are not persuasive. The secondary reference material, Saarinen, US 2021/0037026, reads on the amended limitation.
With regards to Applicant’s argument, on page 8 of the Remarks, ‘Shankar mentions that the firewall “may also be located within a core of the network,” but this is a generic reference to network topology placement and does not describe a telecom core network comprising network functions; …’. The Examiner respectfully disagrees with the Applicant’s argument.
The Examiner asserts that the Applicant did not explicitly claim “a telecom core network”. What is claimed is “a core network”, and Shankar sufficiently discloses the explicitly claimed “a core network” in paragraph [0022] as “the firewall may also be located within a core of the network 14 and communicate with other firewalls.”. Therefore, the Applicant’s argument is moot.
On page 9 of the Remarks, the Applicant also argues: “Saarinen discloses a telecom core network (CN 16) with network functions (NFs 20, 30); however, Saarinen does not teach security inspection.”. The Examiner respectfully disagrees with the Applicant’s argument.
Saarinen is cited to teach the deficiencies of Martini and Shankar, which is “wherein the service communication proxy is configured to mediate a communication between different network functions in the core network”, not to teach the “security inspection” aspect which is already taught by Shankar in paragraph [0041] as “The firewall 12 inspects the decrypted traffic (step 48) and if the firewall decides that the data should be forwarded to its destination …”, and cited in the most recent Non-Final Office Action. Therefore, the Examiner did not find the Applicant’s argument persuasive.
On pages 9-10 of the Remarks the Applicant argues: “None of the cited references describes a proxy that enforces mandatory routing of all inter- network-function communications through itself. The term "service communication proxy" is not used by any of the references of Martini, Shankar, and Saarinen; and none describes the architectural role of mandatorily mediating between telecom network functions.”. The Examiner respectfully disagrees with the Applicant’s argument.
First, as explained above the Applicant did not claim “telecom network functions”. What has been claimed is “network functions in the core network”.
Second, proxy 40 of Fig. 1A of Saarinen is a service communication proxy between provider (NF 30) and consumer (NF 20) as taught in paragraph [0007] as “The method includes receiving a discovery request that requests information indicating an NF service provider available to provide a service to an NF service consumer. The method may also include, in response to the discovery request, replying with information indicating a proxy of the NF service provider or a proxy of the NF service consumer and with security information based on which a connection with the indicated proxy is to be secured.”.
With regards to the Applicant’s argument on pages 10-11 of the Remarks substantially arguing that the proposed combination of Martin, Shankar and Saarinen is not proper, the Examiner re-asserts that the incorporation of Saarinen’s service-based architecture to intercept and selectively forwarding communications between network functions of a core network into the system of the combination of Martin and Shankar provides flexibility, security, and operational efficiency as taught in Saarinen in paragraphs [0004]-[0005] as: “The service-based architecture advantageously enables greater flexibility and speed in the development of new CN services, as it becomes possible to connect to other components without introducing new interfaces. The service-based architecture also introduces the possibility to use application programming interfaces (APIs) based on web technology that make development easier, as libraries and development tools for such technology are already broadly available. … protect communication between core network (CN) network functions (NFs) in a way that enables authorized network equipment (e.g., one or more edge proxies) to intercept the protected communication, e.g., to make sure the communication is not malicious, to perform load balancing, etc. This means in some embodiments that NFs in different public land mobile networks (PLMNs) or different network slices may communicate securely without jeopardizing or thwarting the security or loading of a network or slice.”. Thus, the proposed motivation the Examiner provided is proper, and the Applicant’s argument is not persuasive.
Therefore, the Examiner did not find the Applicant’s argument persuasive, and the rejection of the claims is maintained.
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.
Claims 1-3, 5-7, 10-11 and 13-17 are rejected under 35 U.S.C. 103 as being unpatentable over USPAT No. 2015/0052345 A1 to Martini, US-PGPUB No. 2017/0289104 A1 to Shankar et al. (hereinafter “Shankar”), and further in view of US-PGPUB No. 2021/0037026 A1 to Saarinen
Regarding claim 1:
Martini discloses:
A system for security inspection of Internet Protocol (IP) traffic (see the system of Fig. 1A) in a core network (see Fig. 1A, Network 100), comprising at least one service communication proxy (¶25: “… the MitM gateway 104 may act as a proxy of the server 118”, see Fig. 1A, MitM Gateway 104) which comprises at least one interface (¶48: “… the MitM gateway 104 may act as a proxy of the server 118, mimicking the interface of the server 118 in communications with the browser device 106.”) and a processor (see Fig. 5, Processor 502);
wherein the interface is configured to receive the IP traffic (¶51: “The MitM gateway 104 receives the traffic, …”);
However, Martini does not explicitly disclose the following limitation taught by Shankar:
wherein the processor is configured to decrypt at least one layer of communication of the received IP traffic (¶Shankar, ¶42: “Traffic destined for the client 10 is encrypted at the server 16 (as indicated at block 39). The data is decrypted (36) and inspected (34) at the firewall 12. If after inspection, the firewall 12 decides to forward the data, it transmits the decrypted data over the secure tunnel 18. The traffic is encrypted (re-encrypted) (53) at the client agent 32 and transmitted to the browser 30, where it is decrypted (31).”);
wherein the processor is further configured to perform a security inspection on the at least one decrypted layer in the core network (Shankar, ¶41: “The firewall 12 inspects the decrypted traffic (step 48) and if the firewall decides that the data should be forwarded to its destination (e.g., based on policies, security checks, ACLs (Access Control Lists), etc.), the firewall re-encrypts the data and forwards it to its destination (server 16) (step 49).”, ¶22-24: “… the firewall may also be located within a core of the network 14 … the firewall 12 is configured to provide Transport Layer Security (TLS) by intercepting network traffic flows between the clients 10 and server 16.”, see Fig. 5, Decrypt (36) and Inspect (34) are both performed at the Firewall (12)); and
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of Martini to incorporate the functionality of the firewall to decrypt and inspect traffic received from a server, as disclosed by Shankar, such modification would enable the system to detect hidden threats, and prevent data loss.
The combination of Martini and Shankar does not explicitly disclose the following limitation taught by Saarinen:
wherein the service communication proxy is configured to mediate a communication between different network functions in the core network (Saarinen, ¶25: the one or more proxies 40 may receive communication 50 from NF 30 over connection 30C that is secure and decrypt the received communication 50 using the security credentials based on which the connection 30C is secured, but may then re-encrypt the communication 50 using the security credentials based on which connection 30C is secured and transmit the encrypted communication 50 over connection 20C towards NF 20.”, see Fig. 1A, Core Network(CN) 16), and all communications between two network functions in the core network are routed only via the at least one service communication proxy (Saarinen, ¶25: “the one or more proxies 40 may receive communication 50 from NF 30 over connection 30C … and transmit [the] encrypted communication 50 over connection 20C towards NF 20. The same may be the case for communication 50 transmitted in the other direction from NF 20 to NF 30. In this way, the one or more proxies 40 may effectively intermediate or interwork between the connections 20C, 30C and any secured associated with them.”, see also Fig. 1ANF 20 and NF 30 communicate through proxy 40 only).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of the combination of Martini and Shankar to incorporate the service-based architecture of Saarinen, and to intercept and selectively forwarding communications between network functions of a core network by decrypting the received communication, and encrypting and transmitting the communication towards a different function Saarinen, as disclosed by Saarinen, such service-based architecture enables network functions to communicate securely without jeopardizing or thwarting the security or loading of a network.
Regarding claim 2:
The combination of Martini, Shankar and Saarinen discloses:
The system of Claim 1, wherein the processor is configured to perform a policy action on at least a part of the IP traffic based on the results of the security inspection (Martin, ¶51: “If the HTTP Get request does violate a policy, the MitM gateway 104 can modify or drop the request, as specified by the policy.”).
Regarding claim 3:
The combination of Martini, Shankar and Saarinen discloses:
The system of claim 1, wherein the security inspection comprises an intrusion detection, an intrusion prevention, a virus detection, a malware detection and/or an anomaly detection of protocols and/or communication (Martin, ¶54: “The MitM gateway 104 can compare the HTTP reply with the rules of any policies that apply to traffic into the network 100. … If the HTTP reply does violate a policy (e.g., contains malicious code, too large), …”).
Regarding claim 5:
The combination of Martini, Shankar and Saarinen discloses:
The system of Claim 1, wherein the decrypted layer is any one of the following OSI layers:
a data link layer, a network layer, a transport layer, or an application layer (Shankar, ¶see Fig. 5, the Firewall 12 decrypts (Decrypt 36) and inspects (Inspect 34) data received from server 16 at the Application Layer).
The same motivation which is applied to claim 1 with respect to Shankar applies to claim 5.
Regarding claim 6:
The combination of Martini, Shankar and Saarinen discloses:
The system of Claim 1, wherein the processor is configured to re-encrypt the decrypted IP traffic after the security inspection (Martin, ¶51: “The MitM gateway 104 receives the traffic, decrypts the traffic, inspects the traffic, encrypts the traffic into a second encrypted form,”).
Regarding claim 7:
The combination of Martini, Shankar and Saarinen discloses:
The system of Claim 6, wherein the at least one interface is configured to transmit the IP traffic after said re- encryption (Martin, ¶51: “The MitM gateway 104 receives the traffic, decrypts the traffic, inspects the traffic, encrypts the traffic into a second encrypted form, and passes the traffic to the server 118 (320).”).
Regarding claim 10:
The combination of Martini, Shankar and Saarinen discloses:
The system of Claim 1, wherein the system comprises a plurality of service communication proxies (Martin, ¶36: “… a network 200 with a network gateway 202 and a group of MitM gateways 204-210.”, see Fig. 2);
wherein the plurality of the service communication proxies are configured to share a communication load between two resources (Martin, see Fig. 2, browser devices 212 and 214) in the core network among themselves (Martin, ¶36: “… intercept and examine a request message from browser devices 212 and 214 and respond directly with the address or addresses of one or more of the MitM gateways 204-210,”).
Regarding claim 11:
The combination of Martini, Shankar and Saarinen discloses:
The system of Claim 10, wherein the plurality of the service communication proxies are configured to exchange information on their respective loads (Martin, ¶37: “… the group of MitM gateways 204-210 may be used to share or balance the load of the MitM gateways 204-210.”).
Regarding claims 13-17:
Claims 13-15 and 16-17 recite substantially the same limitations as claims 1-3 and 6-7, respectively in the form of a method to implement the corresponding functionality. Therefore, they are rejected by the same rationale.
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Martini, Shankar, Saarinen, and further in view of US-PGPUB No. 2024/0121213 A1 to Gregory
Regarding claim 4:
The combination of Martini, Shankar and Saarinen discloses the system of Claim 1, but does not explicitly disclose the following limitation taught by Southgate:
wherein the processor is configured to use an artificial intelligence, AI, algorithm to carry out the security inspection (Gregory, ¶45: “… the firewall gateway device firmware may include an AI-enabled function or engine that can be used to inspect each of the communications packets received by the firewall gateway device …”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of the combination of Martini, Shankar and Saarinen to incorporate the functionality of the digital filtering process in the firewall gateway device to conduct packet inspection on received one or more packets by using an AI enabled function or engine, as disclosed by Gregory, such modification would provide the system with improved accuracy, faster response times, and the ability to detect zero-day threats, and enable the system to analyze large amounts of data, identify malicious patterns, and adapt to new threats more effectively than traditional methods.
Claims 8-9 is rejected under 35 U.S.C. 103 as being unpatentable over Martini, Shankar, Saarinen, and further in view of US-PGPUB No. 20060059370 A1 to Asnis et al. (hereinafter “Asnis”)
Regarding claim 8:
The combination of Martini, Shankar and Saarinen discloses the system of Claim 1, but does not explicitly disclose the following limitation taught by Asnis:
wherein the processor is configured not to encrypt the decrypted IP traffic after the security inspection if the core network does not use encryption internally (Asnis, ¶03: “The particular VPN gateway peer determines if the destination of this tunneled packet is on their own selector list. And if so, decrypts the encrypted packet and forwards it to a node on its locally attached internal network.”, Note: it is implied in Asnis encryption is not used in the locally attached internal networks).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of the combination of Martini, Shankar and Saarinen to incorporate the functionality of the digital filtering process in the firewall gateway device to conduct packet inspection on received one or more packets by using an AI enabled function or engine, as disclosed by Asnis, such modification would provide the system with improved accuracy, faster response times, and the ability to detect zero-day threats, and enable the system to analyze large amounts of data, identify malicious patterns, and adapt to new threats more effectively than traditional methods.
Regarding claim 9:
The combination of Martini, Shankar, Saarinen and Asnis discloses:
The system of Claim 8, wherein the at least one interface is configured to transmit the unencrypted IP traffic after performing the security inspection (Asnis, ¶03: “… decrypts the encrypted packet and forwards it to a node on its locally attached internal network.”, Note: it is implied in Asnis encryption is not used in the locally attached internal networks).
The same motivation which is applied to claim 8 with respect to Asnis applies to claim 9.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 MATTHIAS HABTEGEORGIS whose telephone number is (571)272-1916. The examiner can normally be reached M-F 8am-5pm ET.
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, William R. Korzuch can be reached on (571)272-7589. 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.
/M.H./Examiner, Art Unit 2491
/DANIEL B POTRATZ/Primary Examiner, Art Unit 2491
Prosecution Insights