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 office action is in response to the amendment filed on 03/02/2026. Claims 1-3, 5-8, 10-13, & 15 are currently pending in the filing of 03/02/2026, claims 1-3, 5-8, 10-13, & 15 were also pending in the previous filing of 11/07/2025 with RCE filed on 11/26/2025, with no new or cancelled claims since the previous filing.
Response to Applicant’s Amendments / Arguments Regarding 35 U.S.C. § 103
The applicant’s remarks, on pages 9-11 of the response / amendment, the applicant argues the features which allegedly distinguish over the previously cited references cited in the 35 U.S.C. § 103 rejections.
Applicant’s arguments have been considered but are moot in view of the new ground(s) of rejection.
Claim Interpretation under U.S.C. 112(f):
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term "means" or "step" or a term used as a substitute for "means" that is a generic placeholder (also called a nonce term or a nonstructural term having no specific structural meaning) for performing the claimed function;
(B) the term "means" or "step" or the generic placeholder is modified by functional language, typically, but not always linked by the transition word "for" (e.g., "means for'') or another linking word or phrase, such as "configured to" or "so that"; and
(C) the term "means" or "step" or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word "means" (or "step") in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f). The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word "means" (or "step") in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f). The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
This application includes one or more claim limitations that do not use the word "means," but are nonetheless being interpreted under 35 U.S.C. 112(f) because the claim limitations uses a generic placeholder. First, (e.g., local security enforcement module(s) ) that is coupled with functional language (e.g., " ... forwarding at least a part of the network traffic... ") without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such limitations are in claims 6 and 8. Because these claim limitations are being interpreted under 35 U.S.C. 112(f), they are being interpreted to cover the corresponding structure described in the specification (e.g., the structural/physical connections shown in at least fig. 1 by local security enforcement modules 114 and paragraphs [0017] of the applicant’s printed publication.) as performing the claimed functions, and equivalents thereof.
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-8, 10-13, & 15 are rejected under 35 U.S.C. 103 as being unpatentable over US 20190318100 to Bhatia et al. (hereinafter Bhatia), in view of Straub US 20170048215 (hereinafter Straub), in view of US 20240056388 to Chen et al. (hereinafter Chen).
Regarding claim 1, Bhatia teaches,
A computer implemented method for monitoring and control of a network traffic in a cloud server environment, the method comprising: (fig. 4, Cloud Services Provider 410 and [0006] teaches monitoring security risks for cloud service providers who provide services so tenants may execute applications.)
receiving network traffic at a cloud service account of a plurality of cloud service accounts, each (fig. 4, Hosted Application 422. [0003] teaches tenants and accounts. [0069] teaches tenant accounts.) (Chen, further discussed below, [0058] also teaches customers / tenants at different locations.) comprising a local security enforcement module (Agent 430 described in Abstract. [0039-40] teaches that the Agent is executes in the environment provided by the service platform, which is provided by the Cloud Services Provider. Agent may provide data to Security Management.) configured to enforce security policies for data processed by the cloud service account; ([0012] teaches the Agent is configured to identify code that, when executing, performs actions identified as security risks." [0089-90] teaches Agent in communication with Control Manager 172 of Security Monitoring and Control System 102 of fig. 1, and modifies devices by performing security enforcement (blocking access to addresses), and also modifies access to services from Service Provider 112. Fig. 4 and [0197] teach the Agent 430 being in the Cloud Services Provider 410 and sending data to the Security Monitoring and Control System 402.)
(In detail regarding “cloud service account”: fig. 4 and [0190], Cloud Services Provider 410 connected to client device 406. [0003] teaches that users / tenants can subscribe to services by the service provider, and that accounts are associated with the tenant / user. Fig. 4, [0190], and [0192] also teaches Hosted Application 422 that runs applications for the client device 406, and [0191] teaches security monitoring system 402 being connected to Cloud Services 410. Agent 430 / data 432 may be sent to the Security Monitoring and Control System 402.)
forwarding at least a part of the network traffic from the cloud service account to a centralized security monitoring hub, (Security Monitoring and Control System 402) by the local security enforcement module, … (Agent 430) (Fig. 4 and [0197] teach the Agent 430 being in the Cloud Services Provider 410 and sending data to the Security Monitoring and Control System 402.)
… wherein the centralized security monitoring hub comprises a hardware-based security component; ([0066] teaches the Security Monitoring and Control System having a processor. [0033] teaches that the processors may be Application Specific Integrated Circuits (ASICs).)
daisy chaining the local security enforcement module and the hardware-based security component in a chain to enforce the security policies, … (fig. 4 and [0191] teach linking service platform 410 / “local security enforcement module” to Security Monitoring and Control System 402 / “hardware-based security component.” See also [0096].) (The applicant’s printed publication at [0038-39] describes daisy chaining as a process of linking multiple monitoring / control devices in series, so that the output of one device becomes the input of another device.) …wherein the daisy chaining is configured so that one of the local security enforcement module and the hardware-based security component continues to (Claim 9 [0012] & [0248] teach the Agent is configured to identify security risks. Thus, if the Security Monitoring and Control System 402 of fig. 4 was to fail, the Agent 430 would continue to identify security risks.)
detecting, by the hardware-based security component, (ASIC / processor of Security Monitoring and Control System 402.) offending traffic in the part of the network traffic, wherein the offending traffic comprises traffic from an unwanted source or with malicious content; ([0062] teaches the security monitoring and control system detecting threats and remediation to the cloud services 112.)
responsive to the offending traffic, sending a notification of the offending traffic to the local security enforcement module, by the centralized security monitoring hub; and (end of [0062] teaches actions taken by Service Provider are based on the detected suspicious / suspect activity at that or different Service Providers, where [0062] teaches detection to suspicious / suspect activity is performed by Security Monitoring and Control System 402.)
responsive to the notification, implementing a security enforcement strategy in the cloud service account by the local security enforcement module based on the security policy and . ([0009] teaches security policies. [0071] tenant information 124 may include access settings / security policies. [0062] teaches actions being taken at a different Service Provider based on threats detected at a first Service Provider.)
Bhatia fails to explicitly teach that after a failure of one of the local security module or the hardware of the centralized security monitoring hub, the other one continues to enforce the security policies,
However, Straub teaches,
daisy chaining the local security enforcement module and the hardware-based security component in a chain to enforce the security policies, ([0185-186] teaches OWSM that includes security and threat protection that communicates / is linked with a local security program.) (The applicant’s printed publication at [0038-39] describes daisy chaining as a process of linking multiple monitoring / control devices in series, so that the output of one device becomes the input of another device.) wherein the daisy chaining is configured so that one of the local security enforcement module and the hardware-based security component continues to enforce the security policies when the other fails; ([0186] teaches the local enforcement of security policies that are defined by a security manager. Thus, a failure of the security manager’s hardware does not prevent the local enforcement of security policies.) (As discussed above, Bhatia, Claim 9 [0012] & [0248] teach the Agent is configured to identify security risks. Thus, if the Security Monitoring and Control System 402 of fig. 4 was to fail, the Agent 430 would continue to identify security risks.)
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to combine the teachings of Bhatia, which teaches a security service for a multi-tenant service platform, which enables tenants to use the service platform, where the security service provides security services / analysis of multiple service providers that include service agents communicating with the security service (Abstract, fig. 4.), with Straub, which also teaches multi-tenant security services that uses a security service and local security that works with the security service (fig. 6 & [0157]), and further teaches local security that is capable of enforcing security policies provided from the security manager ([0185-186]). One of ordinary skill in the art would have been motivated to perform such an addition to provide Bhatia with the added ability to locally enforce security policies, as taught by Straub, for the purpose of increasing security by identifying and enforcing security policies at the local level to decrease the use of network communication while maintaining security.
Bhatia and Straub fail to explicitly teach the use of flow state tables to track network streams and local security that receives flow state tables,
However, Chen teaches,
responsive to the notification, implementing a security enforcement strategy in the cloud service account by the local security enforcement module based on the security policy and flow state tables, ([0004] & fig. 1 teach cloud-based security service with multiple sites. [0058] teaches flow / session table. [0020] & [0026] teaches threats and stateful based packet inspection.) wherein generated for the corresponding local security module based on at least a portion of the network traffic, wherein the generated flow state tables are transmitted to the local security module, ([0058]) wherein the flow state tables are configured to track and manage active network connections, and wherein the local security enforcement module changes a processing mode by the local security enforcement module based on the flow state tables. ([0058] teaches flow / session table that is updated based on location / region for a tenant using cloud-based security services that distribute to each network gateway. Also teaches security management platform provides such IPsec configuration information for the enterprise customers. [0022-23] & [0046] teach local filter apply policies / rules to filter / firewall malware, and local / localized experiences using the cloud-based security service.)
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to combine the teachings of Bhatia, which teaches a security service for a multi-tenant service platform, which enables tenants to use the service platform, where the security service provides security services / analysis of multiple service providers that include service agents communicating with the security service (Abstract, fig. 4.), with Straub, which also teaches multi-tenant security services that uses a security service and local security that works with the security service (fig. 6 & [0157]), and further teaches local security that is capable of enforcing security policies provided from the security manager ([0185-186]), with Chen, which also teaches tenant systems ([0058]) and cloud-based security service providers (fig. 1 & [0004]), and additionally teaches updating flow / session table based on location / region for a tenant ([0058]). One of ordinary skill in the art would have been motivated to perform such an addition to provide Bhatia and Straub with the added ability to utilize stateful firewalls including flow/session tables that are updated according to region, as taught by Chen, for the purpose of increasing security while increasing computational efficiency by performing updates to flow / session tables based on locations.
Regarding claim 2, Bhatia, Straub, and Chen teach,
The method of claim 1, further comprising:
Bhatia teaches,
storing data from at least a part of the forwarded network traffic at a data repository communicably coupled with the centralized security monitoring hub; and (fig. 1, Storage 122 inside Security Monitoring and Control System 102. [0067] teaches storage 122 connected to additional data stores 180.)
generating the security policy based on analysis of the stored network traffic data, source reputation information from external tenants, or a combination thereof. (fig. 1, Security Monitoring and Control System 102 includes storage 122 that includes Domain Information 128, Security Information 126, Application Information 132, and Tenant Configuration Information 124. [0071] teaches that Tenant Configuration Information 124 includes security policies, security configuration, whitelists, and blacklists that allow and ban IP addresses from being accessed.)
Regarding claim 3, Bhatia, Straub, and Chen teach,
The method of claim 2, further comprising:
Bhatia teaches,
implementing a network traffic short-circuit mechanism at the service accounts based on the flow state tables, by the local security enforcement module, the network traffic short-circuit mechanism configured to change an inline mode of the network traffic to an out-of-band mode. (Bhatia, [0071] teaches the use of access control lists such as whitelists and blacklists, which specify the security setting level for service, which may require additional authentication. See also [0111]. [0120] teaches analytics for different threat levels. [0125] teaches selecting additional action / remediation.) (The applicant’s printed publication at [0022-23] teaches short circuiting and out of band mode as: different levels of inspection of data packets based on Access Control Lists.)
Regarding claim 5, Bhatia, Straub, and Chen teach,
The method of claim 3,
Bhatia teaches,
further comprising daisy chaining at least one other hardware-based security component of the centralized security monitoring hub in the chain. (Bhatia, [0096] teaches security monitoring and control, in various implementations, can include multiple components that may be located on a single hardware platform or on multiple hardware platforms that are in communication with each other.)
Regarding claim 6, Bhatia, Straub, and Chen teach,
A system for monitoring and control of a network traffic in a cloud server environment, the system comprising: (See rejection of claim 1 above.)
a computer processor; (Bhatia, [0066] and [0033] teaching processors)
a cloud server application digitally connected with the computer processor, the cloud server application comprising: (Bhatia, fig. 1, and fig. 4)
As indicated below, portions of claim 6 are rejected using the same basis of arguments used to reject claim 1 above.
a centralized security monitoring hub comprising a hardware-based security component, the centralized security monitoring hub configured to detect an offending traffic comprising traffic from an unwanted source or with malicious content; (See rejection of claim 1 above.)
a plurality of cloud service accounts, each comprising a local security enforcement module configured to enforce security policies for data processed by the corresponding cloud service account of the plurality of cloud service accounts; (Bhatia, [0003] teaching tenant accounts that are provided services (software) by the Service Provider. [0007] teaches tenant account allows user / tenant to access the service platform / Service Provider.)
a non-transitory machine-readable storage medium that provides instructions that, if executed by the processor, are configurable to cause the system to perform operations comprising: (Bhatia, Abstract, fig. 16 and [0281], computer readable storage 1620 and 1622.)
receiving network traffic at a cloud service account of the plurality of cloud service accounts; (See rejection of claim 1 above.)
forwarding at least a part of the network traffic from the cloud service account to the centralized security monitoring hub, by the local security enforcement module of the cloud service account; (See rejection of claim 1 above.)
daisy chaining the local security enforcement module and the hardware-based security component in a chain to enforce the security policies, wherein the daisy chaining is configured so that one of the local security enforcement module and the hardware- based security component continues to enforce the security policies when the other fails;
detecting, by the hardware-based security component, the offending traffic in the part of the network traffic; (See rejection of claim 1 above.)
responsive to the offending traffic, sending a notification of the offending traffic to the local security enforcement module, by the centralized security monitoring hub; and (See rejection of claim 1 above.)
responsive to the notification, implementing a security enforcement strategy in the cloud service account by the local security enforcement module based on the security policy and flow state tables, by wherein the flow state tables are generated for the corresponding local security module based on at least a portion of the network traffic, wherein the generated flow state tables are transmitted to the local security module,
wherein the flow state tables are configured to track and manage active network connections, and wherein the local security enforcement module changes a processing mode by the local security enforcement module based on the flow state tables. (See rejection of claim 1 above.)
Regarding claim 7, Bhatia, Straub, and Chen teach,
The system of claim 6, further comprising:
storing data from at least a part of the forwarded network traffic at a data repository communicably coupled with the centralized security monitoring hub; and
generating the security policy based on analysis of the stored network traffic data, source reputation information from external tenants, or a combination thereof.
Claim 7 is rejected using the same basis of arguments used to reject claim 2 above.
Regarding claim 8, Bhatia, Straub, and Chen teach,
The system of claim 7 further comprising:
implementing a network traffic short-circuit mechanism at the service accounts based on the flow state tables, by the local security enforcement module, the network traffic short-circuit mechanism configured to change an inline mode of the network traffic to an out-of-band mode.
Claim 8 is rejected using the same basis of arguments used to reject claim 3 above.
Regarding claim 10, Bhatia, Straub, and Chen teach,
The system of claim 8 further comprising daisy chaining at least one other hardware-based security component of the centralized security monitoring hub in the chain.
Claim 10 is rejected using the same basis of arguments used to reject claim 5 above.
Regarding claim 11, Bhatia, Straub, and Chen teach,
A non-transitory machine-readable storage medium that provides instructions that, if executed by a processor, are configurable to cause said processor to perform operations comprising: (Bhatia, Abstract, fig. 16 and [0281], computer readable storage 1620 and 1622.)
The portions of claim 11 included below are rejected using the same basis of arguments used to reject claim 1 above.
receiving network traffic at a cloud service account of a plurality of cloud service accounts, each comprising a corresponding local security enforcement module configured to enforce security policies for data processed by the cloud service account;
forwarding at least a part of the network traffic from the cloud service account to a centralized security monitoring hub, by the local security enforcement module, wherein the centralized security monitoring hub comprises a hardware-based security component;
daisy chaining the local security enforcement module and the hardware-based security component in a chain to enforce the security policies, wherein the daisy chaining is configured so that one of the local security enforcement module and the hardware- based security component continues to enforce the security policies when the other fails;
detecting, by the hardware-based security component, offending traffic in the part of the network traffic, wherein the offending traffic comprises traffic from an unwanted source or with malicious content;
responsive to the offending traffic, sending a notification of the offending traffic to the local security enforcement module, by the centralized security monitoring hub; and
responsive to the notification, implementing a security enforcement strategy in the cloud service account by the local security enforcement module based on the security policy and flow state tables, wherein the flow state tables are generated for the corresponding local security module based on at least a portion of the network traffic, wherein the generated flow state tables are transmitted to the local security module, wherein the flow state tables are configured to track and manage active network connections, and wherein the local security enforcement module changes a processing mode by the local security enforcement module based on the flow state tables.
Regarding claim 12, Bhatia, Straub, and Chen teach,
The non-transitory machine-readable storage medium of claim 11 further comprising:
storing data from at least a part of the forwarded network traffic at a data repository communicably coupled with the centralized security monitoring hub; and
generating the security policy based on analysis of the stored network traffic data, source reputation information from external tenants, or a combination thereof.
Claim 12 is rejected using the same basis of arguments used to reject claim 2 above.
Regarding claim 13, Bhatia, Straub, and Chen teach,
The non-transitory machine-readable storage medium of claim 12 further comprising:
implementing a network traffic short-circuit mechanism at the service accounts based on the flow state tables, by the local security enforcement module, the network traffic short-circuit mechanism configured to change an inline mode of the network traffic to an out-of-band mode.
Claim 13 is rejected using the same basis of arguments used to reject claim 3 above.
Regarding claim 15, Bhatia, Straub, and Chen teach,
The non-transitory machine-readable storage medium of claim 13 further comprising daisy chaining at least one other hardware-based security component of the centralized security monitoring hub in the chain.
Claim 15 is rejected using the same basis of arguments used to reject claim 5 above.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, 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 BRIAN WILLIAM AVERY whose telephone number is (571)272-3942. The examiner can normally be reached on 9AM-5PM.
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, Farid Homayounmehr can be reached on (571)272-3739.
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 https://ppair-my.uspto.gov/pair/PrivatePair. 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.
/B.W.A./
/JASON K GEE/Primary Examiner, Art Unit 2495
Prosecution Insights