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 application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
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.
Claims 1-20 are rejected in the Instant Application.
Priority
Examiner acknowledges Applicant’s claim to priority benefits of PCT/IB23/61381 and 63/425189 filed 11/10/2023 and 11/14/2022, respectively.
Information Disclosure Statement
The information disclosure statement(s) (IDS) submitted on 12/20/2024 is/are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement(s) is/are being considered if signed and initialed by the Examiner.
Claim Rejections
Claim Rejections - 35 USC § 112
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.
Claim(s) 4, 9, 14, 20 is/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. Claim 4 is representative and includes the limitation “wherein preferably the segment is a grouping of security platforms or firewalls,” which creates confusion as to the claim scope.
The Applicant(s) are respectfully requested to correct all similar errors.
Claim Rejections - 35 USC § 103
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.
Claims 1-3, 6-8, 11-13, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Oswal (US Pat. 11,095,612) in view of Zuk (US Pub. 2021/0006539).
With respect to Claim 1, Oswal teaches a processor-implemented method, comprising: (Fig. 4a, column (c) 14, line (l) 11-35; device with processor, RAM and storage such as a hard disk)
receiving user context information at a security platform from a cloud security service, (Figs. 1a/b, c. 5, l. 62 to c. 6, l. 32; A cloud-based security service such as Prisma Access can determine metadata such as user ID, device ID, and content ID associated with each flow. The determined metadata information can then be communicated to a SD-WAN device.)
and applying a security policy at the security platform using the user context information. (c. 6, l. 23-35; SD-WAN device can use metadata information about the flow to perform security policy enforcement.)
But Oswal does not explicitly teach wherein the user context information comprises at least one of an IP-user mapping, a user-tag mapping, an IP-tag mapping, an IP-port-user mapping, and an IP-device ID mapping.
Zuk, however, does teach wherein the user context information comprises at least one of an IP-user mapping, a user-tag mapping, an IP-tag mapping, an IP-port-user mapping, and an IP-device ID mapping; (para. 60; device monitors a traffic flow and determines IP address and port number for the flow. Device then user ID for the flow based on the source IP address. Para. 17; network security policies control actions such as allow or block transmission. The policies can be based on various criteria. Para. 46; policy parameters include application, user, device, resource, source/destination, device.)
It would have been obvious to combine the method of Oswal with the context information comprising an IP-user mapping in order to allow the flow from a source IP address to be classified according to user in order to execute the user-parameter security policy.
With respect to Claim 2, modified Oswal teaches the method of claim 1, and Oswal also teaches wherein the security platform comprises a physical firewall, virtual machine firewall, or a container-based firewall. (c. 2, ln. 44 to c. 4, l. 35; firewall including physical or virtual machine firewall.)
With respect to Claim 3, modified Oswal teaches the method of claim 1, and Oswal also teaches wherein the security platform is an edge device in a SD-WAN network, wherein the edge device is configured to act as a connection and/or termination point of the SD-WAN network, (Fig. 1a, c. 9, l. 41 to c. 10, l. 9; SD-WAN edge devices reside at every site and act as the connection and termination points of the SD-WAN fabric. See also Fig. 2, c. 11, l. 5-17.)
and wherein the edge device is further configured to connect to the cloud security service via an IPsec tunnel. (Fig. 1a, c. 9, l. 58 to c. 10, l. 9; IPsec tunnels between SD-WAN edge devices and security service.)
With respect to Claim 6, it is substantially similar to Claim 1 and is rejected in the same manner, the same art and reasoning applying. Further, Oswal also teaches and a memory coupled to the processor and configured to provide the processor with instructions. (Fig. 4a, column (c) 14, line (l) 11-35; device with processor, RAM and storage such as a hard disk)
With respect to Claims 7-8, they are substantially similar to Claims 2-3, respectively, and are rejected in the same manner, the same art and reasoning applying.
With respect to Claim 11, it is substantially similar to Claim 1 and is rejected in the same manner, the same art and reasoning applying. Further, Oswal also teaches a computer program product, the computer program product being embodied in a tangible computer readable storage medium and comprising computer instructions for: (Fig. 4a, column (c) 14, line (l) 11-35; device with processor, RAM and storage such as a hard disk)
With respect to Claims 12-13, they are substantially similar to Claims 2-3, respectively, and are rejected in the same manner, the same art and reasoning applying.
With respect to Claim 18, Oswal teaches a processor-implemented method, comprising: (Fig. 4a, column (c) 14, line (l) 11-35; device with processor, RAM and storage such as a hard disk)
receiving user context information from a security platform at a cloud security service, (Figs. 1a/b, c. 5, l. 62 to c. 6, l. 32; A cloud-based security service such as Prisma Access can determine metadata such as user ID, device ID, and content ID associated with each flow. The determined metadata information can then be communicated to a SD-WAN device for policy enforcement. c. 4, l. 61 to c. 5, l. 29; SD-WAN device may determine at least some of the context information instead. c. 6, l. 46-53; SD-WAN determines app ID and communicates it to the security service to prevent repetition. It would have been obvious to one of ordinary skill to apply the same to any derived context information.)
and storing the user context information in a data store of the cloud security service (c. 9, l. 58 to c. 10, l. 9; data store of security service for network/security logging data. To the extent that this may be construed as not explicitly teaching storage of the user context information there, it would have been obvious to one of ordinary skill prior to the effective filing date to store the context information at the security service to avoid having to constantly re-discover the data, see c. 5, l. 11-17; context information is expensive in terms of CPU to determine.)
for redistribution of the user context information to another security platform. (Examiner asserts this is intended use not entitled to patentable weight, since the storage is the active verb. However, Oswal also suggests distribution of context information. c. 5, l. 30-46; System seeks to avoid inconsistent enforcement for an enterprise. Therefore, it would have been obvious to one of ordinary skill prior to the effective filing date to distribute to the other SD-WAN devices of Fig. 1a in order to provide consistent enforcement.)
But Oswal does not explicitly teach wherein the user context information comprises at least one of an IP-user mapping, a user-tag mapping, an IP-tag mapping, an IP-port-user mapping, and an IP-device ID mapping.
Zuk, however, does teach wherein the user context information comprises at least one of an IP-user mapping, a user-tag mapping, an IP-tag mapping, an IP-port-user mapping, and an IP-device ID mapping; (para. 60; device monitors a traffic flow and determines IP address and port number for the flow. Device then user ID for the flow based on the source IP address. Para. 17; network security policies control actions such as allow or block transmission. The policies can be based on various criteria. Para. 46; policy parameters include application, user, device, resource, source/destination, device.)
It would have been obvious to combine the method of Oswal with the context information comprising an IP-user mapping in order to allow the flow from a source IP address to be classified according to user in order to execute the user-parameter security policy.
Claims 4-5, 9-10, 14-15, and 19-20 are rejected under 35 U.S.C. 103(a) as being unpatentable over Oswal (US Pat. 11,095,612) in view of Zuk (US Pub. 2021/0006539), and further in view of Ansari (US Pub. 2010/0202450).
With respect to Claim 4, modified Oswal teaches the method of claim 1, but does not explicitly teach subscribing.
Ansari, however, does teach wherein the security platform subscribes to a segment for centralized identity redistribution, wherein preferably the segment is a grouping of security platforms or firewalls. (para. 17; gateway may have firewall functionality. Para. 117, 165, 181-184; Pub/Sub server that gateways subscribe to. The Pub/Sub server pushes updates to the gateway. Published data is delivered to matching subscriptions. See also Oswal, c. 5, l. 30-46; System seeks to avoid inconsistent enforcement for an enterprise.)
It would have been obvious to one of ordinary skill prior to the effective filing date to combine the method of modified Oswal with the subscription to a grouping of centralized identity redistribution in order to allow context information to be viewed similarly by all devices for an enterprise to allow for consistent security policy enforcement.
With respect to Claim 5, modified Oswal teaches the method of claim 1, and Oswal also teaches wherein the method further comprises, prior to receiving the user context information, receiving incoming traffic at the security platform; (c. 7, l. 6 to c. 8, l. 7; To make sure all data is monitored, data can be mirrored from the SD-WAN to the security service.)
wherein the user context information is associated with an IP address of the incoming traffic; (c. 3, l. 5-16; source IP address. See also Zuk, para. 60; IP address of flow.)
and Zuk also teaches and wherein applying the security policy comprises attributing the incoming traffic to an identified user by associating the user context information with the IP address. (para. 60; user ID deduced from source IP address.)
The same motivation to combine as the independent claim applies here.
But modified Oswal does not explicitly teach device authentication.
Ansari, however, does teach wherein the security platform is an authenticated platform of a security service, (Examiner asserts that Oswal’s teaching of setting up IPsec tunnels that secure traffic implicitly teaches authenticating the device, see c. 9, l. 58 to c. 10, l. 9. Regardless, Examiner will also cite Ansari, para. 24, 113, 143; device authenticates with service. A security platform device was previously taught.)
It would have been obvious to one of ordinary skill prior to the effective filing date to combine the method of Oswal with the authenticated security platform in order to ensure communications are with a trusted device.
With respect to Claims 9-10, they are substantially similar to Claims 4-5, respectively, and are rejected in the same manner, the same art and reasoning applying.
With respect to Claims 14-15, they are substantially similar to Claims 4-5, respectively, and are rejected in the same manner, the same art and reasoning applying.
With respect to Claim 19, modified Oswal teaches the method of claim 18, but does not explicitly teach subscribing.
Ansari, however, does teach wherein the another security platform is subscribed to a segment for centralized identity redistribution to receive the user context information from the cloud security service. (para. 17; gateway may have firewall functionality. Para. 117, 165, 181-184; Pub/Sub server that gateways subscribe to. The Pub/Sub server pushes updates to the gateway. Published data is delivered to matching subscriptions. See also Oswal, c. 5, l. 30-46; System seeks to avoid inconsistent enforcement for an enterprise.)
It would have been obvious to one of ordinary skill prior to the effective filing date to combine the method of modified Oswal with the subscription to a grouping of centralized identity redistribution in order to allow context information to be viewed similarly by all devices for an enterprise to allow for consistent security policy enforcement.
With respect to Claim 20, modified Oswal teaches the method of claim 18, but does not explicitly teach subscribing.
Ansari, however, does teach wherein the another security platform is subscribed to a segment for centralized identity redistribution to receive the user context information from the cloud security service, (para. 17; gateway may have firewall functionality. Para. 117, 165, 181-184; Pub/Sub server that gateways subscribe to. The Pub/Sub server pushes updates to the gateway. Published data is delivered to matching subscriptions. See also Oswal, c. 5, l. 30-46; System seeks to avoid inconsistent enforcement for an enterprise.)
and wherein the method further comprises: publishing the user context information to the another security platform, and, wherein preferably the segment is a grouping of security platforms or firewalls. (Para. 117, 165, 181-184; Pub/Sub server that gateways subscribe to. The Pub/Sub server pushes updates to the gateway. Published data is delivered to matching subscriptions. See also Oswal, c. 5, l. 30-46; System seeks to avoid inconsistent enforcement for an enterprise.)
It would have been obvious to one of ordinary skill prior to the effective filing date to combine the method of modified Oswal with the subscription to a grouping of centralized identity redistribution in order to allow context information to be viewed similarly by all devices for an enterprise to allow for consistent security policy enforcement.
Claims 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over Oswal (US Pat. 11,095,612) in view of Ansari (US Pub. 2010/0202450).
With respect to Claim 16, Oswal teaches a processor-implemented method, comprising: (Fig. 4a, column (c) 14, line (l) 11-35; device with processor, RAM and storage such as a hard disk)
producing at an authenticated security platform user context information, and/or obtaining at the security platform user context information from one or more sources; (An authenticated security platform will be taught later. Figs. 1a/b, c. 5, l. 62 to c. 6, l. 32; A cloud-based security service such as Prisma Access can determine metadata such as user ID, device ID, and content ID associated with each flow. The determined metadata information can then be communicated to a SD-WAN device for policy enforcement. c. 4, l. 61 to c. 5, l. 29; SD-WAN device may determine at least some of the context information instead.)
and, sending the user context information to a cloud security service. (c. 6, l. 46-53; SD-WAN determines app ID and communicates it to the security service to prevent repetition. It would have been obvious to one of ordinary skill to apply the same to any derived context information.)
But Oswal does not explicitly teach device authentication.
Ansari, however, does teach an authenticated security platform (Examiner asserts that Oswal’s teaching of setting up IPsec tunnels that secure traffic implicitly teaches authenticating the device, see c. 9, l. 58 to c. 10, l. 9. Regardless, Examiner will also cite Ansari, para. 24, 113, 143; device authenticates with service. A security platform device was previously taught.)
It would have been obvious to one of ordinary skill prior to the effective filing date to combine the method of Oswal with the authenticated security platform in order to ensure communications are with a trusted device.
With respect to Claim 17, modified Oswal teaches the method of claim 16, and Oswal also teaches wherein the security platform is an edge device in a SD-WAN network, wherein the edge device is configured to act as a connection and/or termination point of the SD-WAN network, (Fig. 1a, c. 9, l. 41 to c. 10, l. 9; SD-WAN edge devices reside at every site and act as the connection and termination points of the SD-WAN fabric. See also Fig. 2, c. 11, l. 5-17.)
wherein the edge device is further configured to connect to the cloud security service via an IPsec tunnel. (Fig. 1a, c. 9, l. 58 to c. 10, l. 9; IPsec tunnels between SD-WAN edge devices and security service.)
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NICHOLAS P CELANI whose telephone number is (571)272-1205. The examiner can normally be reached on M-F 9-5.
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, Vivek Srivastava can be reached on 571-272-7304. 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.
/NICHOLAS P CELANI/Examiner, Art Unit 2449