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 .
This following is a final office action in response to the communication received on April 7, 2026. Claims 1-3, 7, 9 and 12-15 have been amended. Therefore, Claims 1-18 are pending and addressed below.
Response to Amendment
Examiner has withdrawn the drawing objections as applicant amended the replacement drawing.
Applicant’s amendment and response to the claim are sufficient to overcome the 35 USC 112 (b) rejection set forth in the previous office action. Examiner has withdrawn the rejection under 35 USC 112 (b) as applicant amended the claim.
Examiner has withdrawn the rejection under double patenting as applicant has filed a terminal disclaimer.
Response to Arguments
Applicant’s arguments filed April 7, 2026 have been fully considered but they are not persuasive for the following reasons:
Applicant’s arguments with respect to the rejections of amended claims 1, 7 and 13 under 35 U.S.C 102(a)(1) have been fully considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. A new ground of rejection under 35 U.S.C 103 is made in view of the combination of prior art of Didomenico et al (US PG-PUB No. 20200067986 A1) and Verma et al (US PG-PUB No. 20230124136 A1) (see below rejection details)
Therefore, claims 1, 7 and 13 are rejected under 35 U.S.C 103. As claims 2-6 are dependent directly or indirectly on claim 1, claims 8-12 are dependent directly or indirectly on claim 7, claims 14-18 are dependent directly or indirectly on claim 13, applicant’s argument with respect to the rejections of claim 2-6, 8-12 and 14-18 are moot.
Claim Rejections - 35 USC § 103
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 (i.e., changing from AIA to pre-AIA ) 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.
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-4, 7-10 and 13-16 are rejected under 35 U.S.C. 103 as being unpatentable over Didomenico et al (US PG-PUB No. 20200067986 A1) in view of Verma et al (US PG-PUB No. 20230124136 A1).
Regarding claims 1, 7 and 13, Didomenico teaches a cloud network message processing method, system and device, the method implemented by a traffic director for a cloud security device, comprising:
obtaining a cloud network message; wherein the cloud network message is sent from a source end to a cloud security device according to a default routing policy (Paragraph [0006]: “The method also includes receiving, at the enterprise security management software tool (implemented by a traffic director for a cloud security device). network traffic data (obtaining cloud network message) describing network traffic in the enterprise network (the cloud network message processing method includes describing the cloud network message is sent from a source end to a cloud security device in the enterprise network), and generating an assessment of network security coverage by policies in one or both of the enterprise security management software tool and the third party network traffic management software based at least on the network traffic data, the configuration data, and a security policy defined for the enterprise network by the enterprise security management software tool (default routing policy).”);
determining a target security device for the cloud network message from pre-configured multiple types of candidate security devices based on identification information contained in the cloud network message; wherein the candidate security devices comprise: a third-party security device outside the cloud security device (Paragraph [0006]: “a method includes receiving a definition in an enterprise security management software tool of a node within an enterprise network that represents a third party network traffic management device (the definition determines a target security device for the cloud network message from pre-configured multiple types of candidate security devices) controlled using third party traffic management software, the third party network traffic management device positioned within the enterprise to manage traffic within a portion of the enterprise network.”; Paragraph [0040]: “embodiments of the present invention are directed to providing integration between an enterprise security management configuration tool (traffic director) and third party network traffic software that can be used to manage network traffic through third party networking devices, such as routers, firewalls (pre-configured third-party security device outside the cloud security device), or other physical equipment.”; Paragraph [0122]: “In the embodiment shown, for each defined third party networking device, the third party networking device is accessed to obtain information regarding the security policy applied at that device by third party security software (step 606). As noted above, this may include, e.g., providing a network address for the third party networking device or otherwise identifying the device, as well as providing access credentials for such a device (determining a target security device based on identification information contained in the cloud network message) as seen in FIG. 15.”); and
sending the cloud network message, via a pre-established direction path between the traffic director and the target security device, to the target security device for security processing, and sending the cloud network message processed by the target security device to a destination end, wherein the pre-established direction path is pre-configured for forwarding the cloud network message without performing routing resolution or identification processing (Paragraph [0042]: “Due to the complexity of enterprise security policies and enterprise topologies, establishing an enterprise security policy that can apply across an entire enterprise is complex (pre-established direction path between the traffic director and the target security device across an entire enterprise). To simplify the complexity of such policy definition, the present Applicant has developed an enterprise security management configuration tool (this is the traffic director which send the cloud network message to the target security device for security processing).”).
Didomenico teaches the candidate security devices comprises third-party security devices outside of the cloud security device. Didomenico is not relying on teaching the built-in security device inside the cloud security device.
However, Verma teaches the candidate security devices comprises both of a built-in security device inside the cloud security device, and a third-party security device outside the cloud security device (Paragraph [0091]: “the firewalls 405 include an organization firewall (built-in security device) 405a and a cloud-based firewall (third-party security device) 405b.”; The terms are further explained in Paragraph [0050]: “the terms “organization firewall” refer to a firewall maintained by an organization” and Paragraph [0051]: “the terms “cloud-based firewall” refer to a virtual firewall maintained by a third-party cloud service provider or the organization”.).
Didomenico and Verma are both considered to be analogous to the claimed invention because they both teach managing firewall rules and network data traffic. Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the candidate security devices disclosed by Didomenico with adding a built-in security device, disclosed by Verma.
One of the ordinary skills in the art would have been motivated to make this modification in order to route IP data packets to a cloud-based service based on the firewall rules/policies, as suggested by Verma in paragraph [0006].
Regarding claims 2, 8 and 14, Didomenico and Verma teach all of the features with respect to claim 1, 7 and 13, as outlined above.
Didomenico further teaches wherein, the traffic director is provided inside the cloud security device; obtaining the cloud network message comprises: receiving, by the traffic director, the cloud network message sent from the source end (Paragraph [0007]: “receive, at the enterprise security management software tool (traffic director), network traffic data (obtaining the cloud network message) describing network traffic in the enterprise network; ”; Paragraph [0101]: “Furthermore, although the Panorama (example of a software management tool which is used to define policies for security firewall devices) took defines source/destination (the cloud network message sent from the source end to the destination end), the tool 412 defines a consumer/provider, and can be correlated.”).
Regarding claims 3, 9 and 15, Didomenico and Verma teach all of the features with respect to claim 1, 8 and 13, as outlined above.
Verma further teaches wherein determining the target security device for the cloud network message from the pre-configured multiple types of candidate security devices comprises: determining a target type corresponding to the identification information contained in the cloud network message (Paragraph [0099]: “The encapsulated IP data packet is routed to the organization's firewall 405a (The cloud network message is forwarded to a built-in security device)”; Paragraph [0101]: “When the destination IP address of each IP data packet is identified (the identification information contained in the cloud network message), the one or more IP data packets are routed to the cloud-based firewall 405b (the cloud network message is forwarded to a third-party security device) which verifies the firewall policies for the gateway 404 based on the destination IP address. ”);
Didomenico teaches determining one or more candidate security devices of the target type from the pre-configured multiple types of candidate security devices and determining the target security device from the one or more candidate security devices of the target type (Paragraph [0040]: “embodiments of the present invention are directed to providing integration between an enterprise security management configuration tool and third party network traffic software that can be used to manage network traffic through third party networking devices, such as routers, firewalls, or other physical equipment. By defining a software interface through which configuration data for third party networking devices can be queried and configuration data accessed, the enterprise security management configuration tool can compare overall network traffic to the configuration provided by the third party networking software to assess an overall security level within an enterprise network”).
One of the ordinary skills in the art would have been motivated to make this modification in order to route IP data packets to a cloud-based service based on the firewall rules/policies, as suggested by Verma in paragraph [0006].
Regarding claims 4, 10 and 16, Didomenico and Verma teach all of the features with respect to claim 3, 9 and 15, as outlined above.
Didomenico further teaches wherein determining the target security device from the one or more candidate security devices of the target type comprises: in the case that there is only one candidate security device of the target type, taking the one candidate security device of the target type as the target security device; or in the case that there are multiple candidate security devices of the target type, determining the target security device from the multiple candidate security devices of the target type (Paragraph [0122]: “for each defined third party networking device, the third party networking device is accessed to obtain information regarding the security policy applied at that device by third party security software (step 606) (in the case that there is only one candidate security device of the target type, taking the one candidate security device of the target type as the target security device).”; Paragraph [0124]: “It is noted that, particularly in the event there is no centralized third party security software, each third party networking device that is discovered within the enterprise network is accessed and configuration information is obtained. Accordingly, steps 606-608 may occur iteratively or in parallel for each third party networking device (in the case that there are multiple candidate security devices of the target type, determining the target security device from the multiple candidate security devices of the target type).”).
Claims 5, 11 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Didomenico et al (US PG-PUB No. 20200067986 A1) and Verma et al (US PG-PUB No. 20230124136 A1), in view of Kirby et al (US PG-PUB No. 20170208097 A1).
Regarding claim 5, 11 and 17, Didomenico and Verma teach all of the features with respect to claim 4, 10 and 16, as outlined above.
Didomenico and Verma failed to explicitly teach, but Kirby teaches wherein determining the target security device from the multiple candidate security devices of the target type comprises: determining the target security device from the multiple candidate security devices of the target type based on session information contained in the cloud network message; wherein target security devices corresponding to a same session information are identical (Paragraph [0038]: “In some embodiments, the security device controller includes connecting to a security device, maintaining a session with the security device, and sending multiple commands to the security device over a period of time that the session is maintained/open (based on session information) (e.g., the multiple commands can be on a blocking or non-blocking channel in which the security device can send an authorization token that can be used accordingly to send commands).”).
Didomenico and Verma and Kirby are all considered to be analogous to the claimed invention because they all teach managing firewall rules and network data traffic. Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified determining the target security device disclosed by Didomenico and Verma with adding based on session information contained in the cloud network message, disclosed by Kirby.
One of the ordinary skills in the art would have been motivated to make this modification in order to maintain the session for authorization, as suggested by Kirby in paragraph [0038].
Claims 6, 12 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Didomenico et al (US PG-PUB No. 20200067986 A1) and Verma et al (US PG-PUB No. 20230124136 A1), in view of Kirby et al (US PG-PUB No. 20170208097 A1), in further view of Whillock et al (US Patent No. 8150970 B1).
Regarding claim 6, 12 and 18, Didomenico, Verma and Kirby teach all of the features with respect to claim 5, 11 and 17, as outlined above.
Kirby further teaches wherein, the session information includes: a source IP address and a destination IP address (Paragraph [0069]: "In some embodiments, the security device controller also provides more advanced search features including the ability to search multiple rules against multiple devices."; [0070]: "The search process can begin by selecting a workbook. The search type (e.g., access or rule) can be selected (e.g., the access search type can return any and all matches, including larger subnets, overlapping rules, and partial matches; and the rule search type can return exact matches, if any exist, from the filter sets in the selected workbook). A source and destination IP address or prefix in CIDR format, subnet mask or as a range (e.g.,
10.0.0.0-12.0.0.0) can be entered.").
Didomenico, Verma and Kirby fail to explicitly teach performing an order-independent hash operation on the combined IP address to obtain a hash value; performing a modulo operation based on the hash value and the number of candidate security devices of the target type to obtain a remainder; and taking the candidate security device of the target type corresponding to the remainder as the target security device.
However, Whillock teaches performing combination processing on the source IP address and the destination IP address to obtain a combined IP address; performing an
order-independent hash operation on the combined IP address to obtain a hash value;
performing a modulo operation based on the hash value and the number of candidate
security devices of the target type to obtain a remainder; and taking the candidate security device of the target type corresponding to the remainder as the target security
device ([Col 4, line 40] - [Col 5, line 6]: "The target (target security device) can be
determined from the incoming identifier of the connection. For example, the identifier
can be a URI (the source IP address and destination IP address). The URI includes
all of the information to determine each level of the hierarchy 400 that will receive the
work corresponding to this request. Typically, a client's computer contacts a DNS server
to resolve the website address, e.g., www.happy.com, into an IP address. The IP address combined with the port receiving the request for work can be used to identify the adaptor (performing combination processing on the source IP address and the destination IP address to obtain a combined IP address). In this example, an identifier for the incoming work request is the URI provided above, i.e., rtmp://www.happy.com/happyApplication/somelnstance. A hash function is applied to
generate a unique number representing the identifier (performing an order- independent hash operation on the combined IP address to obtain a hash value), for example, the number 12345. The modulo operation is then applied, where the dividend is 12345 and the divisor is the number of core processes (performing a modulo operation based on the hash value and the number of candidate security devices of the target type to obtain a remainder), i.e., 14. The remainder is determined in this example to be "11". The work request is therefore assigned to the core process mapped to the remainder of "11" (taking the candidate security device of the target type corresponding to the remainder as the target security device.). The next time a work request is received from the same source, i.e., the same application instance having the same URI, the request will be sent to the same core process.”).
Didomenico, Verma, Kirby and Whillock are all considered to be analogous to the claimed invention because they all teach message forwarding (work load distribution) among security devices (among server processes). Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method, systema and device disclosed by Didomenico, Verma and Kirby with adding performing combination processing on the source IP address and the destination address to obtain a combined IP address; performing an order-independent hash operation on the combined IP address to obtain a hash value; performing a modulo operation based on the hash value and the number of candidate security devices of the target type to obtain a remainder; and taking the candidate security device of the target type corresponding to the remainder as the target security device disclosed by Whillock.
One of the ordinary skills in the art would have been motivated to make this modification in order to provide fairness and affinity in the work distribution (cloud network message processing), as suggested by Whillock, in [Col 2, line 67].
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Nellen (US 11057349 B2) discloses Cloud-based Multi-function Firewall And Zero Trust Private Virtual Network
Cometto et al (US 12375449 B2) discloses Virtual Private Cloud Network Switching
Martin et al (US 20200336513 A1) discloses NETWORK SECURITY AND MANAGEMENT SYSTEM
Saavedra et al (US 20190182213 A1) discloses SYSTEM, APPARATUS AND METHOD FOR PROVIDING A UNIFIED FIREWALL MANAGER
Miriyala et al (US 11700236 A1) discloses Packet steering to a host-based firewall in virtualized environments
Zhang et al (CN 107872390 A) discloses A Routing Method And Message Transmitting Device
Ruan et al (CN 117155694 A) discloses Method And Device For Configuring Private Cloud Firewall
Xu (CN 116055133 A) discloses Flow Forwarding Method, Device, Electronic Equipment And Computer Readable Storage Medium
Qu (CN 113923046 A) discloses A Realizing Method And System Of Distributed Firewall Safety
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 JASMINE DAY whose telephone number is (571)272-0204. The examiner can normally be reached Monday - Friday 9:00 - 5:00.
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, Philip Chea can be reached at 571-272-3951. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/J.M.D./Examiner, Art Unit 2499 /PHILIP J CHEA/Supervisory Patent Examiner, Art Unit 2499
Prosecution Insights