DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This action is responsive to communication received on 03/13/2026. Claims 1-20 are pending of which claims 1, 6, 7, 14, 15, 17,18 and 20 are amended.
The Examiner recommends filing a written authorization for Internet communication in response to the present action. Doing so permits the USPTO to communicate with Applicant using Internet email to schedule interviews or discuss other aspects of the application. Without a written authorization in place, the USPTO cannot respond to Internet correspondence received from Applicant. The preferred method of providing authorization is by filing form PTO/SB/439, available at: https://www.uspto.gov/patent/forms/forms. See MPEP § 502.03 for other methods of providing written authorization.
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, 7-13, 15 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Cudak US 2017/0104789 and further in view of Bubshait US 2024/0143781, Griffin US 2024/0095215 and HamiltonII US 2016/0232024.
Regarding claims 1, 15 and 18, Cudak teaches an apparatus, non-transitory CRM executed by a processing device and method comprising: at least one processing device comprising a processor coupled to a memory; the at least one processing device being configured to implement a system management node of a distributed processing system (computing system to manage workload execution on a network where management include handling vulnerabilities, in a distributed cloud comping system ¶s15,16, 50)
[0015] FIG. 1 illustrates a system 100 configured to assign workloads based on known updates and/or security vulnerabilities, according to one embodiment. The networked system 100 includes a computer 102. The computer 102 may also be connected to other computers via a network 130. In at least one embodiment, the system 100 depicts a computing cluster comprising the computer 102 and a plurality of compute nodes 150. In general, the network 130 may be a telecommunications network and/or a wide area network (WAN). In a particular embodiment, the network 130 is the Internet.
[0016] The computer 102 generally includes a processor 104 which obtains instructions and data via a bus 120 from a memory 106 and/or a storage 108. The computer 102 may also include one or more network interface devices 118, input devices 122, and output devices 124 connected to the bus 120. The computer 102 is generally under the control of an operating system (not shown). Examples of operating systems include the UNIX operating system, versions of the Microsoft Windows operating system, and distributions of the Linux operating system. (UNIX is a registered trademark of The Open Group in the United States and other countries. Microsoft and Windows are trademarks of Microsoft Corporation in the United States, other countries, or both. Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both.) More generally, any operating system supporting the functions disclosed herein may be used. The processor 104 is a programmable logic device that performs instruction, logic, and mathematical processing, and may be representative of one or more CPUs. The network interface device 118 may be any type of network communications device allowing the computer 102 to communicate with other computers via the network 130
[0051] Computer system/server 12 may be described in the general context of computer system-executable instructions, such as program modules, being executed by a computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, and so on that perform particular tasks or implement particular abstract data types. Computer system/server 12 may be practiced in distributed cloud computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed cloud computing environment, program modules may be located in both local and remote computer system storage media including memory storage devices.
to determine by the distributed processing system, node security information characterizing one or more security issues encountered on one or more of a plurality of endpoint nodes of the distributed processing system(system determines if security vulnerability exists in compute nodes to which a fix/update may be required, ¶21)
the one or more security issues comprising at least one security issue resulting from a set of one or more workloads executing on one or more of the plurality of endpoint nodes on behalf of one or more requesting host devices(security vulnerabilities and other issues corresponding to workloads that will be executed on nodes are determined to identify updates needed and route workloads, ¶21)
[0021] For example, the compliance rules 116 may specify the most current versions of software and/or firmware. If the management application 112 determines that a compute node 150 is not running the most current version of the software, the management application 112 may perform predefined operations to delay or obviate the need to install an update to the software so that the compliance rules 116 are satisfied. As another example, the compliance rules 116 may specify security vulnerabilities, threats, loopholes, and the like, which may require a software update 117 to be fixed. If a given compute node 150 has not received the corresponding software update 117, the management application 112 may determine that the compute node 150 violates the compliance rule 116, and the management application 112 may attempt to orchestrate installation of the software update according to the techniques described herein. As another example, the compliance rules 116 may identify hardware components that are not acceptable for use in the compute nodes 150. For example, a network adapter may be known to cause data corruption. If a compute node 150 includes the offending network adapter, the management application 112 may disable the offending network adapter so that it does not corrupt any more data. In addition, if an update for the network adapter is in the software updates 117, the management application 112 may adjust the deployment of virtual machines 113 and/or workloads 114 such that the offending network adapter is not used until the software update 117 is applied. Generally, the compliance rules 116 may specify any number and type of rules that are associated with one or more software updates 117. The compliance rules 116 may also specify corresponding operations that the management application 112 may perform to cause the compute nodes 150 to come into compliance with a given compliance rule 116.
to apply, to the first endpoint node, the first set of one or more corrective action(schedule the update/patch to fix the system , ¶21);
and to apply the second set of one or more corrective actions by deploying at least one additional endpoint node in the distributed processing system, the at least one additional endpoint node not being subject to the identified second type of the one or more security issues encountered on the second endpoint node(migrate workload to nodes with components not affected by the need for update/patch, ¶25)
[0021] For example, the compliance rules 116 may specify the most current versions of software and/or firmware. If the management application 112 determines that a compute node 150 is not running the most current version of the software, the management application 112 may perform predefined operations to delay or obviate the need to install an update to the software so that the compliance rules 116 are satisfied. As another example, the compliance rules 116 may specify security vulnerabilities, threats, loopholes, and the like, which may require a software update 117 to be fixed. If a given compute node 150 has not received the corresponding software update 117, the management application 112 may determine that the compute node 150 violates the compliance rule 116, and the management application 112 may attempt to orchestrate installation of the software update according to the techniques described herein. As another example, the compliance rules 116 may identify hardware components that are not acceptable for use in the compute nodes 150. For example, a network adapter may be known to cause data corruption. If a compute node 150 includes the offending network adapter, the management application 112 may disable the offending network adapter so that it does not corrupt any more data. In addition, if an update for the network adapter is in the software updates 117, the management application 112 may adjust the deployment of virtual machines 113 and/or workloads 114 such that the offending network adapter is not used until the software update 117 is applied. Generally, the compliance rules 116 may specify any number and type of rules that are associated with one or more software updates 117. The compliance rules 116 may also specify corresponding operations that the management application 112 may perform to cause the compute nodes 150 to come into compliance with a given compliance rule 116.
[0025] At step 230, described in greater detail with reference to FIG. 3, the management application 112 may perform a predefined operation to defer (and/or eliminate) the need to apply the software update to the first compute node. Generally, the management application 112 may perform any set of operations to ensure that the offending hardware and/or software is not used. For example, continuing with the previous example, if the operating system security fix is the required software update 117, the management application 112 may migrate workloads 114 associated with the first virtual machine 113 on the first compute node 150 to a virtual machine 113 on a second compute node. If, however, a second virtual machine 113 is not affected, the management application 112 may allow the second virtual machine 113 to continue execution on the first compute node 150 while the first virtual machine 113 is updated and rebooted. At step 240, the first compute node may continue executing at least one workload 114 without applying the software update. For example, a first workload 114 may be migrated to a second compute node 150 because the first workload 114 uses a component of the first compute node 150 that is targeted by a software update. However, a second workload 114 executing on the first compute node 150 may not be modified, as the second workload 114 may not use the component of the first compute node 150 that is targeted by the software update. At step 250, the management application 112 may optionally apply the software update to the first compute node.
and migrating at least one workload of the set of one or more workloads running on the second endpoint node to the at least one additional endpoint node(migrate workload to node that is not affected by the .
[0028] FIG. 4B reflects compute nodes 150.sub.1, 150.sub.2 after the management application 112 has caused the migration of workload 114.sub.2 to virtual machine 113.sub.2 of compute node 150.sub.2. As shown, virtual machine 113.sub.1 of compute node 150.sub.1 continues to execute workload 114.sub.1, but no longer executes 114.sub.2. The security update is still available, but has not been installed, allowing workload 114.sub.1 to continue to execute. However, since workload 114.sub.2 has been migrated to compute node 150.sub.2, the risk of not installing the upgrade is minimized, as workload 114.sub.1 does not use the affected component that has not been addressed by the security update. Advantageously, the security update may be installed at a later time. As shown, virtual machine 113.sub.2 now runs workloads 114.sub.2, 114.sub.3, and 114.sub.4. However, in one embodiment, the management application 112 may migrate one or both of workloads 114.sub.3 and 114.sub.4 to compute node 150.sub.1 (assuming neither workload 114.sub.3 nor workload 114.sub.4 uses the affected component of compute node 1500.
Cudak teaches performing a first set of actions( patch a vulnerability, ¶21) and a second set of actions(migrate workload to unaffected nodes, ¶26) but does not identifying the security issued by type. Thus Cudak does not teach; to identify, based at least in part on the determined node security information, a first type of the one or more security issues encountered on at least a first one of the plurality of endpoint nodes of the distributed processing system and a second type of the one or more security issues encountered on at least a second one of the plurality of endpoint nodes of the distributed processing system
the second type of the one or more security issues being associated with one or more designated components of the second endpoint node.
Bubshait in the same field of endeavor as the invention teaches a system for responding to network threats. Bubshait teaches to identify, based at least in part on the determined node security information, a first type of the one or more security issues encountered on at least a first one of the plurality of endpoint nodes of the distributed processing system and a second type of the one or more security issues encountered on at least a second one of the plurality of endpoint nodes of the distributed processing system(determine remediation type such patching the computer application, or a second remediation type disabling or preventing access to compute resources, ¶43)
[0043] In accordance with certain embodiments, the method 300 includes determining a type of the remediation to determine a remediation priority for a computer application. The type of remediation is an action to be performed to prevent ransomware from accessing system resources. Non-limiting examples of the type of remediation include patching the computer application, blocking the computer application, or another action that prevents ransomware from accessing system resources. Blocking the computer application may include disabling user access to the computer application until a patch is available, blocking the computer application from accessing system resources, or another action that prevents ransomware from accessing system resources. The method 300 includes determining a first type of remediation associated with a first computer application of the remediation prioritization report, determining a second type of remediation associated with a second computer application of the remediation prioritization report, and adjusting a first priority for the first computer application and a second priority for the second computer application based on the first type of remediation and the second type of remediation. The method 300 may adjust the first priority and the second priority before outputting the remediation prioritization report or may output a second remediation prioritization report with the adjusted priorities.
the second type of the one or more security issues being associated with one or more designated components of the second endpoint node(vulnerabilities that can affect an organization system components/applications, ¶15)
[0015] An embodiment in accordance with the present disclosure describes a method for analyzing ransomware threat intelligence to determine a risk level of one or more computer applications and generating a report that prioritizes the one or more computer applications in terms of remediation urgency. This method obtains data sets from different sources including results of security testing of computer applications, exploitability level for one or more vulnerabilities associated with the one or more computer applications, threat intelligence data feeds, impact scores related to organization specific criteria, or a combination thereof. The results of the security testing of the computer applications are generated by an application scanner (a security testing tool). The exploitability level indicates whether a vulnerability associated with a computer application is exploitable. A vulnerability, as used herein, refers to a flaw within a computer application that makes the computer application susceptible to a ransomware or other type of cyber attack or malware. Threat intelligence data feeds may include both internal feeds (i.e. from within an organization) and external feeds (i.e. from defined threats recognized by a global community). Impact score related to organization specific criteria may include, but are not limited to, parameters related to integrity, availability, confidentiality, other variables used by the organization, or and a combination thereof. Considering these data sources in determining the risk level enhances the accuracy of the generated report that prioritizes remediation of the organization's computer applications and their associated vulnerabilities in order to prevent ransomware or other attacks. Timely prioritization and remediation of vulnerabilities before they are utilized by malicious third parties to perform a ransomware attack enables increased utilization of the organization's system resources, which include networks, computer applications, and other associated system components, and reduces costs associated with mitigating damage done by ransomware attacks.
to select a first set of one or more corrective actions for the first type of the one or more security issues and a second set of one or more corrective actions for the second type of the one or more security issues(determine remediation type such one that that includes patching the computer application, or a second remediation type that includes disabling or preventing access to compute resources, ¶43).
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Cudak’s first action(patch) and second of action(migrate) with method of executing such action based on determining the remediation type that should be performed . The reason for this modification would be to implement a system that can more robustly handle vulnerabilities by patching systems or migrating workloads as another way to remediate a vulnerability until patch is available.
Cudak teaches each of the nodes in a distributed computing network contains a management application for manages software updates/patches. Cudak/Bubshait does not teach by the system management node of the distributed processing system performing the determine, identify, select and apply steps to other endpoint nodes. Griffin in the same field of endeavor as the invention teaches a system for software management in a distributed computing environment. Griffin teaches teach by the system management node of the distributed processing system performing the determine, identify, select and apply steps to other endpoint nodes(management node of a the managed nodes in a distributed computing environment analyzes the software on the managed nodes and determines software that need updates and deploys updated software)
[0012] The management node 104 can manage the nodes 110a-c in the distributed computing environment 100. Managing the nodes 110a-c can include authorizing updates for the nodes 110a-c, reviewing computing privileges for the nodes 110a-c, or other suitable administrative management. Additionally, the management node 104 can tabulate existing software versions for each node of the nodes 110a-c. The management node 104 can access the software repository 102 to compare the existing software versions executing on the nodes 110a-c with released software versions from the software repository 102. Using the released software versions, the management node 104 can determine that an existing software version on the second node 110b is outdated compared to the released software versions. The management node 104 can generate an update request 106 for updating the existing software version to the released software version. The update request 106 can include an update file 108 that can be used to update the second node 110b. The update file 108 can provide an update for a software package, an operating system, or other suitable computing service. In some examples, the management node 104 can receive the update request 106 including the update file 108 from the software repository 102.
It would have been obvious to a person of ordinary skill in the art before the effective filing of the invention to modify Cudak/Bubshait with implementing a centralized software management that uses management node to manage software updates on managed nodes of a distributed network as taught by Griffin. The reason for this modification would be to provide a simple substitution of self managed updates with a centralized software management variant.
The combination of Cudak/Bubshair/Griffin does not teach removing the second endpoint node from the distributed processing system. HamiltonII in the same field of endeavor as the invention teaches of system for security mitigation. HamiltonII teaches removing the second endpoint node from the distributed processing system(disconnect/isolate/quarantine system from network, ¶70).
[0070] In step 506, response module 406 isolates the affected VMs identified in step 502. In this embodiment, isolating the affected VMs involves sandboxing, quarantining, or otherwise disconnecting the affected VMs to advantageously help prevent the detected threat from affecting other VMs. In this manner, response module 406 can isolate affected VMs as a reactionary measure to help contain detected threats while subsequent processing is performed. Response module 406 can isolate the affected VMs from all VMs in the determined neighborhood, from all VMs in the computing environment, or from a specified combination of VMs. In another embodiment, response module 406 can isolate both the affected VMs and all VMs in the determined neighborhood from the remaining VMs in the computing environment.
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Cudak/Bubshait/Griffin with disconnecting/isolating a system from the network as taught by HamiltonII. The reason for this modification would be to provide protection to a network from by preventing nodes with vulnerabilities from execution of workloads susceptible to vulnerabilities.
Regarding claim 2, Cudak teaches wherein the at least one processing device comprises at least a portion of a control plane of the distributed processing system configured for communication with the plurality of endpoint nodes of the distributed processing system over one or more networks(system includes a management layer( i.e. control plane) for managing a cloud computing environment(i.e. distributed processing system), ¶s51,62).
[0051] Computer system/server 12 may be described in the general context of computer system-executable instructions, such as program modules, being executed by a computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, and so on that perform particular tasks or implement particular abstract data types. Computer system/server 12 may be practiced in distributed cloud computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed cloud computing environment, program modules may be located in both local and remote computer system storage media including memory storage devices.
[0062] In one example, management layer 64 may provide the functions described below. Resource provisioning provides dynamic procurement of computing resources and other resources that are utilized to perform tasks within the cloud computing environment. Metering and Pricing provide cost tracking as resources are utilized within the cloud computing environment, and billing or invoicing for consumption of these resources. In one example, these resources may comprise application software licenses. Security provides identity verification for cloud consumers and tasks, as well as protection for data and other resources. User portal provides access to the cloud computing environment for consumers and system administrators. Service level management provides cloud computing resource allocation and management such that required service levels are met. Service Level Agreement (SLA) planning and fulfillment provide pre-arrangement for, and procurement of, cloud computing resources for which a future requirement is anticipated in accordance with an SLA.
Regarding claim 3, Cudak teaches wherein at least a portion of the control plane is implemented in a distributed manner across two or more of the plurality of endpoint nodes of the distributed processing system( management systems implemented in a distributed cloud computing environment, ¶51).
[0051] Computer system/server 12 may be described in the general context of computer system-executable instructions, such as program modules, being executed by a computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, and so on that perform particular tasks or implement particular abstract data types. Computer system/server 12 may be practiced in distributed cloud computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed cloud computing environment, program modules may be located in both local and remote computer system storage media including memory storage devices.
Regarding claim 7, HamiltonII teaches removing the second endpoint node from the distributed processing system is performed responsive to a successful migration of the one or more workloads running on the second endpoint node to the at least one additional endpoint node(disconnect/isolate/quarantine system from network, ¶70).
[0070] In step 506, response module 406 isolates the affected VMs identified in step 502. In this embodiment, isolating the affected VMs involves sandboxing, quarantining, or otherwise disconnecting the affected VMs to advantageously help prevent the detected threat from affecting other VMs. In this manner, response module 406 can isolate affected VMs as a reactionary measure to help contain detected threats while subsequent processing is performed. Response module 406 can isolate the affected VMs from all VMs in the determined neighborhood, from all VMs in the computing environment, or from a specified combination of VMs. In another embodiment, response module 406 can isolate both the affected VMs and all VMs in the determined neighborhood from the remaining VMs in the computing environment.
Regarding claim 8, Bubshait teaches wherein the first type of the one or more security issues comprise security vulnerabilities associated with one or more patches(vulnerabilities associate with remediation type that can be patched, Bubshait ¶43).
[0025] At step 230, described in greater detail with reference to FIG. 3, the management application 112 may perform a predefined operation to defer (and/or eliminate) the need to apply the software update to the first compute node. Generally, the management application 112 may perform any set of operations to ensure that the offending hardware and/or software is not used. For example, continuing with the previous example, if the operating system security fix is the required software update 117, the management application 112 may migrate workloads 114 associated with the first virtual machine 113 on the first compute node 150 to a virtual machine 113 on a second compute node. If, however, a second virtual machine 113 is not affected, the management application 112 may allow the second virtual machine 113 to continue execution on the first compute node 150 while the first virtual machine 113 is updated and rebooted. At step 240, the first compute node may continue executing at least one workload 114 without applying the software update. For example, a first workload 114 may be migrated to a second compute node 150 because the first workload 114 uses a component of the first compute node 150 that is targeted by a software update. However, a second workload 114 executing on the first compute node 150 may not be modified, as the second workload 114 may not use the component of the first compute node 150 that is targeted by the software update. At step 250, the management application 112 may optionally apply the software update to the first compute node.
Regarding claim 9, Bubshait teaches wherein the first type of the one or more security issues comprise security vulnerabilities associated with at least a designated threshold criticality(remediation may have a prioritization with different risk levels, ¶39).
[0039] The system 100 may utilize remediation prioritizer 128 to calculate the order of remediation (i.e. the remediation priority) for one or more computer applications and generate the remediation prioritization report 110 based on the overall risk level for each computer application. A non-limiting example of the remediation prioritization report 110 is shown in Table 5 below.
Regarding claim 10, Bubshait teaches wherein the second type of the one or more security issues comprise security vulnerabilities for which there are no patches available(second remediation type action such a blocking access until a patch is available… implying that no patches are available for a time, ¶43).
[0043] In accordance with certain embodiments, the method 300 includes determining a type of the remediation to determine a remediation priority for a computer application. The type of remediation is an action to be performed to prevent ransomware from accessing system resources. Non-limiting examples of the type of remediation include patching the computer application, blocking the computer application, or another action that prevents ransomware from accessing system resources. Blocking the computer application may include disabling user access to the computer application until a patch is available, blocking the computer application from accessing system resources, or another action that prevents ransomware from accessing system resources. The method 300 includes determining a first type of remediation associated with a first computer application of the remediation prioritization report, determining a second type of remediation associated with a second computer application of the remediation prioritization report, and adjusting a first priority for the first computer application and a second priority for the second computer application based on the first type of remediation and the second type of remediation. The method 300 may adjust the first priority and the second priority before outputting the remediation prioritization report or may output a second remediation prioritization report with the adjusted priorities.
Regarding claim 11, Bubshait teaches wherein the first type of the one or more security issues comprise security vulnerabilities associated with a first criticality level and the second type of the one or more security issues comprise security vulnerabilities associated with a second criticality level, the second criticality level being different than the first criticality level(remediation may have a at least a first and second priority ¶43).
[0043] In accordance with certain embodiments, the method 300 includes determining a type of the remediation to determine a remediation priority for a computer application. The type of remediation is an action to be performed to prevent ransomware from accessing system resources. Non-limiting examples of the type of remediation include patching the computer application, blocking the computer application, or another action that prevents ransomware from accessing system resources. Blocking the computer application may include disabling user access to the computer application until a patch is available, blocking the computer application from accessing system resources, or another action that prevents ransomware from accessing system resources. The method 300 includes determining a first type of remediation associated with a first computer application of the remediation prioritization report, determining a second type of remediation associated with a second computer application of the remediation prioritization report, and adjusting a first priority for the first computer application and a second priority for the second computer application based on the first type of remediation and the second type of remediation. The method 300 may adjust the first priority and the second priority before outputting the remediation prioritization report or may output a second remediation prioritization report with the adjusted priorities.
Regarding claim 12, Cudak teaches wherein the second type of the one or more security issues comprise security vulnerabilities which are rooted in one or more designated components of the second endpoint node(vulnerability rooted in a system or software component such as an operating system, ¶24).
[0024] FIG. 2 illustrates a method 200 to assign workloads based on software updates, according to one embodiment. Generally, the steps of the method 200 provide techniques to defer or eliminate the need to install software updates upon receipt. As shown, the method 200 begins at step 210, where the management application 112 may receive an indication of a software update, security vulnerability, or other required software upgrade in the software updates 117. In at least one embodiment, a user may provide the indication. In response, the management application 112 may reference metadata associated with the software updates 117 to identify a component of the computing system targeted by the software update 117. For example, a first software update 117 may target a security vulnerability in an operating system, while a second software update 117 may target flawed firmware of a hardware component. At step 220, the management application 112 may determine that a first compute node violates a compliance rule related to the software update (or security vulnerability). For example, if a critical security fix is received for an operating system, the management application 112 may determine that the operating system of a first virtual machine 113 executing on the first compute node has not been updated based on metadata associated with the operating system provided by the hypervisor 121 managing the first virtual machine. In at least one embodiment, the management application 112 may maintain a database of all installed software and hardware components of each compute node 150 in the storage 108, thereby facilitating the determination as to which components violate compliance rules 116.
Regarding claim 13, Cudak teaches wherein the one or more designated components comprise an operating system architecture of the second endpoint node(vulnerability rooted in a system or software component such as an operating system, ¶24).
[0024] FIG. 2 illustrates a method 200 to assign workloads based on software updates, according to one embodiment. Generally, the steps of the method 200 provide techniques to defer or eliminate the need to install software updates upon receipt. As shown, the method 200 begins at step 210, where the management application 112 may receive an indication of a software update, security vulnerability, or other required software upgrade in the software updates 117. In at least one embodiment, a user may provide the indication. In response, the management application 112 may reference metadata associated with the software updates 117 to identify a component of the computing system targeted by the software update 117. For example, a first software update 117 may target a security vulnerability in an operating system, while a second software update 117 may target flawed firmware of a hardware component. At step 220, the management application 112 may determine that a first compute node violates a compliance rule related to the software update (or security vulnerability). For example, if a critical security fix is received for an operating system, the management application 112 may determine that the operating system of a first virtual machine 113 executing on the first compute node has not been updated based on metadata associated with the operating system provided by the hypervisor 121 managing the first virtual machine. In at least one embodiment, the management application 112 may maintain a database of all installed software and hardware components of each compute node 150 in the storage 108, thereby facilitating the determination as to which components violate compliance rules 116.
Claims 4, 5, 16 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Cudak/Bubshait/Griffin/HamiltonII as applied to claims 1, 15 and 18 above, and further in view of Thakore US 11,916,775.
Regarding claims 4, 16 and 19, Cudak/Bubshait/Griffin/HamiltonII does not teach wherein the distributed processing system comprises a software-defined storage system, and wherein the plurality of endpoint nodes comprise respective software-defined storage server nodes of the software-defined storage system. Thakore in the same field of endeavor teaches a system for implementing and management of cloud based multi-tenant services. Thakore teaches wherein the distributed processing system comprises a software-defined storage system, and wherein the plurality of endpoint nodes comprise respective software-defined storage server nodes of the software-defined storage system.
[The software-defined data center layer 825 may provide resource pooling, usage tracking, and governance on top of the hypervisor layer 830. The software-defined data center layer 825 may enable the creation of virtualization for the Infrastructure-as-Code concept by using representational state transfer (REST) Application Programming Interfaces (APIs). The management of block storage devices may be virtualized, and end users may be provided with a self-service API to request and consume those resources without requiring any knowledge of where the storage is deployed or on what type of device. Various compute nodes may be balanced for storage.
The image layer 820 may use various operating systems and other pre-installed software components. Patch management may be used to identify, acquire, install, and verify patches for products and systems. Patches may be used to correct security and functionality problems in software. Patches may also be used to add new features to operating systems, including security capabilities. The image layer 820 may focus on the compute instead of storage and networking. The instances within the cloud computing environments may be provided at the image layer 820. Col 12 Line 59- Col 13 Line 13]
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Cudak/Bubshait/Griffin/HamiltonII’s cloud based service network a software defined data center(i.e. storage) as taught by Thakore. The reason for this modification would be to implement storage services for a cloud computing based network that provide more efficiency and ease of deployment.
Regarding claim 5, Cudak further teaches wherein migrating the one or more workloads comprises migrating data stored on the second endpoint node to the at least one additional endpoint node(migrate workload to nodes with components not affected by the need for update/patch, ¶25).
Claims 6, 17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Cudak/Bubshait/Griffin/HamiltonII as applied to claims 1, 15 and 18 above, and further in view of Patil US 2017/0250855.
Regarding claim 6, 17 and 20, Cudak/ teaches wherein the system management node provides at least a portion of a multi-cloud orchestration layer of the cloud-based processing system(Cudak, ¶21 management agent implements function of an orchestration layer managing software/update deployment on nodes)
[0021] For example, the compliance rules 116 may specify the most current versions of software and/or firmware. If the management application 112 determines that a compute node 150 is not running the most current version of the software, the management application 112 may perform predefined operations to delay or obviate the need to install an update to the software so that the compliance rules 116 are satisfied. As another example, the compliance rules 116 may specify security vulnerabilities, threats, loopholes, and the like, which may require a software update 117 to be fixed. If a given compute node 150 has not received the corresponding software update 117, the management application 112 may determine that the compute node 150 violates the compliance rule 116, and the management application 112 may attempt to orchestrate installation of the software update according to the techniques described herein. As another example, the compliance rules 116 may identify hardware components that are not acceptable for use in the compute nodes 150. For example, a network adapter may be known to cause data corruption. If a compute node 150 includes the offending network adapter, the management application 112 may disable the offending network adapter so that it does not corrupt any more data. In addition, if an update for the network adapter is in the software updates 117, the management application 112 may adjust the deployment of virtual machines 113 and/or workloads 114 such that the offending network adapter is not used until the software update 117 is applied. Generally, the compliance rules 116 may specify any number and type of rules that are associated with one or more software updates 117. The compliance rules 116 may also specify corresponding operations that the management application 112 may perform to cause the compute nodes 150 to come into compliance with a given compliance rule 116.
Cudak/Bubshait/Griffin/HamiltonII do not teach wherein the distributed processing system comprises a cloud-based processing system, and wherein the plurality of endpoint nodes comprise respective cloud endpoint nodes operating on one or more clouds of one or more cloud service providers. Patil in the same field of endeavor as the invention teaches a system for anomaly detection and software patching. Patil teaches wherein the distributed processing system comprises a cloud-based processing system, and wherein the plurality of endpoint nodes comprise respective cloud endpoint nodes operating on one or more clouds of one or more cloud service providers(cloud services provided by multiple ISPs, ¶s17,21).
[0017] FIG. 1 illustrates an example environment 100 for implementing an anomaly detection system for an online service that utilizes telemetry data. In the environment 100, a first user 102(1) and a second user 102(2) (collectively “users 102”) represent a plurality of users 102 that can utilize respective client computing devices 104(1) and 104(2) (collectively “client computing devices 104”) to access one or more servers 106(1), 106(2), . . . , 106(N) (collectively “server(s) 106”) of a data center 108 that provides one or more online services 110. The online service(s) 110 can include, without limitation, a personal information management (PIM) service, such as an email service, a web-hosting service, a storage service, a virtual machine service, a business productivity service, an entertainment service (e.g., a music service, a video service, a gaming service, etc.), a personal productivity service (e.g., a travel service), a social networking service, or any similar cloud-based service.
[0021] The environment 100 is further shown as including a first Internet service provider (ISP) 120(1) and a second ISP 120(2) (collectively “ISPs 120”). The ISPs 120 represent a plurality of ISPs 120 that can be involved in enabling access of users 102 to the online service(s) 110. That is, each ISP 120 can represent a third party entity (or operator) that provides services to users for accessing, using, or participating in the Internet, and although two ISPs 120(1) and 120(2) are shown in FIG. 1, it is to be appreciated that any number of ISPs 120 can be involved in the network topology on which the online service(s) 110 is implemented.
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Cudak/Bubshait with implementing the vulnerability remediation system in a cloud environment with a cloud environment provided by multiple ISPs. The reason for this modification would be to provide vulnerability remediation to cloud computing environments that comprise multiple different ISPs, where cloud computing is commonly provided my multiple differing providers.
Claims 14 is rejected under 35 U.S.C. 103 as being unpatentable over Cudak/Bubshait Cudak/Bubshait/Griffin/HamiltonII as applied to claim 1 above, and further in view of Patin US 2016/0065656.
Regarding claim 14, Patil does not teach wherein the first set of one or more corrective actions are applied non-disruptively to the first endpoint node without affecting at least one workload running on the first endpoint node. Patin in the same field of endeavor as the invention teaches a for managing SDN based networks. Patin teaches wherein the first set of one or more corrective actions are applied non-disruptively to the first endpoint node without affecting at least one workload running on the first endpoint node.
[0091] In certain embodiments, the Distributed Control Nodes can be adapted to allow for online patching of software and/or firmware without impact to the I/O Level, Control Level or Operations Level. Patching, including Firmware Patching, has become a routine task, as patching is the most effective method for removing a known vulnerability. The system can thus allow for patches to be delivered, installed, and placed into effect securely and without downtime.
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Patil with a system for live software patching as taught by Patin. The reason for this modification would be to patch OS and other software type patches on live systems without need for system downtime do you reboot/restart needed for patching.
Applicant Remarks
Applicant’s arguments with respect to claims 1-20 have been considered but are moot because the new ground of rejection responsive to amendments do not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Tom Y. Chang whose telephone number is 571-270-5938. The examiner can normally be reached on Monday-Friday from 9am to 5pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Emmanuel Moise, can be reached on (571)272-3865. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/TOM Y CHANG/
Primary Examiner, Art Unit 2455
Prosecution Insights