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 .
DETAILED ACTION
This office action is responsive to Applicant’s reply filed on 04/09/2026.
Claims 1 – 20 are pending; wherein claims 1 – 5, 8 – 12, 15 – 17, and 19 – 20 have been amended.
Response to Amendment
Objection for abstract is withdrawn in view of Applicant’s amendments.
Claim objections for claims 2 – 5, 7, 9 – 12, 14, and 17 – 20 are withdrawn in view of Applicant’s amendments.
Claim Interpretation
112(f) interpretation for “a processing device” in claim 8 is maintained.
Response to Arguments
Applicants’ arguments dated 04/09/2026 with respect to claims 1 – 20 have been considered but are moot in view of the new ground(s) of rejection as necessitated by amendments.
Regarding 101 rejections, Applicant argues that “… However, claim 1, as amended, recites ‘wherein the custom controller performs one or more operations to synchronize an actual state of the at least one provisioned resource at the at least one node to a target state of the at least one provisioned resource specified by the custom resource definition, and wherein each operation of the one or more operations includes provisioning a dependent resource.’ Applicant respectfully notes that performing operations to synchronize resource states at nodes of a remote data center cannot be performed mentally. These are technical operations that require automated computer processing to provision and deploy computing resources. Therefore, for at least this reason, the eligibility analysis should end at the first prong of Revised Step 2A.” (Remark; p. 12: first full paragraph.)
Examiner agrees that synchronization of resource state cannot be performed mentally. However, the synchronization is just data update operation. Such operation is conventional technology that allows data to be updated and is insignificant extra-solution activity. Therefore, the synchronization is not indicative of an integration into a practical application. In other words, 35 USC 101 rejections for claims 1 – 20 remain.
Specification
The specification is objected to as failing to provide proper antecedent basis for the claimed subject matter. See 37 CFR 1.75(d)(1) and MPEP § 608.01(o). Correction of the following is required:
Claim 17 recites feature “a policy engine server”, which is not supported by the specification.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1 – 20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Claim 1
Step 1
The claim is statutory because it is directed to a method.
Step 2A, prong 1
The claim recites limitations
“identifying … one or more provisioned resources of a plurality of nodes of a remote data center;
for at least one provisioned resource of the one or more provisioned resources, identifying … an available update of the at least one provisioned resource based at least on a resource graph associated with the at least one provisioned resource …”
These limitations directed to concept of collecting and recognition of data (Smart Systems Innovations, LLC v. Chicago Transit Authority; 873 F.3d 1364, 124 U.S.P.Q.2d 1441 (Fed Cir. 2017)). This concept is reasonably performed mentally through human observation and evaluation to identify provisioned resources and identify available update from observation of resource graph. Thus, these limitations are directed to a mental process.
Step 2A, prong 2
The claim recites additional limitations “responsive to identifying the available update, providing … a custom resource definition associated with the available update of the at least one provisioned resource … to update at least one node of the plurality of nodes of the data center … synchronize an actual state of the at least one provisioned resource at the at least one node to a target state of the at least one provisioned resource at the at least one node …”
The additional limitations amount to an insignificant extra-solution activity because they amount to general post-solution activity to provide a custom resource definition a node and update resource and its state.
The claim further recites additional elements “a client-side update component and a custom controller.” The additional elements are recited as high level of generality and used as a tool to perform the limitations.
Thus, the additional limitations and the additional elements are not indicative of an integration into a practical application.
Steps 2B
The claim as a whole is not amounted to significantly more than the judicial exception. Claim 1 is directed to an abstract idea and is not patent eligible.
Analyses of claims 2 – 6 as follow:
Claim 2
The claim recites limitations “periodically querying … a policy engine of a server-side update component of the update framework to obtain the resource graph …; returning … the resource graph associated with the at least one provisioned resource …”
The limitations, as drafted, query and return data. Thus, the limitations, under its broadest reasonable interpretation, are an insignificant extra-solution activity, and elements “policy engine and a server-side update component” are tools to perform the limitations. Thus, the limitations and elements are not integrated into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Claim 3
The claim recites limitations “requesting … the resource graph … from a graph builder of the client-side update component based on one or more release pointers…;
applying … one or more policy definitions to the resource graph; and
providing … the resource graph to the client-side component”
The limitations, as drafted, request the resource graph, apply policy definition to the resource graph, and provide the resource graph. Thus, the limitations, under its broadest reasonable interpretation, are an insignificant extra-solution activity. Thus, the limitations are not integrated into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Claim 4
The claim recites limitations “retrieving one or more release pointers …; and
generating the resource graph by linearly ordering … the retrieved one or more release pointers …”
The limitations, as drafted, retrieve the release pointer, which is an insignificant extra-solution activity, and generate the source graph, which is reasonably created mentally by human with an aide of paper and pen. Thus, the limitations are not integrated into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Claim 5
The claim recites limitations “identifying a current version of the at least one provisioned resource;
locating the current version of the at least one provisioned resource in the resource graph …; and
identifying a subsequent version of the at least one provisioned resource in the resource graph after the current version of the at least one provisioned resource.”
The limitations, as drafted, identify and locate version of the provisioned resource, which are reasonably performed mentally by human observation and evaluation of data. Thus, the limitations are not integrated into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Claim 6
The claim recites limitations “the client-side update component is instantiated using one or more remote Kubernetes clusters of the remote data center.”
The limitations, as drafted, generate the client-side update component, which is an insignificant extra-solution activity. Thus, the limitations are not integrated into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Claim 7
The claim recites limitations “the server-side update component is separate from the remote data center.”
The limitations, as drafted, further separate the server-side update component, which is an insignificant extra-solution activity. Thus, the limitations are not integrated into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Claim 8
The claim is statutory because it is directed to a system.
The claim recites limitation in the same manner as claim 1; therefore, it is rejected for the same reasons.
Furthermore, the claim recites additional element “a processing device.” The additional element is recited as high level of generality and used as a tool to perform the limitations. Thus, the additional element is not indicative of an integration into a practical application.
Claims 9 – 14
Claims 9 – 14 recite limitations in the same manner as claims 2 – 7 respectively; therefore, claims 9 – 14 are also rejected for the same reasons.
Claim 15
Step 1
The claim is statutory because it is directed to a device.
Step 2A, prong 1
The claim recites limitations “…periodically check for updates of one or more resources of a remote data center ...”
These limitations directed to concept of collecting and recognition of data (Smart Systems Innovations, LLC v. Chicago Transit Authority; 873 F.3d 1364, 124 U.S.P.Q.2d 1441 (Fed Cir. 2017)). This concept is reasonably performed mentally through human observation and evaluation to check and identify available update. Thus, the limitations are directed to a mental process.
Step 2A, prong 2
The claim recites additional limitations “perform over-the-air (OTA) updates to the one or more resources … synchronize an actual state of the provisioned resource to a target state of the provisioned resource … provisioning a dependent resource.”
The additional limitations amount to an insignificant extra-solution activity because they amount to general post-solution activity to provide a custom resource definition a node and update resource and its state.
The claim further recites additional elements “one or more processors.” The additional elements are recited as high level of generality and used as a tool to perform the limitations.
Thus, the additional limitations and the additional elements are not indicative of an integration into a practical application.
Steps 2B
The claim as a whole is not amounted to significantly more than the judicial exception. Claim 15 is directed to an abstract idea and is not patent eligible.
Analysis of claims 16 – 20
Claim 16
The claim recites limitations “the update framework comprises a combination of one or more client-side components and one or more server-side components.”
The limitations, as drafted, define the framework, which is an insignificant extra-solution activity. Thus, the limitations are not integrated into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Claim 17
The claim recites limitations “the client-side components comprise at least one of:
a cluster version operator (CVO) to perform periodic checks for updates from a policy engine server; or
a second-level operator (SLO) to perform service updates.”
The limitations, as drafted, define functionalities of the client-side components, which is an insignificant extra-solution activity. Thus, the limitations are not integrated into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Claim 18
The claim recites limitations “the CVO is instantiated using one or more remote Kubernetes clusters.”
The limitations, as drafted, instantiate the CVO, which is an insignificant extra-solution activity. Thus, the limitations are not integrated into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Claim 19
The claim recites limitations “the server-side components comprise at least one of:
a policy engine to query a container artifact repository for one or more release pointers …; or
a graph builder to generate one or more directed graphs …”
The limitations, as drafted, define functionalities of the server-side components, which is an insignificant extra-solution activity. Thus, the limitations are not integrated into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Claim 20
The claim recites limitations “the client-side components communicate with the server-side components via a side car container of the server-side components.”
The limitations, as drafted, further define functionalities of the client-side components, which is an insignificant extra-solution activity. Thus, the limitations are not integrated into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1 – 5, 7 – 12, 14 – 17, and 19 – 20 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Sun et al. (Patent No. US 11,119,754 B1; hereinafter Sun.)
Claim 1
Sun teaches a method comprising:
identifying, using a client-side update component, one or more provisioned resources of a plurality of nodes of a remote data center (Sun; Fig. 2; col. 4: 37 – 49; At 202, the method includes selecting an update path for updating a system component (provisioned resource) of the host device (node) based on a multi-stage combination of hashes corresponding to versions of updates of the system component. For example, as described above, versions of the system component (provisioned resource), starting with an initial version of the system component (provisioned resource) that is currently included in the host device and ending with a targeted version of the system component (provisioned resource) to which the system component of the host device is to be updated, may be iteratively combined …;
Fig. 2; col. 4: 32 – 54; method 200 may be performed in order to update the host device 104 of FIG. 1 and may be performed by the user/management device 102 (client-side component) and/or the update management system 106 (client-side component) of FIG. 1 …;
Fig. 1; col. 3: 13 – 23; For example, the update management system 106 (client-side update component) may utilize information about a current state of the host device 104 (e.g., a sequence number and/or a payload hash for a current version of the sub-component on the host device) (provisioned resource) …
Col. 2: 27 – 44; … the following description will largely reference updating a single system component for a single host device, however, it is to be understood that the described systems and processes may be implemented in order to coordinate the updating of multiple system components and/or multiple host systems (nodes), such as a fleet of servers in a network (e.g., a compute service provider network) and/or an on-premises data center …);
for at least one provisioned resource of the one or more provisioned resources, identifying, using the client-side component, an available update of the at least one provisioned resource based at least on a resource graph associated with the at least one provisioned resource, the resource graph depicting one or more update paths of the at least one provisioned resource (Sun; Fig. 2; col. 4: 32 – 54; method 200 may be performed in order to update the host device 104 of FIG. 1 and may be performed by the user/management device 102 (client-side component) and/or the update management system 106 (client-side component) of FIG. 1. At 202, the method includes selecting an update path for updating a system component of the host device based on a multi-stage combination of hashes corresponding to versions of updates of the system component. For example, as described above, versions of the system component, starting with an initial version of the system component (provisioned resources) that is currently included in the host device and ending with a targeted version of the system component to which the system component of the host device is to be updated, may be iteratively combined ...
At 204, the method includes generating an update manifest including a plurality of update payloads from the selected update path …
Fig. 1; col. 2: 53 – col. 3: 3; … Further, for each host, the update payloads that are appropriate for the host devices may be based off of loaded firmware versions (provisioned resources) of the host devices (nodes), the host device's uptime, and/or the age of the firmware on the host device … This increases the effort on a backend service (e.g., an update management service, such as update management system 106) (client-side component), which is used to tell the host device the feasible update path and associated payloads. In order to address this complexity, the directed graphs 110 (resource graph) are continuously updated as new updates are received from the update source(s) 112 in order to maintain a navigable resource for identifying an update path for a current state of a host device and generating payloads for updating the host device according to the identified update path …
Col. 2: 45 – 50; The update management system 106 may include an update path builder 108 configured to build, update, and manage one or more directed graphs (resource graph) of update paths 110 using version information of updates to one or more system components for the host devices 104); and
responsive to identifying the available update, providing, using the client-side component, a custom resource definition associated with the available update of the at least one provisioned resource to a custom controller associated with the at least one provisioned resource to update at least one node of the plurality of nodes of the data center using the available update of the at least one provisioned resource (Sun; Fig. 2; col. 4: 50 – 62; At 204, the method includes generating an update manifest (custom resource definition) including a plurality of update payloads from the selected update path …
At 206, the method includes uploading the plurality of update payloads to the host device to cause the host device to update the system component …
Col. 6: 30 – 31; FIG. 5 is a flow chart of an example method 500 for updating a host device and verifying the update
Col. 6: 46 – 48; … The secure connection may allow the user/management device to securely upload an update manifest and payload files to the network cards storage, as indicated at 506 …
Col. 6: 60 – 64; … the host device may perform a first check to ensure that the sequence number of the update payloads in the update manifest (custom resource definition) are greater than or equal to a current sequence number of a current version of the component to be updated, as indicated at 510 …
Col. 7: 26 – 28; This process may be performed in order to cause the processor to complete the update process using the payload data loaded in system memory.), wherein the custom controller performs one or more operations to synchronize an actual state of the at least one provisioned resource at the at least one node to a target state of the at least one provisioned resource at the at least one node specified by the custom resource definition (Sun; Fig. 2; col. 4: 50 – 62; At 204, the method includes generating an update manifest (custom resource definition) including a plurality of update payloads from the selected update path …
At 206, the method includes uploading the plurality of update payloads to the host device (node) to cause the host device to update the system component …
col. 4: 63 – col. 5: 13; FIG. 3 is a diagram 300 showing an example multi-stage reversible function applied to component updates to represent a history of updates for a host device (node). As shown, an initial host state 302a (actual state) (e.g., an initial state of a host device, such as host device 104 of FIG. 1) may be represented by a previous hash 304a of live update version information for a component of the host device. When the component is updated with a first update version of the component, represented by payload 306a, a hash of the payload 306a is combined with the hash 304a of the current version (actual state) in the host device (e.g., using the XOR operation in the illustrative example) to derive the “previous hash” value 304b of a next host state 302b. This process is iteratively repeated for each of N updates (where N is an integer sequence number, representing the number of update versions applied to the host device to update the component) until a final update payload 306c is applied and used to generate the final hash 304d of the most up-to-date host state 302d (target state). Also see Fig. 4, col. 5: 22 – col. 6: 29), and wherein at least one operation of the one or more operations includes provisioning a dependent resource (Sun; Fig. 2; col. 4: 50 – 62; At 204, the method includes generating an update manifest (custom resource definition) including a plurality of update payloads (including dependent resource) from the selected update path …)
Claim 2
Sun also teaches
periodically querying, using the client-side update component of an update framework, a policy engine of a server-side update component of the update framework to obtain the resource graph associated with the at least one provisioned resource (Sun; Fig. 1; col. 3: 4 – 12; When an update is to be propagated to the host device 104, the user and/or management device 102 may request an update manifest from the update management system 106 (policy engine). The update management system 106 may utilize an update manifest builder 114 to access the directed graphs 110 (resource graph) …
Col. 2: 45 – 50; The update management system 106 may include an update path builder 108 configured to build, update, and manage one or more directed graphs (resource graph) of update paths 110 using version information of updates to one or more system components for the host devices 104);
returning, using the policy engine, the resource graph associated with the at least one provisioned resource to the client-side component (Sun; Fig. 1; col. 3: 4 – 12; When an update is to be propagated to the host device 104, the user and/or management device 102 may request an update manifest from the update management system 106 (policy engine). The update management system 106 may utilize an update manifest builder 114 to access the directed graphs 110 …)
Claim 3
Sun also teaches
requesting, using the policy engine, the resource graph associated with the at least one provisioned resource from a graph builder of the client-side update component based on one or more release pointers associated with at least one version of the provisioned resource (Sun; Fig. 1; col. 2: 45 – 49; The update management system 106 may include an update path builder 108 configured to build, update, and manage one or more directed graphs of update paths 110 using version information of updates to one or more system components for the host devices 104 …
col. 5: 23 – 39; FIG. 4 is an example of a directed graph 400 of different update paths for updating a host device …
For example, the host device may be updated to version 3 (release pointer) by applying the updates of versions 1 and 2 prior to applying the update of version 3, which would result in a new hash corresponding to a multi-stage iterative combination of the initial hash, the hash 1 of the payload of the version 1 update (release pointer), the hash 2 of the payload of the version 2 update (release pointer), and the hash 3 of the payload of the version 3 update …);
applying, using the policy engine, one or more policy definitions to the resource graph (Sun; col. 2: 45 – 58; The update management system 106 (policy engine) may include an update path builder 108 configured to build, update, and manage one or more directed graphs of update paths 110 using version information of updates to one or more system components for the host devices 104 …
… Further, for each host, the update payloads that are appropriate for the host devices may be based off of loaded firmware versions of the host devices, the host device's uptime, and/or the age of the firmware on the host device. However, these factors (policy definitions) may cause countless combinations in update paths); and
providing, using the policy engine, the resource graph to the client-side component (Sun; Fig. 1; col. 3: 4 – 12; When an update is to be propagated to the host device 104, the user and/or management device 102 may request an update manifest from the update management system 106 (policy engine). The update management system 106 may utilize an update manifest builder 114 to access the directed graphs 110 …)
Claim 4
Sun also teaches
retrieving one or more release pointers associated with one or more versions of the at least one provisioned resource from a release pointer artifact repository (Sun; col. 2: 45 – 49; The update management system 106 may include an update path builder 108 configured to build, update, and manage one or more directed graphs of update paths 110 using version information of updates to one or more system components for the host devices 104 …
col. 5: 23 – 39; FIG. 4 is an example of a directed graph 400 of different update paths for updating a host device …
For example, the host device may be updated to version 3 (release pointer) by applying the updates of versions 1 and 2 prior to applying the update of version 3, which would result in a new hash corresponding to a multi-stage iterative combination of the initial hash, the hash 1 of the payload of the version 1 update (release pointer), the hash 2 of the payload of the version 2 update (release pointer), and the hash 3 of the payload of the version 3 update …); and
generating the resource graph by linearly ordering, based on each version of the one or more versions of the at least one provisioned resource, the retrieved one or more release pointers corresponding to the at least one provisioned resource (Sun; col. 2: 45 – 49; The update management system 106 may include an update path builder 108 configured to build, update, and manage one or more directed graphs (resource graph) of update paths 110 using version information of updates to one or more system components for the host devices 104 …
col. 5: 23 – 39; FIG. 4 is an example of a directed graph 400 of different update paths for updating a host device …
For example, the host device may be updated to version 3 (release pointer) by applying the updates of versions 1 and 2 prior to applying the update of version 3, which would result in a new hash corresponding to a multi-stage iterative combination of the initial hash, the hash 1 of the payload of the version 1 update (release pointer), the hash 2 of the payload of the version 2 update (release pointer), and the hash 3 of the payload of the version 3 update …
Col. 6: 6 – 29; The directed graph 400 may be used to map update paths for updating any number and combination of system components. As new updates are received, new nodes are created in the graph corresponding to the addition of the new updates to the existing paths and the creation of new paths including the new updates …; see picture below)
PNG
media_image1.png
608
820
media_image1.png
Greyscale
Claim 5
Sun also teaches
identifying a current version of the at least one provisioned resource (Sun; Fig. 1; col. 3: 13 – 48; For example, the update management system 106 may utilize information about a current state of the host device 104 (e.g., a sequence number and/or a payload hash for a current version of the sub-component on the host device), which may be received via the request for the update manifest, to perform a multi-stage hashing operation using payloads associated with the initial/current version of the sub-component, the final (updated) version of the sub-component, and any updated versions that fall between the initial and final versions along a selected update path in the directed graph …);
locating the current version of the at least one provisioned resource in the resource graph associated with the at least one provisioned resource (Sun; Fig. 1; col. 3: 13 – 48; For example, the update management system 106 may utilize information about a current state of the host device 104 (e.g., a sequence number and/or a payload hash for a current version of the sub-component on the host device), which may be received via the request for the update manifest, to perform a multi-stage hashing operation using payloads associated with the initial/current version of the sub-component, the final (updated) version of the sub-component, and any updated versions that fall between the initial and final versions along a selected update path in the directed graph …); and
identifying a subsequent version of the at least one provisioned resource in the resource graph after the current version of the at least one provisioned resource (Sun; Fig. 1; col. 3: 13 – 48; For example, the update management system 106 may utilize information about a current state of the host device 104 (e.g., a sequence number and/or a payload hash for a current version of the sub-component on the host device), which may be received via the request for the update manifest, to perform a multi-stage hashing operation using payloads associated with the initial/current version of the sub-component, the final (updated) version of the sub-component, and any updated versions that fall between the initial and final versions along a selected update path in the directed graph …)
Claim 7
Sun also teaches the server-side update component is separate from the remote data center (Sun; col. 2: 27 – 44; FIG. 1 shows an example update environment 100 in which a user and/or management device 102 coordinates an update process for one or more host devices 104 using an update management system 106 (server-side update component) … the following description will largely reference updating a single system component for a single host device, however, it is to be understood that the described systems and processes may be implemented in order to coordinate the updating of multiple system components and/or multiple host systems (nodes), such as a fleet of servers in a network (e.g., a compute service provider network) and/or an on-premises data center …), update management system 106 is separate from host devices 104 in data center.
Claim 8
This is a system version of the method version in claim 1; therefore, it is rejected for the same reasons. Furthermore, Sun also teaches a system comprising a processing device (Sun; col. 11: 33 – 35; FIG. 8 depicts a generalized example of a suitable computing environment 800 in which the described innovations may be implemented.
Col. 11: 45 – 47; With reference to FIG. 8, the computing environment 800 includes one or more processing units 810, 815 and memory 820, 825.)
Claim 9
This limitation is already discussed in claim 2; therefore, it is rejected for the same reasons.
Claim 10
This limitation is already discussed in claim 3; therefore, it is rejected for the same reasons.
Claim 11
This limitation is already discussed in claim 4; therefore, it is rejected for the same reasons.
Claim 12
This limitation is already discussed in claim 5; therefore, it is rejected for the same reasons.
Claim 14
This limitation is already discussed in claim 7; therefore, it is rejected for the same reasons.
Claim 15
Sun teaches a circuit comprising:
one or more processors (Sun; col. 11: 33 – 35; FIG. 8 depicts a generalized example of a suitable computing environment 800 in which the described innovations may be implemented. And, col. 11: 45 – 47; With reference to FIG. 8, the computing environment 800 includes one or more processing units 810, 815 and memory 820, 825) to implement an update framework to periodically check for updates of one or more resources of a remote data center and perform over-the-air (OTA) updates to the one or more resources Fig. 2; col. 4: 37 – 49; At 202, the method includes selecting an update path for updating a system component (provisioned resource) of the host device (node) based on a multi-stage combination of hashes corresponding to versions of updates of the system component. For example, as described above, versions of the system component (provisioned resource), starting with an initial version of the system component (provisioned resource) that is currently included in the host device and ending with a targeted version of the system component (provisioned resource) to which the system component of the host device is to be updated, may be iteratively combined …;
Col. 2: 27 – 44; … the following description will largely reference updating a single system component for a single host device, however, it is to be understood that the described systems and processes may be implemented in order to coordinate the updating of multiple system components and/or multiple host systems (nodes), such as a fleet of servers in a network (e.g., a compute service provider network) and/or an on-premises data center …), wherein the update framework provides a custom resource definition associated with an available update of a provisioned resource to a custom controller, and wherein the custom controller performs one or more operations to synchronize an actual state of the provisioned resource to a target state of the provisioned resource specified by the custom resource definition (Sun; Fig. 2; col. 4: 50 – 62; At 204, the method includes generating an update manifest (custom resource definition) including a plurality of update payloads from the selected update path …
At 206, the method includes uploading the plurality of update payloads to the host device (node) to cause the host device to update the system component …
col. 4: 63 – col. 5: 13; FIG. 3 is a diagram 300 showing an example multi-stage reversible function applied to component updates to represent a history of updates for a host device (node). As shown, an initial host state 302a (actual state) (e.g., an initial state of a host device, such as host device 104 of FIG. 1) may be represented by a previous hash 304a of live update version information for a component of the host device. When the component is updated with a first update version of the component, represented by payload 306a, a hash of the payload 306a is combined with the hash 304a of the current version (actual state) in the host device (e.g., using the XOR operation in the illustrative example) to derive the “previous hash” value 304b of a next host state 302b. This process is iteratively repeated for each of N updates (where N is an integer sequence number, representing the number of update versions applied to the host device to update the component) until a final update payload 306c is applied and used to generate the final hash 304d of the most up-to-date host state 302d (target state). Also see Fig.4, col. 5: 22 – col. 6: 29), and wherein at least one operation of the one or more operations includes provisioning a dependent resource (Sun; Fig. 2; col. 4: 50 – 62; At 204, the method includes generating an update manifest (custom resource definition) including a plurality of update payloads (including dependent resource) from the selected update path …
At 206, the method includes uploading the plurality of update payloads to the host device (node) to cause the host device to update the system component …)
Claim 16
Sun also teaches the update framework comprises a combination of one or more client-side components and one or more server-side components (Sun; col. 2: 27 – 30; FIG. 1 shows an example update environment 100 in which a user and/or management device 102 coordinates an update process for one or more host devices 104 using an update management system 106.)
Claim 17
Sun also teaches the client-side components comprise at least one of:
a cluster version operator (CVO) to perform periodic checks for updates from a policy engine server (Sun; Fig. 1; col. 3: 4 – 12; When an update is to be propagated to the host device 104, the user and/or management device 102 may request an update manifest from the update management system 106. The update management system 106 may utilize an update manifest builder 114 to access the directed graphs 110 (resource graph) …); or
a second-level operator (SLO) to perform service updates (Sun; Fig. 1; col. 3: 49 – 53; After receipt of the update manifest from the update management system 106, the user/management device 102 may then send the update manifest to the host device 104 to cause the host device to update the system component according to the update manifest …)
Claim 19
Sun also teaches the server-side components comprises at least one of:
a policy engine to query a container artifact repository for one or more release pointers associated with at least one resource of the one or more resources (Sun; Fig. 1; col. 2: 45 – 49; The update management system 106 may include an update path builder 108 configured to build, update, and manage one or more directed graphs of update paths 110 using version information of updates to one or more system components for the host devices 104 …
col. 5: 23 – 39; FIG. 4 is an example of a directed graph 400 of different update paths for updating a host device …
For example, the host device may be updated to version 3 (release pointer) by applying the updates of versions 1 and 2 prior to applying the update of version 3, which would result in a new hash corresponding to a multi-stage iterative combination of the initial hash, the hash 1 of the payload of the version 1 update (release pointer), the hash 2 of the payload of the version 2 update (release pointer), and the hash 3 of the payload of the version 3 update …); or
a graph builder to generate one or more directed graphs that represent one or more eligible version for the one or more resources of a given cluster based at least in part on the one or more release pointer from the policy engine (Sun; Fig. 1; col. 2: 45 – 49; The update management system 106 may include an update path builder 108 configured to build, update, and manage one or more directed graphs of update paths 110 using version information of updates to one or more system components for the host devices 104 …
col. 5: 23 – 39; FIG. 4 is an example of a directed graph 400 of different update paths for updating a host device …
For example, the host device may be updated to version 3 (release pointer) by applying the updates of versions 1 and 2 prior to applying the update of version 3, which would result in a new hash corresponding to a multi-stage iterative combination of the initial hash, the hash 1 of the payload of the version 1 update (release pointer), the hash 2 of the payload of the version 2 update (release pointer), and the hash 3 of the payload of the version 3 update …)
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 6, 13, 18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Sun in view of Ibryam et al. (Pub. No. US 2022/0035646 A1; hereinafter Ibryam.)
Claim 6
Sun teaches the client-side update component is instantiated the remote data center (Sun; Fig. 2; col. 4: 32 – 54; method 200 may be performed in order to update the host device 104 (node) of FIG. 1 and may be performed by the user/management device 102 (client-side component) and/or the update management system 106 of FIG. 1 …;
Col. 2: 27 – 44; … the following description will largely reference updating a single system component for a single host device, however, it is to be understood that the described systems and processes may be implemented in order to coordinate the updating of multiple system components and/or multiple host systems (nodes), such as a fleet of servers in a network (e.g., a compute service provider network) and/or an on-premises data center …)
But Sun does not explicitly teach the client-side update component is instantiated using one or more remote Kubernetes clusters.
However, Ibryam teaches the client-side update component is instantiated using one or more remote Kubernetes clusters (Ibryam; [0014] FIG. 1 illustrates a system 100 for initializing and executing applications within containers according to an exemplary embodiment of the present disclosure … For example, the cluster 102 and/or the node 108 may execute applications (client-side update component) using a containerization platform, such as Kubernetes and/or Red Hat® OpenShift®), application executes in Kubernetes [Wingdings font/0xE0] application is instantiated in Kubernetes.
Sun and Ibryam are in the same analogous art as they are in the same field of endeavor, managing nodes in a computing environment. Therefore, it would have been obvious to one with ordinary skill, in the art before the effective filing date of the claimed invention, to incorporate Ibryam teachings into Sun invention to allow node to execute applications/component in containerization platform Kubernetes, as suggested by Ibryam ([0098]), as the Kubernetes platform automates deployment, scaling, and management of applications.
Claim 13
This limitation is already discussed in claim 6; therefore, it is rejected for the same reasons.
Claim 18
Sun also teaches the client-side components comprises at least one of:
the CVO is instantiated clusters (Sun; Fig. 1; col. 3: 4 – 12; When an update is to be propagated to the host device 104, the user and/or management device 102 may request an update manifest from the update management system 106. The update management system 106 may utilize an update manifest builder 114 to access the directed graphs 110 (resource graph) …)
But Sun does not explicitly teach the CVO is instantiated using one or more remote Kubernetes clusters.
However, Ibryam teaches the CVO is instantiated using one or more remote Kubernetes clusters (Ibryam; [0014] FIG. 1 illustrates a system 100 for initializing and executing applications within containers according to an exemplary embodiment of the present disclosure … For example, the cluster 102 and/or the node 108 may execute applications (CVO) using a containerization platform, such as Kubernetes and/or Red Hat® OpenShift®), application executes in Kubernetes [Wingdings font/0xE0] application is instantiated in Kubernetes.
Sun and Ibryam are in the same analogous art as they are in the same field of endeavor, managing nodes in a computing environment. Therefore, it would have been obvious to one with ordinary skill, in the art before the effective filing date of the claimed invention, to incorporate Ibryam teachings into Sun invention to allow node to execute applications/component in containerization platform Kubernetes, as suggested by Ibryam ([0098]), as the Kubernetes platform automates deployment, scaling, and management of applications.
Claim 20
Ibryam teaches the client-side components communicate with the server-side components via a sidecar container of the server-side components (Ibryam; [0013] … in certain instances, multiple applications executing in different primary containers may communicate with the same sidecar container implementing a particular integration function utilized by the multiple applications.) Motivation for incorporating Ibryam into Sun is the same as motivation in claim 6.
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 CUONG V LUU whose telephone number is (571)270-1733. The examiner can normally be reached 6:30 AM - 3:00 PM.
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, Hyung S. Sough can be reached at (571) 272-6799. 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.
/CUONG V LUU/Examiner, Art Unit 2192
/S. Sough/SPE, Art Unit 2192
Prosecution Insights