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 09/17/2025.
Claims 1, 14 and 20 have been amended. Claims 1-20 are pending.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-3, 6, 11, 14-16, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Bernstein et al (2018/0278639) in views of Koral et al (2023/0080679) and Chien (2018/0198796).
For claim 1, Bernstein teaches a method performed by at least one processor (par.63, lines 1-2 and par.88, lines 8-9), the method comprising: detecting an onboarding of an application (the application containers including a respective container image that was detected as a new container image as Bernstein explains in par.77); determining one or more application properties of the application in response to the detecting (the detector container is configured to determine a filtering profile as in application properties for the protected APP container as Bernstein explains in par.53 and par.54); generating a protection program based on the one or more application properties (the routing rules are generated based on analysis of the protected APP container as Bernstein explains in par.33 and par.78); and deploying, by the security service, the protection program (container images of the protected APP container to be deployed in a containerized environment are analyzed to determine an application type of an application to be executed by the protected APP container as Bernstein explains in par.34 and par.81), wherein the protection program provides a mitigation action in response to a detection of an attack on the application (when malicious activity has been detected at S630, such activity is blocked or otherwise mitigated using one or more filtering rules design to block or present certain type of threats as Bernstein explains in par.80 and par.81).
Bernstein fails to teach that of a near real time (near-RT) radio access network (RAN) intelligent controller (RIC) and wherein the application comprises an xApp onboarded to the near-RT RIC, generating by a security service within the near-RT RIC and distinct from any xApp, wherein the protection program provides a mitigation action in response to a detection of an attack on the xApp, wherein the application properties includes a list of ports determined in response to onboarded the xApp, and wherein the detection of the attack comprises determining, by the protection program, whether a received packet specifies a port included in the list of ports.
Koral teaches, similar system, of a near real time (near-RT) radio access network (RAN) intelligent controller (RIC) (Koral teaches that one or more RANs (e.g., RAN 110) can be based on open-RAN (O-RAN) technology and standards, real or near real time RAN intelligent controller (RIC) par.42), wherein the application comprises an xApp onboarded to the near-RT RIC (Koral teaches that xApp can be inside or within of near-RT RIC as Koral teaches in par.45), generating by a security service within the near-RT RIC and distinct from any xApp (Koral teaches that of security system that performing the aggressive device detection analysis when the applicable threshold amount of signaling has been satisfied (instead of, for example, on a continuous basis) or when a suspected aggressive device report message has been received, can desirably protect and secure the communication network 102 from aggressive signaling as Koral teaches in par.55), wherein the protection program provides a mitigation action in response to a detection of an attack on the xApp (Koral teaches that security program or system to detect attach of application which is part or within of RAN and can employ a security application (e.g., aggressive device detector, aggressive and/or malicious event detector, and/or DDoS application) to facilitate detecting and mitigating aggressive and/or malicious communication devices and associated aggressive and/or malicious events against the RAN 110, and managing (e.g., controlling) attachments, registrations, and/or connections of communication devices to the RAN 110 or associated communication network 102. For example, the security application can be a micro services application (e.g., xApp) that can be part of or built on top of the RICas Koral teaches in par.45) and wherein the application properties includes a list of ports determined in response to onboarded the xApp (Koral teaches the system includes ports which is part of communication device that is part of overall system of RAN as Koral teaches in par.40 and 45). It would have been obvious to one ordinary skill in the art before effective filling date to modify Bernstein to include near real time (near-RT) radio access network (RAN) intelligent controller (RIC) as taught and suggested by Koral for the purpose of performing a mitigation or responsive action to mitigate (e.g., reduce or minimize) the aggressive and/or malicious behavior of such aggressive and/or malicious communication devices at the RAN level of the communication network, which can mitigate (e.g., reduce or minimize) the impact (e.g., negative impact) of such aggressive and/or malicious communication devices not only at the RAN level but also at the packet core component and other network equipment of the communication network (Koral, par.45).
Chien teaches, similar system, wherein the application properties includes a list of ports, (Chien teaches that the process will at a minimum check the destination port against a white list of UDP ports, so that UDP communications are only allowed with respect to ports that are identified in the white list. In the outbound case, module 821 and/or 822 may also assure that UDP packets are only sent to destination addresses and/or ports that are allowable under a corresponding white list as Chien teaches in par.144) and wherein the detection of the attack comprises determining, by the protection program, whether a received packet specifies a port included in the list of ports (Chien teaches that if the IP address, port number, and category code matches those in the white list, the evaluation module may indicate a high security rating. If the IP address and port number match, but the category code does not match, the evaluation module may determine an intermediate security rating, and request a user instruction on how to proceed. If the IP address and port number do not match those in the white list, the evaluation module may determine a lowest security rating. The evaluation module and/or other applications can take different actions, depending on the security rating meaning Chien’s system can determine or identify port from list of ports as Chien teaches in par.73). It would have been obvious to one ordinary skill in the art before effective filling date to modify Bernstein to include packet specifies a port included in the list of ports as taught and suggested by Chien for the purpose of evaluating a questionable network communication whether an outbound or inbound network communication is allowable based on one or more factors or properties of the communication, including one or more of an IP address, a listening port, a geographic location, time of day, or the like and to only communicate with other devices that are identified in a white list of trusted computing systems (Chien, abstract).
For claim 2, Bernstein in view of Koral and Chien further teaches wherein the detection of the attack on the application includes the protection program inspecting a received packet ( the detector container is configured to inspect and filter traffic redirected from the protected APP container in accordance with the configuration defined in the filtering profile for the protected APP container as Bernstein explains in par.78), and wherein the mitigation action includes dropping the received packet in response to the detection of the attack based on the inspection (when malicious activity has been detected at S630, such activity is blocked or otherwise mitigated using one or more filtering rules design to block or present certain type of threats as Bernstein explains in par.80 and par.81).
For claim 3, Bernstein in view of Koral and Chien further teaches wherein the detection of the attack occurs in response to a determination (such that traffic is redirected to the detector container when the traffic is originally directed to one of the ports defined in the routing rules as Bernstein explains in par.33). Bernstein fails to teach that based on the inspection, that the specified port is not included in the list of ports.
Chien further teaches based on the inspection, that the specified port is not included in the list of ports (Chien teaches that if the IP address, port number, and category code matches those in the white list, the evaluation module may indicate a high security rating. If the IP address and port number match, but the category code does not match, the evaluation module may determine an intermediate security rating, and request a user instruction on how to proceed. If the IP address and port number do not match those in the white list, the evaluation module may determine a lowest security rating. The evaluation module and/or other applications can take different actions, depending on the security rating meaning Chien’s system can determine or identify port from list of ports as Chien teaches in par.73). It would have been obvious to one ordinary skill in the art before effective filling date to modify Bernstein to include specifies a port included in the list of ports as taught and suggested by Chien for the purpose of evaluating a questionable network communication whether an outbound or inbound network communication is allowable based on one or more factors or properties of the communication, including one or more of an IP address, a listening port, a geographic location, time of day, or the like and to only communicate with other devices that are identified in a white list of trusted computing systems (Chien, abstract). The same motivation as claim1 applies.
For claim 6, Bernstein in view of Koral and Chien further teaches wherein the one or more application properties includes list of predetermined processes of the application, wherein the detection of the attack on the application occurs in response to detection of execution of a process not included in the list of predetermined processes, and wherein the mitigation action includes blocking the process not included in the list of predetermined processes (the learned behavior may be based on resources used by the protected APP container as Bernstein explains in par.36 and par.37).
For claim 11, Bernstein in view of Koral and Chien further teaches after deploying the protection program, determining a new property of the application; and adjusting one or more rules of the protection program (based on the identified abnormalities, the runtime model may be updated in real-time, thereby allowing for dynamic adaption of filtering based on newly identified abnormalities as Bernstein explains in par.52).
For claim 14, Bernstein teaches a network node operating in a wireless communication network (par.62), the network node comprising: at least one memory configured to store computer program code (par.62); and at least one processor configured to access said at least one memory and operate as instructed by said computer program code (par.64), said computer program code including: detecting code configured to cause at least one of said at least one processor to detect an onboarding of an application (the application containers including a respective container image that was detected as a new container image as Bernstein explains in par.77), determining code configured to cause at least one of said at least one processor to determine one or more application properties of the application in response to the detecting (the detector container is configured to determine a filtering profile as in application properties for the protected APP container as Bernstein explains in par.53 and par.54), generating code configured to cause at least one of said at least one processor to generate a protection program based on the one or more application properties (the routing rules are generated based on analysis of the protected APP container as Bernstein explains in par.33 and par.78), and deploying code configured to cause at least one of said at least one processor to deploy, by the security service, the protection program (container images of the protected APP container to be deployed in a containerized environment are analyzed to determine an application type of an application to be executed by the protected APP container as Bernstein explains in par.34 and par.81), wherein the protection program provides a mitigation action in response to a detection of an attack on the application (when malicious activity has been detected at S630, such activity is blocked or otherwise mitigated using one or more filtering rules design to block or present certain type of threats as Bernstein explains in par.80 and par.81).
Bernstein fails to teach that of a near real time (near-RT) radio access network (RAN) intelligent controller (RIC) and wherein the application comprises an xApp onboarded to the near-RT RIC, generating by a security service within the near-RT RIC and distinct from any xApp, wherein the protection program provides a mitigation action in response to a detection of an attack on the xApp, wherein the application properties includes a list of ports determined in response to onboarded the xApp, and wherein the detection of the attack comprises determining, by the protection program, whether a received packet specifies a port included in the list of ports.
Koral teaches, similar system, of a near real time (near-RT) radio access network (RAN) intelligent controller (RIC) (Koral teaches that one or more RANs (e.g., RAN 110) can be based on open-RAN (O-RAN) technology and standards, real or near real time RAN intelligent controller (RIC) par.42), wherein the application comprises an xApp onboarded to the near-RT RIC (Koral teaches that xApp can be inside or within of near-RT RIC as Koral teaches in par.45), generating by a security service within the near-RT RIC and distinct from any xApp (Koral teaches that of security system that performing the aggressive device detection analysis when the applicable threshold amount of signaling has been satisfied (instead of, for example, on a continuous basis) or when a suspected aggressive device report message has been received, can desirably protect and secure the communication network 102 from aggressive signaling as Koral teaches in par.55), wherein the protection program provides a mitigation action in response to a detection of an attack on the xApp (Koral teaches that security program or system to detect attach of application which is part or within of RAN and can employ a security application (e.g., aggressive device detector, aggressive and/or malicious event detector, and/or DDoS application) to facilitate detecting and mitigating aggressive and/or malicious communication devices and associated aggressive and/or malicious events against the RAN 110, and managing (e.g., controlling) attachments, registrations, and/or connections of communication devices to the RAN 110 or associated communication network 102. For example, the security application can be a micro services application (e.g., xApp) that can be part of or built on top of the RICas Koral teaches in par.45) and wherein the application properties includes ports determined in response to onboarded the xApp (Koral teaches the system includes ports which is part of communication device that is part of overall system of RAN as Koral teaches in par.40 and 45). It would have been obvious to one ordinary skill in the art before effective filling date to modify Bernstein to include near real time (near-RT) radio access network (RAN) intelligent controller (RIC) as taught and suggested by Koral for the purpose of performing a mitigation or responsive action to mitigate (e.g., reduce or minimize) the aggressive and/or malicious behavior of such aggressive and/or malicious communication devices at the RAN level of the communication network, which can mitigate (e.g., reduce or minimize) the impact (e.g., negative impact) of such aggressive and/or malicious communication devices not only at the RAN level but also at the packet core component and other network equipment of the communication network (Koral, par.45).
Chien teaches, similar system, wherein the application properties includes a list of ports, (Chien teaches that the process will at a minimum check the destination port against a white list of UDP ports, so that UDP communications are only allowed with respect to ports that are identified in the white list. In the outbound case, module 821 and/or 822 may also assure that UDP packets are only sent to destination addresses and/or ports that are allowable under a corresponding white list as Chien teaches in par.144) and wherein the detection of the attack comprises determining, by the protection program, whether a received packet specifies a port included in the list of ports (Chien teaches that if the IP address, port number, and category code matches those in the white list, the evaluation module may indicate a high security rating. If the IP address and port number match, but the category code does not match, the evaluation module may determine an intermediate security rating, and request a user instruction on how to proceed. If the IP address and port number do not match those in the white list, the evaluation module may determine a lowest security rating. The evaluation module and/or other applications can take different actions, depending on the security rating meaning Chien’s system can determine or identify port from list of ports as Chien teaches in par.73). It would have been obvious to one ordinary skill in the art before effective filling date to modify Bernstein to include packet specifies a port included in the list of ports as taught and suggested by Chien for the purpose of evaluating a questionable network communication whether an outbound or inbound network communication is allowable based on one or more factors or properties of the communication, including one or more of an IP address, a listening port, a geographic location, time of day, or the like and to only communicate with other devices that are identified in a white list of trusted computing systems (Chien, abstract).
For claim 15, Bernstein in view of Karol and Chien further teaches wherein the detection of the attack on the application includes the protection program inspecting a received packet ( the detector container is configured to inspect and filter traffic redirected from the protected APP container in accordance with the configuration defined in the filtering profile for the protected APP container as Bernstein explains in par.78), and wherein the mitigation action includes dropping the received packet in response to the detection of the attack based on the inspection (when malicious activity has been detected at S630, such activity is blocked or otherwise mitigated using one or more filtering rules design to block or present certain type of threats as Bernstein explains in par.80 and par.81).
For claim 16, Bernstein in view of Karol and Chien further teaches wherein the detection of the attack occurs in response to a determination (such that traffic is redirected to the detector container when the traffic is originally directed to one of the ports defined in the routing rules as Bernstein explains in par.33). Bernstein fails to teach that based on the inspection, that the specified port is not included in the list of ports.
Chien further teaches based on the inspection, that the specified port is not included in the list of ports (Chien teaches that if the IP address, port number, and category code matches those in the white list, the evaluation module may indicate a high security rating. If the IP address and port number match, but the category code does not match, the evaluation module may determine an intermediate security rating, and request a user instruction on how to proceed. If the IP address and port number do not match those in the white list, the evaluation module may determine a lowest security rating. The evaluation module and/or other applications can take different actions, depending on the security rating meaning Chien’s system can determine or identify port from list of ports as Chien teaches in par.73). It would have been obvious to one ordinary skill in the art before effective filling date to modify Bernstein to include specifies a port included in the list of ports as taught and suggested by Chien for the purpose of evaluating a questionable network communication whether an outbound or inbound network communication is allowable based on one or more factors or properties of the communication, including one or more of an IP address, a listening port, a geographic location, time of day, or the like and to only communicate with other devices that are identified in a white list of trusted computing systems (Chien, abstract). The same motivation as claim14 applies.
For claim 19, Bernstein in view of Karol and Chien further teaches wherein the one or more application properties includes list of predetermined processes of the application, wherein the detection of the attack on the application occurs in response to detection of execution of a process not included in the list of predetermined processes, and wherein the mitigation action includes blocking the process not included in the list of predetermined processes (the learned behavior may be based on resources used by the protected APP container as Bernstein explains in par.36 and par.37).
For claim 20, Bernstein teaches a non-transitory computer readable medium having instructions stored therein (par.62), which when executed by a processor cause the processor to execute (par.64) a method comprising: detecting an onboarding of an application (the application containers including a respective container image that was detected as a new container image as Bernstein explains in par.77); determining one or more application properties of the application in response to the detecting the detector container is configured to determine a filtering profile as in application properties for the protected APP container as Bernstein explains in par.53 and par.54); generating a protection program based on the one or more application properties (the routing rules are generated based on analysis of the protected APP container as Bernstein explains in par.33 and par.78); and deploying, by the security service, the protection program, wherein the protection program provides a mitigation action in response to a detection of an attack on the application (when malicious activity has been detected at S630, such activity is blocked or otherwise mitigated using one or more filtering rules design to block or present certain type of threats as Bernstein explains in par.80 and par.81).
Bernstein fails to teach that of a near real time (near-RT) radio access network (RAN) intelligent controller (RIC) and wherein the application comprises an xApp onboarded to the near-RT RIC, generating by a security service within the near-RT RIC and distinct from any xApp, wherein the protection program provides a mitigation action in response to a detection of an attack on the xApp, wherein the application properties includes a list of ports determined in response to onboarded the xApp, and wherein the detection of the attack comprises determining, by the protection program, whether a received packet specifies a port included in the list of ports.
Koral teaches, similar system, of a near real time (near-RT) radio access network (RAN) intelligent controller (RIC) (Koral teaches that one or more RANs (e.g., RAN 110) can be based on open-RAN (O-RAN) technology and standards, real or near real time RAN intelligent controller (RIC) par.42), wherein the application comprises an xApp onboarded to the near-RT RIC (Koral teaches that xApp can be inside or within of near-RT RIC as Koral teaches in par.45), generating by a security service within the near-RT RIC and distinct from any xApp (Koral teaches that of security system that performing the aggressive device detection analysis when the applicable threshold amount of signaling has been satisfied (instead of, for example, on a continuous basis) or when a suspected aggressive device report message has been received, can desirably protect and secure the communication network 102 from aggressive signaling as Koral teaches in par.55), wherein the protection program provides a mitigation action in response to a detection of an attack on the xApp (Koral teaches that security program or system to detect attach of application which is part or within of RAN and can employ a security application (e.g., aggressive device detector, aggressive and/or malicious event detector, and/or DDoS application) to facilitate detecting and mitigating aggressive and/or malicious communication devices and associated aggressive and/or malicious events against the RAN 110, and managing (e.g., controlling) attachments, registrations, and/or connections of communication devices to the RAN 110 or associated communication network 102. For example, the security application can be a micro services application (e.g., xApp) that can be part of or built on top of the RICas Koral teaches in par.45) and wherein the application properties includes ports determined in response to onboarded the xApp (Koral teaches the system includes ports which is part of communication device that is part of overall system of RAN as Koral teaches in par.40 and 45). It would have been obvious to one ordinary skill in the art before effective filling date to modify Bernstein to include near real time (near-RT) radio access network (RAN) intelligent controller (RIC) as taught and suggested by Koral for the purpose of performing a mitigation or responsive action to mitigate (e.g., reduce or minimize) the aggressive and/or malicious behavior of such aggressive and/or malicious communication devices at the RAN level of the communication network, which can mitigate (e.g., reduce or minimize) the impact (e.g., negative impact) of such aggressive and/or malicious communication devices not only at the RAN level but also at the packet core component and other network equipment of the communication network (Koral, par.45).
Chien teaches, similar system, wherein the application properties includes a list of ports, (Chien teaches that the process will at a minimum check the destination port against a white list of UDP ports, so that UDP communications are only allowed with respect to ports that are identified in the white list. In the outbound case, module 821 and/or 822 may also assure that UDP packets are only sent to destination addresses and/or ports that are allowable under a corresponding white list as Chien teaches in par.144) and wherein the detection of the attack comprises determining, by the protection program, whether a received packet specifies a port included in the list of ports (Chien teaches that if the IP address, port number, and category code matches those in the white list, the evaluation module may indicate a high security rating. If the IP address and port number match, but the category code does not match, the evaluation module may determine an intermediate security rating, and request a user instruction on how to proceed. If the IP address and port number do not match those in the white list, the evaluation module may determine a lowest security rating. The evaluation module and/or other applications can take different actions, depending on the security rating meaning Chien’s system can determine or identify port from list of ports as Chien teaches in par.73). It would have been obvious to one ordinary skill in the art before effective filling date to modify Bernstein to include packet specifies a port included in the list of ports as taught and suggested by Chien for the purpose of evaluating a questionable network communication whether an outbound or inbound network communication is allowable based on one or more factors or properties of the communication, including one or more of an IP address, a listening port, a geographic location, time of day, or the like and to only communicate with other devices that are identified in a white list of trusted computing systems (Chien, abstract).
Claim(s) 4-5, 13, and 17-18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bernstein et al (2018/0278639) in views of Koral et al (2023/0080679) and Chien (2018/0198796) as applied to claims above, and further in view of Rioux et al (2022/0215101).
For claims 4, and 17, Bernstein, as modified by Karol and Chien, teaches all the limitations as previously set forth except for wherein the application properties includes a list of transport protocols, and wherein the detection of the attack occurs in response to a determination, based on the inspection, that the received packet specifies a transport protocol not included in the list of transport protocols.
Rioux teaches, similar system, wherein the application properties includes a list of transport protocols, and wherein the detection of the attack occurs in response to a determination, based on the inspection, that the received packet specifies a transport protocol not included in the list of transport protocols (par.584). It would have been obvious to one ordinary skill in the art before effective filling date to modify Bernstein, as modified by Karol, to include the received packet specifies a transport protocol not included in the list of transport protocols as taught and suggested by Rioux in order to ensure that usable backups are always available, multifactor authentication for particular accounts may be utilized and accounts may be configured with the minimum privilege required to function, isolated recovery environments may be created and isolation may be monitored and enforced to ensure the integrity of the recovery environment, and so on (Rioux, par.584).
For claims 5, and 18, Bernstein, as modified by Karol and Chien, teaches all the limitations as previously set forth except for wherein the application properties includes a list of target subnets, and wherein the detection of the attack occurs in response to a determination, based on the inspection, that the received packet specifies a target subnet not included in the list of target subnets.
Rioux further teaches wherein the application properties includes a list of target subnets, and wherein the detection of the attack occurs in response to a determination, based on the inspection, that the received packet specifies a target subnet not included in the list of target subnets (One or more of the monitoring programs 510a, 510b, 510n may detect 702 that the application is preparing to take an undesirable action as Rioux explains in par.634 and par.635). It would have been obvious to one ordinary skill in the art before effective filling date to modify Bernstein, as modified by Karol and Chien, to includes a list of target subnets, and wherein the detection of the attack occurs in response to a determination as taught and suggested by Rioux in order to ensure that usable backups are always available, multifactor authentication for particular accounts may be utilized and accounts may be configured with the minimum privilege required to function, isolated recovery environments may be created and isolation may be monitored and enforced to ensure the integrity of the recovery environment, and so on (Rioux, par.584).
For claims 13, Bernstein, as modified by Karol and Chien, teaches all the limitations as previously set forth except for wherein the protection program is an extended Berkley Packet Filter (eBPF).
Rioux further teaches wherein the protection program is an extended Berkley Packet Filter (eBPF) (one or more extended Berkeley Packet Filter (‘eBPF’) programs that may be attached to various tracepoints as Rioux explains in par.624). It would have been obvious to one ordinary skill in the art before effective filling date to modify Bernstein, as modified by Karol and Chien, to includes extended Berkley Packet Filter (eBPF) as taught and suggested by Rioux in order to monitor different things at different points in the application's execution (Rioux, par.624).
Claim(s) 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bernstein et al (2018/0278639) in views of Koral et al (2023/0080679) and Chien (2018/0198796) as applied to claims above, and further in view of Manuilov et al (10318272).
Bernstein, as modified by Karol and Chien, teaches all the limitations as previously set forth except for wherein the one or more application properties includes a list of approved modifications to the application, wherein the detection of the attack on the application occurs in response to detection of a modification to the application not included in the list of approved modifications, and wherein the mitigation action includes blocking the modification to the application not included in the list of approved modifications.
Manuilov teaches, similar system, wherein the one or more application properties includes a list of approved modifications to the application (col.12, lines 6-24), wherein the detection of the attack on the application occurs in response to detection of a modification to the application not included in the list of approved modifications (col.12, lines 43-68), and wherein the mitigation action includes blocking the modification to the application not included in the list of approved modifications (col.13, lines 1-16). It would have been obvious to one ordinary skill in the art before effective filling date to modify Bernstein, as modified by Karol, to includes wherein the mitigation action includes blocking the modification to the application not included in the list of approved modifications as taught and suggested by Manuilov in order to locating the portion of network activity that reveals how to manually update the instance of the previous version of the target application, a security action to protect a user from a candidate security threat (Manuilov, abstract).
Claim(s) 8-10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bernstein et al (2018/0278639) in views of Koral et al (2023/0080679) and Chien (2018/0198796) as applied to claims above, and further in view of Hayashi (2018/0034733).
For claim 8, Bernstein, as modified by Karol and Chien, teaches all the limitations as previously set forth except for wherein the detection of the attack on the application occurs in response to a detection of receiving a number packets within a time period that exceeds a threshold, and wherein the mitigation action includes blocking one or more packets received within the time period.
Hayashi teaches, similar system, wherein the detection of the attack on the application occurs in response to a detection of receiving a number packets within a time period that exceeds a threshold, and wherein the mitigation action includes blocking one or more packets received within the time period (par.43 and par.57). It would have been obvious to one ordinary skill in the art before effective filling date to modify Bernstein, as modified by Karol, to includes wherein the mitigation action includes blocking the modification to the application not included in the list of approved modifications as taught and suggested by Hayashi in order to execute a program which are robust against a large amount of accesses (Hayashi, par.24).
For claim 9, Bernstein, as modified by Karol and Chien, teaches all the limitations as previously set forth except for wherein the detection of the attack on the application occurs in response to a detection of receiving a number packets having a predetermined destination and source within a time period that exceeds a threshold.
Hayashi further teaches wherein the detection of the attack on the application occurs in response to a detection of receiving a number packets having a predetermined destination and source within a time period that exceeds a threshold (par.43 and par.61). It would have been obvious to one ordinary skill in the art before effective filling date to modify Bernstein, as modified by Drozd, to includes receiving a number packets having a predetermined destination and source within a time period that exceeds a threshold as taught and suggested by Hayashi in order to execute a program which are robust against a large amount of accesses (Hayashi, par.24).
For claim 10, Bernstein, as modified by Karol and Chien, teaches all the limitations as previously set forth except for wherein the detection of the attack on the application occurs in response to a detection of receiving a number packets having a predetermined protocol type within a time period that exceeds a threshold.
Hayashi further teaches wherein the detection of the attack on the application occurs in response to a detection of receiving a number packets having a predetermined protocol type within a time period that exceeds a threshold (par.46 and par.57). It would have been obvious to one ordinary skill in the art before effective filling date to modify Bernstein, as modified by Karol, and Chien, to includes receiving a number packets having a predetermined destination and source within a time period that exceeds a threshold as taught and suggested by Hayashi in order to execute a program which are robust against a large amount of accesses (Hayashi, par.24).
Claim(s) 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bernstein et al (2018/0278639) in views of Koral et al (2023/0080679) and Chien (2018/0198796) as applied to claims above, and further in view of Martinez et al (2018/0131724).
Bernstein, as modified by Karol and Chien, teaches all the limitations as previously set forth except for removing the protection program in response to a determination the application is removed.
Martinez teaches, similar system, removing the protection program in response to a determination the application is removed (removing the firewall rules when the application or computer workload is removed or stopped as Martinez teaches in par.93). It would have been obvious to one ordinary skill in the art before effective filling date to modify Bernstein, as modified by Karol and Chien, to includes removing the protection program in response to a determination the application is removed as taught and suggested by Martinez in order to perform the computer workload are automatically and simultaneously applied to multiple firewalls within and outside the security zone assigned to the application (Martinez, par.93).
Response to Amendments/Arguments
Applicant’s arguments with respect to claim(s) 1-20 have been 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.
The applicant’s arguments regarding new amendment limitations in claims 1, 14 and 20, has been considered but is moot, because the examiner applied new art, Koral et al (2023/0080679), that covers newly claimed limitation.
Regarding dependent claims arguments, said arguments are moot because the applied references are not considered to have alleged differences, and therefore are considered to properly show that for which they were cited.
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 AYUB A MAYE whose telephone number is (571)270-5037. The examiner can normally be reached Monday-Friday 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, SHEWAYE GELAGAY can be reached at 571-272-4219. 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.
/AYUB A MAYE/Examiner, Art Unit 2436
/SHEWAYE GELAGAY/Supervisory Patent Examiner, Art Unit 2436