DETAILED ACTION
This Office action is in response to the amendment filed on June 24, 2026.
Claims 1-20 are pending.
Claims 1, 4, 6-8, 10, 11, 13, 15, 17, and 19 are currently amended.
Applicant has failed to fully address the objections to Claims 1, 3-10, 13, and 17-20. Accordingly, these objections are maintained and further explained hereinafter.
Applicant has failed to fully address the 35 U.S.C. § 112(b) rejection of Claim 15. Accordingly, this rejection is maintained and further explained hereinafter.
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 .
Internet Communications
Without a written authorization for Internet communications by the Applicant in place, the USPTO cannot communicate with the Applicant via email and will not respond via email to any Internet correspondence which contains information subject to the confidentiality requirement as set forth in 35 U.S.C. § 122, such as claimed subject matter in an interview agenda or proposed claim amendments for an Examiner’s Amendment.
Therefore, in the interest of facilitating compact prosecution, the Examiner kindly asks the Applicant to authorize Internet communications with the USPTO by using Form PTO/SB/439 (available at https://www.uspto.gov/patents/apply/forms). The form may be submitted via the USPTO patent electronic filing system (Patent Center) using the document description “Internet Communications Authorized” to facilitate processing. The written authorization for Internet communications must be submitted on a separate paper to be entitled to acceptance in accordance with 37 CFR § 1.4(c). The separate paper will facilitate processing and avoid confusion. The written authorization for Internet communications may not be submitted via an email. See MPEP § 502.03(II).
Claim Interpretation
For clarity of the prosecution history record, Claims 17-20 are directed to one or more computer storage media. It is noted that the Applicant’s specification expressly states that “[c]omputer storage media does not comprise signals per se” (paragraph [00128]). Thus, such statement appears to provide a special definition that explicitly excludes a computer storage medium from being interpreted as transitory signals per se. Therefore, Claims 17-20 can rely on the special definition and are eligible subject matter under § 101.
Response to Amendment
<<>> • × • <<>>
Claim Objections
Claims 1, 3-10, 13, and 17-20 are objected to because of the following informalities:
Claims 1, 3, 9, 10, 17, and 18 recite “the snapshot.” It should read -- the snapshot of content --.
<<>> + <<>> + <<>> • × • <<>> + <<>> + <<>>
Claims 3-8, 13, 18, and 19 contain a typographical error: the word “and” should be added after the first “wherein” clause.
<<>> + <<>> + <<>> • × • <<>> + <<>> + <<>>
Claim 5 recites “the completion.” It should read -- the completion of the firmware update --.
<<>> + <<>> + <<>> • × • <<>> + <<>> + <<>>
Claim 10 recites “the execution.” It should read -- the execution of the workflow application --.
<<>> + <<>> + <<>> • × • <<>> + <<>> + <<>>
Claim 20 recites “the completion.” It should read -- the completion of the aspect of the firmware update --.
Appropriate correction is required.
Claim Rejections - 35 U.S.C. § 112
The following is a quotation of 35 U.S.C. § 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claim 15 is rejected under 35 U.S.C. § 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention.
Claim 15 recites the limitation “the workflow.” There is insufficient antecedent basis for this limitation in the claim. In the interest of compact prosecution, the Examiner subsequently interprets this limitation as reading “the workflow application” for the purpose of further examination.
Claim Rejections - 35 U.S.C. § 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, 2, 9-11, 13, and 15-17 are rejected under 35 U.S.C. § 103 as being unpatentable over US 2014/0033187 (hereinafter “Beale”) in view of US 2017/0154005 (hereinafter “Ahmed”), US 2020/0334083 (hereinafter “Liu”), and US 2023/0385159 (hereinafter “Kuchibhotla”).
Examiner’s Remarks: In order for a reference to be proper for use in an obviousness rejection under 35 U.S.C. § 103, the reference must be analogous art to the claimed invention. In re Bigio, 381 F.3d 1320, 1325, 72 USPQ2d 1209, 1212 (Fed. Cir. 2004). A reference is analogous art to the claimed invention if: (1) the reference is from the same field of endeavor as the claimed invention (even if it addresses a different problem); or (2) the reference is reasonably pertinent to the problem faced by the inventor (even if it is not in the same field of endeavor as the claimed invention). See MPEP § 2141.01(a)(I).
Note that the claimed invention is generally directed to providing efficient implementation of firmware updates on GPUs in a data center, while reducing disruption to workflows associated with certain workflow application (specification, paragraph [0007]). As for the “same field of endeavor” test, Beale is generally directed to dynamic firmware updating systems useable in translated computing environments (specification, paragraph [0001]). As for the “reasonably pertinent” test, Ahmed is generally directed to managing workloads and hot-swapping a co-processor of an information handling system in a data center (specification, paragraph [0001]). And Liu is generally directed to determining a resource required for executing a code segment (specification, paragraph [0002]). And Kuchibhotla is generally directed to providing a snapshot ability in a manner that prevents data loss (specification, paragraph [0001]). Thus, Beale, Ahmed, Liu, and Kuchibhotla are all analogous art to the claimed invention (even if they address different problems or are not in the same field of endeavor as the claimed invention).
As per Claim 1, Beale discloses:
A system (Figure 1) to coordinate a firmware update and execution of a workflow, the system comprising:
Examiner’s Remarks: Note that the limitation “coordinate a firmware update and execution of a workflow” in the preamble of the claim is not given any patentable weight because it is merely a statement of purpose or intended use of the claimed invention. See MPEP § 2111.02.
at least one computer processor (Figure 1: 102); and
computer storage media (Figure 1: 104) storing computer-useable instructions that, when used by the at least one computer processor, cause the system to perform operations comprising:
accessing a request to perform the firmware update […] (paragraph [0041], “An update command operation 212 is then issued from the non-native operating system, via the remaining firmware module, to the console program to initiate the transition to new firmware [accessing a request to perform the firmware update]. A transfer operation 214 transfers control of the overall method to the console program, for execution of the dynamic firmware update (emphasis added).”);
capturing a snapshot of content stored on a […] memory […] (paragraph [0024], “The memory 104 can include one or more memory devices, and generally represents a storage subsystem of the computing device. The memory 104 can include one or more different types of RAM, Flash memory, or disk memory, and is addressable by the processor 102 to execute one or more of the modules thereon. As further discussed below, the memory 104 is capable of hosting different firmware and/or software systems (emphasis added).”; paragraph [0043], “A halt partition operation 216 halts all operation on the resource managed by the firmware. In the embodiment shown in FIG. 1, the halt partition operation 216 halts operation of a particular partition, including the state of the stacks, non-native operating system, and non-native applications executing thereon, such that the partition resources (e.g., memory associated with that partition) are preserved in their last used state. As such, the halt partition operation 216, in conjunction with the quiesce operation 208 and halt operation 210, effectively captures a snapshot of the current state of execution within a particular partition by preventing the associated instructions and data from being changed during the firmware update process. In the embodiments discussed here, the halt partition operation 216 occurs on a partition including the remaining, executing firmware module (emphasis added).”);
based on the request, performing the firmware update subsequent to [a] workflow application being controlled and the snapshot being captured (paragraph [0043]1, “A halt partition operation 216 halts all operation on the resource managed by the firmware. In the embodiment shown in FIG. 1, the halt partition operation 216 halts operation of a particular partition, including the state of the stacks, non-native operating system, and non-native applications [{a} workflow application] executing thereon, such that the partition resources (e.g., memory associated with that partition) are preserved in their last used state. As such, the halt partition operation 216, in conjunction with the quiesce operation 208 and halt operation 210, effectively captures a snapshot of the current state of execution within a particular partition by preventing the associated instructions and data from being changed during the firmware update process [{a} workflow application being controlled and the snapshot being captured]. In the embodiments discussed here, the halt partition operation 216 occurs on a partition including the remaining, executing firmware module (emphasis added).”; paragraph [0044], “An update operation 218 performs the actual updating of firmware within the computing system. Since the resource managed by the now-halted firmware has its state preserved, the current firmware can be replaced by updated firmware within the computing system [based on the request, performing the firmware update subsequent to {a} workflow application being controlled and the snapshot being captured] (emphasis added).”); and
1Examiner’s Remarks: Note that the Applicant’s specification expressly states that “[…] a ‘workflow’ (also referred to herein in one example as ‘tasks’ or ‘workload’) refers to a series or collection of activities or computations associated with completing a task” (paragraph [0029]). Thus, under the broadest reasonable interpretation (BRI), the plain meaning of the limitation “a workflow application” includes an application executing a series or collection of activities or computations associated with completing a task, which is consistent with the specification. Thus, the limitation “a workflow application,” given its plain meaning consistent with the specification, is mapped to Beale’s non-native application. See MPEP § 2173.01(I).
subsequent to completion of the firmware update, […] resume the execution of the workflow application based at least on the snapshot […] (paragraph [0046], “In the embodiment shown in FIG. 1, the update operation 218 starts execution of the new firmware using the customized, initial stack generated using the initial stack building operation 206 [subsequent to completion of the firmware update], which involves both initial, startup operations generally performed by a system organized according stack-based non-native architecture, and the various custom operations included in the stack. This generally includes restarting use of the halted partition using the updated firmware, thereby allowing the operating system to resume operation from where the previous firmware left off, thereby restarting operation of the firmware within the partition [resume the execution of the workflow application based at least on the snapshot] (emphasis added).”), wherein the workflow application resumes execution […] (paragraph [0048], “It additionally includes a workload resumption operation 224, in which the one or more applications 124 that were previously executing are resumed, thereby allowing continued execution from the point at which the previous firmware was interrupted to perform the firmware update (emphasis added).”).
Beale does not explicitly disclose:
[…] associated with a graphics processing unit (GPU) of a node; and
based on the request, causing an operating system (OS) driver of the GPU to control a workflow application being hosted or executed on the GPU.
However, Ahmed discloses:
[…] associated with a graphics processing unit (GPU) of a node (paragraph [0048], “Host processing complex 1020 represents the main processing elements of information handling system 1000, including a main processor stack 1022 including one or more processors, chipset elements, storage devices, memory devices, I/O devices, and the like, general-purpose processing units (GPUs) 1024 and 1026, and a hot-plug control module 1028. GPUs 1024 and 1026 represent processing resources of host processing complex 1020 that can be utilized to offload main processor stack 1022 from various functions as needed or desired. An example of GPUs 1024 and 1026 include graphics co-processors, encoding co-processors, or media co-processors, and the like, such as various processing devices as my be supplied by different vendors or manufacturers (emphasis added).”); and
based on the request, causing an operating system (OS) driver of the GPU to control a workflow application being hosted or executed on the GPU (paragraph [0049], “Hosted OS 1032 operates to manage the runtime aspects of hosted environment 1030, to launch programs and applications on host processing complex 1020, and to launch, manage, maintain, and halt workloads on GPUs 1024 and 1026. For example, after a hot-plug event, a replacement GPU can be reset by hot-plug control module 1028, and hosted OS can detect the presence of the replacement GPU, and launch a workload on the replacement GPU (emphasis added).”).
As pointed out hereinabove, Beale and Ahmed are both analogous art to the claimed invention. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Ahmed into the teaching of Beale to include “[…] associated with a graphics processing unit (GPU) of a node; and based on the request, causing an operating system (OS) driver of the GPU to control a workflow application being hosted or executed on the GPU.” The modification would be obvious because one of ordinary skill in the art would be motivated to utilize graphics co-processors to offload various compute intensive tasks and services from main processor stack (Ahmed, paragraph [0048]).
The combination of Beale and Ahmed does not explicitly disclose:
[…] a high-bandwidth memory (HBM) associated with the GPU.
However, Liu discloses:
[…] a high-bandwidth memory (HBM) associated with the GPU (paragraph [0045], “It is known that GPU, as a dedicated processor, has strong computing capability due to a large number of kernels and high-bandwidth memory (emphasis added).”).
As pointed out hereinabove, Liu is an analogous art to the claimed invention. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Liu into the combined teachings of Beale and Ahmed to include “[…] a high-bandwidth memory (HBM) associated with the GPU.” The modification would be obvious because one of ordinary skill in the art would be motivated to utilize a computer memory interface for 3D-stacked synchronous dynamic random-access memory (SDRAM).
Beale discloses “after completion of the firmware update” and the combination of Beale, Ahmed, and Liu discloses “the HBM,” but the combination of Beale, Ahmed, and Liu does not explicitly disclose:
[…] restoring, after completion of the firmware update, the HBM with content from the snapshot; and
[…] based on the content restored to the HBM.
However, Kuchibhotla discloses:
[…] restoring […] the [storage system] with content from the snapshot (paragraph [0032], “As illustrated, the storage manager 110 also includes a third module, a recovery manager 166 configured to restore the local storage system 105 to a state indicated by a snapshot stored in the snapshot storage 125. For example, a user may want to restore the local storage system 105 to a state reflected by a snapshot 117, such as in response to a failure at the local storage system 105 or to debug an issue with the compute 102 (emphasis added).”; paragraph [0085], “At block 704, in response to detecting the event, the storage manager restores the cloud-based storage system to a state indicated by a most recent snapshot of the cloud-based storage system captured prior to detecting the event (emphasis added).”); and
[…] based on the content restored to the [storage system] (paragraph [0032], “As illustrated, the storage manager 110 also includes a third module, a recovery manager 166 configured to restore the local storage system 105 to a state indicated by a snapshot stored in the snapshot storage 125. For example, a user may want to restore the local storage system 105 to a state reflected by a snapshot 117, such as in response to a failure at the local storage system 105 or to debug an issue with the compute 102 (emphasis added).”; paragraph [0085], “At block 704, in response to detecting the event, the storage manager restores the cloud-based storage system to a state indicated by a most recent snapshot of the cloud-based storage system captured prior to detecting the event (emphasis added).”).
As pointed out hereinabove, Kuchibhotla is an analogous art to the claimed invention. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Kuchibhotla into the combined teachings of Beale, Ahmed, and Liu to include “[…] restoring, after completion of the firmware update, the HBM with content from the snapshot; and […] based on the content restored to the HBM.” The modification would be obvious because one of ordinary skill in the art would be motivated to restore an HBM to a state reflected by a snapshot, such as in response to a failure at the HBM or to debug an issue with the GPU (Kuchibhotla, paragraph [0032]).
As per Claim 2, the rejection of Claim 1 is incorporated; and Beale further discloses:
wherein controlling the workflow application comprises pausing the execution of the workflow application (paragraph [0043], “A halt partition operation 216 halts all operation on the resource managed by the firmware. In the embodiment shown in FIG. 1, the halt partition operation 216 halts operation of a particular partition, including the state of the stacks, non-native operating system, and non-native applications executing thereon, such that the partition resources (e.g., memory associated with that partition) are preserved in their last used state. As such, the halt partition operation 216, in conjunction with the quiesce operation 208 and halt operation 210, effectively captures a snapshot of the current state of execution within a particular partition by preventing the associated instructions and data from being changed during the firmware update process. In the embodiments discussed here, the halt partition operation 216 occurs on a partition including the remaining, executing firmware module.”).
As per Claim 9, the rejection of Claim 1 is incorporated; and Beale further discloses:
wherein the snapshot comprises at least one of metadata associated with the execution of the workflow application or contextual data associated with the execution of the workflow application (paragraph [0043], “A halt partition operation 216 halts all operation on the resource managed by the firmware. In the embodiment shown in FIG. 1, the halt partition operation 216 halts operation of a particular partition, including the state of the stacks, non-native operating system, and non-native applications executing thereon, such that the partition resources (e.g., memory associated with that partition) are preserved in their last used state. As such, the halt partition operation 216, in conjunction with the quiesce operation 208 and halt operation 210, effectively captures a snapshot of the current state of execution within a particular partition by preventing the associated instructions and data from being changed during the firmware update process. In the embodiments discussed here, the halt partition operation 216 occurs on a partition including the remaining, executing firmware module.”).
As per Claim 10, the rejection of Claim 1 is incorporated; and the combination of Beale, Ahmed, Liu, and Kuchibhotla discloses “causing the OS driver to resume the execution of the workflow application based at least on the snapshot,” “the GPU,” and “the HBM,” and Beale further discloses:
communicating […] an indication that an aspect of the firmware update has been completed […] (paragraph [0046], “In the embodiment shown in FIG. 1, the update operation 218 starts execution of the new firmware using the customized, initial stack generated using the initial stack building operation 206, which involves both initial, startup operations generally performed by a system organized according stack-based non-native architecture, and the various custom operations included in the stack. This generally includes restarting use of the halted partition using the updated firmware, thereby allowing the operating system to resume operation from where the previous firmware left off, thereby restarting operation of the firmware within the partition.”); and
restoring […] with content from the snapshot, wherein the workflow application resumes the execution based on the content from the snapshot (paragraph [0046], “In the embodiment shown in FIG. 1, the update operation 218 starts execution of the new firmware using the customized, initial stack generated using the initial stack building operation 206, which involves both initial, startup operations generally performed by a system organized according stack-based non-native architecture, and the various custom operations included in the stack. This generally includes restarting use of the halted partition using the updated firmware, thereby allowing the operating system to resume operation from where the previous firmware left off, thereby restarting operation of the firmware within the partition.”).
As per Claim 11, Beale discloses:
A computer-implemented method (paragraph [0007], “[…] a method for updating firmware executing on a computing system are disclosed.”), comprising:
transmitting […] a request to perform a firmware update […] (paragraph [0041], “An update command operation 212 is then issued from the non-native operating system, via the remaining firmware module, to the console program to initiate the transition to new firmware [transmitting {…} a request to perform a firmware update]. A transfer operation 214 transfers control of the overall method to the console program, for execution of the dynamic firmware update (emphasis added).”);
causing […] to capture a snapshot of a […] memory […] based on the request (paragraph [0024], “The memory 104 can include one or more memory devices, and generally represents a storage subsystem of the computing device. The memory 104 can include one or more different types of RAM, Flash memory, or disk memory, and is addressable by the processor 102 to execute one or more of the modules thereon. As further discussed below, the memory 104 is capable of hosting different firmware and/or software systems (emphasis added).”; paragraph [0043], “A halt partition operation 216 halts all operation on the resource managed by the firmware. In the embodiment shown in FIG. 1, the halt partition operation 216 halts operation of a particular partition, including the state of the stacks, non-native operating system, and non-native applications executing thereon, such that the partition resources (e.g., memory associated with that partition) are preserved in their last used state. As such, the halt partition operation 216, in conjunction with the quiesce operation 208 and halt operation 210, effectively captures a snapshot of the current state of execution within a particular partition by preventing the associated instructions and data from being changed during the firmware update process. In the embodiments discussed here, the halt partition operation 216 occurs on a partition including the remaining, executing firmware module (emphasis added).”);
controlling a workflow application being hosted or executed […] until completion of an aspect of the firmware update (paragraph [0043]1, “A halt partition operation 216 halts all operation on the resource managed by the firmware. In the embodiment shown in FIG. 1, the halt partition operation 216 halts operation of a particular partition, including the state of the stacks, non-native operating system, and non-native applications [{a} workflow application] executing thereon, such that the partition resources (e.g., memory associated with that partition) are preserved in their last used state. As such, the halt partition operation 216, in conjunction with the quiesce operation 208 and halt operation 210, effectively captures a snapshot of the current state of execution within a particular partition by preventing the associated instructions and data from being changed during the firmware update process [controlling a workflow application being hosted or executed]. In the embodiments discussed here, the halt partition operation 216 occurs on a partition including the remaining, executing firmware module (emphasis added).”; paragraph [0044], “An update operation 218 performs the actual updating of firmware within the computing system. Since the resource managed by the now-halted firmware has its state preserved, the current firmware can be replaced by updated firmware within the computing system [until completion of an aspect of the firmware update] (emphasis added).”);
1Examiner’s Remarks: Note that the Applicant’s specification expressly states that “[…] a ‘workflow’ (also referred to herein in one example as ‘tasks’ or ‘workload’) refers to a series or collection of activities or computations associated with completing a task” (paragraph [0029]). Thus, under the broadest reasonable interpretation (BRI), the plain meaning of the limitation “a workflow application” includes an application executing a series or collection of activities or computations associated with completing a task, which is consistent with the specification. Thus, the limitation “a workflow application,” given its plain meaning consistent with the specification, is mapped to Beale’s non-native application. See MPEP § 2173.01(I).
receiving an indication of the completion of the aspect of the firmware update (paragraph [0046]2, “In the embodiment shown in FIG. 1, the update operation 218 starts execution of the new firmware using the customized, initial stack generated using the initial stack building operation 206, which involves both initial, startup operations generally performed by a system organized according stack-based non-native architecture, and the various custom operations included in the stack. This generally includes restarting use of the halted partition using the updated firmware, thereby allowing the operating system to resume operation from where the previous firmware left off, thereby restarting operation of the firmware within the partition (emphasis added).”); and
2Examiner’s Remarks: Note that Beale discloses that the operating system restarts use of the halted partition using the updated firmware. Thus, one of ordinary skill in the art would readily comprehend that the operating system receives an indication that the firmware updating has completed in order to be able to use the updated firmware.
resuming execution of the workflow application subsequent to the completion of the aspect of the firmware update […] (paragraph [0046], “In the embodiment shown in FIG. 1, the update operation 218 starts execution of the new firmware using the customized, initial stack generated using the initial stack building operation 206, which involves both initial, startup operations generally performed by a system organized according stack-based non-native architecture, and the various custom operations included in the stack. This generally includes restarting use of the halted partition using the updated firmware, thereby allowing the operating system to resume operation from where the previous firmware left off, thereby restarting operation of the firmware within the partition [resuming execution of the workflow application subsequent to the completion of the aspect of the firmware update] (emphasis added).”), wherein the workflow application resumes execution […] (paragraph [0048], “It additionally includes a workload resumption operation 224, in which the one or more applications 124 that were previously executing are resumed, thereby allowing continued execution from the point at which the previous firmware was interrupted to perform the firmware update (emphasis added).”).
Beale does not explicitly disclose:
[…] via an operating system (OS) driver of a graphics processing unit (GPU) of a node […].
However, Ahmed discloses:
[…] via an operating system (OS) driver of a graphics processing unit (GPU) of a node […] (paragraph [0049], “Hosted OS 1032 operates to manage the runtime aspects of hosted environment 1030, to launch programs and applications on host processing complex 1020, and to launch, manage, maintain, and halt workloads on GPUs 1024 and 1026. For example, after a hot-plug event, a replacement GPU can be reset by hot-plug control module 1028, and hosted OS can detect the presence of the replacement GPU, and launch a workload on the replacement GPU (emphasis added).”).
As pointed out hereinabove, Beale and Ahmed are both analogous art to the claimed invention. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Ahmed into the teaching of Beale to include “[…] via an operating system (OS) driver of a graphics processing unit (GPU) of a node […].” The modification would be obvious because one of ordinary skill in the art would be motivated to utilize graphics co-processors to offload various compute intensive tasks and services from main processor stack (Ahmed, paragraph [0048]).
The combination of Beale and Ahmed does not explicitly disclose:
a high-bandwidth memory (HBM) of the GPU.
However, Liu discloses:
a high-bandwidth memory (HBM) of the GPU (paragraph [0045], “It is known that GPU, as a dedicated processor, has strong computing capability due to a large number of kernels and high-bandwidth memory (emphasis added).”).
As pointed out hereinabove, Liu is an analogous art to the claimed invention. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Liu into the combined teachings of Beale and Ahmed to include “a high-bandwidth memory (HBM) of the GPU.” The modification would be obvious because one of ordinary skill in the art would be motivated to utilize a computer memory interface for 3D-stacked synchronous dynamic random-access memory (SDRAM).
Beale discloses “after completion of the firmware update” and the combination of Beale, Ahmed, and Liu discloses “the HBM,” but the combination of Beale, Ahmed, and Liu does not explicitly disclose:
[…] restoring, after completion of the firmware update, the HBM with content from the snapshot; and
[…] based on the content restored to the HBM.
However, Kuchibhotla discloses:
[…] restoring […] the [storage system] with content from the snapshot (paragraph [0032], “As illustrated, the storage manager 110 also includes a third module, a recovery manager 166 configured to restore the local storage system 105 to a state indicated by a snapshot stored in the snapshot storage 125. For example, a user may want to restore the local storage system 105 to a state reflected by a snapshot 117, such as in response to a failure at the local storage system 105 or to debug an issue with the compute 102 (emphasis added).”; paragraph [0085], “At block 704, in response to detecting the event, the storage manager restores the cloud-based storage system to a state indicated by a most recent snapshot of the cloud-based storage system captured prior to detecting the event (emphasis added).”); and
[…] based on the content restored to the [storage system] (paragraph [0032], “As illustrated, the storage manager 110 also includes a third module, a recovery manager 166 configured to restore the local storage system 105 to a state indicated by a snapshot stored in the snapshot storage 125. For example, a user may want to restore the local storage system 105 to a state reflected by a snapshot 117, such as in response to a failure at the local storage system 105 or to debug an issue with the compute 102 (emphasis added).”; paragraph [0085], “At block 704, in response to detecting the event, the storage manager restores the cloud-based storage system to a state indicated by a most recent snapshot of the cloud-based storage system captured prior to detecting the event (emphasis added).”).
As pointed out hereinabove, Kuchibhotla is an analogous art to the claimed invention. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Kuchibhotla into the combined teachings of Beale, Ahmed, and Liu to include “[…] restoring, after completion of the firmware update, the HBM with content from the snapshot; and […] based on the content restored to the HBM.” The modification would be obvious because one of ordinary skill in the art would be motivated to restore an HBM to a state reflected by a snapshot, such as in response to a failure at the HBM or to debug an issue with the GPU (Kuchibhotla, paragraph [0032]).
As per Claim 13, the rejection of Claim 11 is incorporated; and the combination of Beale, Liu, and Kuchibhotla does not explicitly disclose:
wherein the GPU comprises a communication interface communicatively coupled to the OS driver, wherein the OS driver does not communicate the request to another GPU not having the communication interface.
However, Ahmed discloses:
wherein the GPU comprises a communication interface communicatively coupled to the OS driver, wherein the OS driver does not communicate the request to another GPU not having the communication interface (paragraph [0049]1, “Hosted OS 1032 operates to manage the runtime aspects of hosted environment 1030, to launch programs and applications on host processing complex 1020, and to launch, manage, maintain, and halt workloads on GPUs 1024 and 1026. For example, after a hot-plug event, a replacement GPU can be reset by hot-plug control module 1028, and hosted OS can detect the presence of the replacement GPU, and launch a workload on the replacement GPU.”; paragraph [0054], “[…] GPU interface module 1042 directs GPU handler module 1036 to retrieve the requested information from hosted environment 1030, from hosted OS 1032, or directly from the selected one of GPUs 1024 and 1026, and to provide the retrieved information to the GPU interface module.”).
1Examiner’s Remarks: Note that Ahmed discloses that the hosted OS launches, manages, maintains, and halts workloads on GPUs. And that the GPUs provide requested information to the GPU interface module. Thus, one of ordinary skill in the art would readily comprehend that the hosted OS does not communicate with an GPU not having a communication interface.
As pointed out hereinabove, Ahmed is an analogous art to the claimed invention. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Ahmed into the combined teachings of Beale, Liu, and Kuchibhotla to include “wherein the GPU comprises a communication interface communicatively coupled to the OS driver, wherein the OS driver does not communicate the request to another GPU not having the communication interface.” The modification would be obvious because one of ordinary skill in the art would be motivated to utilize graphics co-processors to offload various compute intensive tasks and services from main processor stack (Ahmed, paragraph [0048]).
As per Claim 15, the rejection of Claim 11 is incorporated; and Beale further discloses:
wherein causing the GPU to capture a snapshot comprises instructing the workflow application to pause and store on the content associated with the workflow at a time of pausing (paragraph [0043], “A halt partition operation 216 halts all operation on the resource managed by the firmware. In the embodiment shown in FIG. 1, the halt partition operation 216 halts operation of a particular partition, including the state of the stacks, non-native operating system, and non-native applications executing thereon, such that the partition resources (e.g., memory associated with that partition) are preserved in their last used state. As such, the halt partition operation 216, in conjunction with the quiesce operation 208 and halt operation 210, effectively captures a snapshot of the current state of execution within a particular partition by preventing the associated instructions and data from being changed during the firmware update process. In the embodiments discussed here, the halt partition operation 216 occurs on a partition including the remaining, executing firmware module.”).
As per Claim 16, the rejection of Claim 11 is incorporated; and Beale further discloses:
wherein controlling the workflow application comprises at least one of: pausing the execution of the workflow application or deleting at least one pending command from the workflow application (paragraph [0043], “A halt partition operation 216 halts all operation on the resource managed by the firmware. In the embodiment shown in FIG. 1, the halt partition operation 216 halts operation of a particular partition, including the state of the stacks, non-native operating system, and non-native applications executing thereon, such that the partition resources (e.g., memory associated with that partition) are preserved in their last used state. As such, the halt partition operation 216, in conjunction with the quiesce operation 208 and halt operation 210, effectively captures a snapshot of the current state of execution within a particular partition by preventing the associated instructions and data from being changed during the firmware update process. In the embodiments discussed here, the halt partition operation 216 occurs on a partition including the remaining, executing firmware module.”).
As per Claim 17, Beale discloses:
One or more computer storage media (Figure 1: 104) having computer-executable instructions embodied thereon that, when executed by one or more processors cause a computing system to perform operations comprising:
accessing a request to perform a firmware update […] (paragraph [0041], “An update command operation 212 is then issued from the non-native operating system, via the remaining firmware module, to the console program to initiate the transition to new firmware [accessing a request to perform a firmware update]. A transfer operation 214 transfers control of the overall method to the console program, for execution of the dynamic firmware update (emphasis added).”);
capturing a snapshot of content stored at a time of pausing the execution of [a] workflow application and on a memory device […] (paragraph [0024], “The memory 104 can include one or more memory devices, and generally represents a storage subsystem of the computing device. The memory 104 can include one or more different types of RAM, Flash memory, or disk memory, and is addressable by the processor 102 to execute one or more of the modules thereon. As further discussed below, the memory 104 is capable of hosting different firmware and/or software systems (emphasis added).”; paragraph [0043]1, “A halt partition operation 216 halts all operation on the resource managed by the firmware. In the embodiment shown in FIG. 1, the halt partition operation 216 halts operation of a particular partition, including the state of the stacks, non-native operating system, and non-native applications [{a} workflow application] executing thereon, such that the partition resources (e.g., memory associated with that partition) are preserved in their last used state. As such, the halt partition operation 216, in conjunction with the quiesce operation 208 and halt operation 210, effectively captures a snapshot of the current state of execution within a particular partition by preventing the associated instructions and data from being changed during the firmware update process. In the embodiments discussed here, the halt partition operation 216 occurs on a partition including the remaining, executing firmware module (emphasis added).”);
1Examiner’s Remarks: Note that the Applicant’s specification expressly states that “[…] a ‘workflow’ (also referred to herein in one example as ‘tasks’ or ‘workload’) refers to a series or collection of activities or computations associated with completing a task” (paragraph [0029]). Thus, under the broadest reasonable interpretation (BRI), the plain meaning of the limitation “a workflow application” includes an application executing a series or collection of activities or computations associated with completing a task, which is consistent with the specification. Thus, the limitation “a workflow application,” given its plain meaning consistent with the specification, is mapped to Beale’s non-native application. See MPEP § 2173.01(I).
based on the request, performing the firmware update subsequent to the workflow application being paused and the snapshot being captured (paragraph [0043], “As such, the halt partition operation 216, in conjunction with the quiesce operation 208 and halt operation 210, effectively captures a snapshot of the current state of execution within a particular partition by preventing the associated instructions and data from being changed during the firmware update process [the workflow application being paused and the snapshot being captured]. In the embodiments discussed here, the halt partition operation 216 occurs on a partition including the remaining, executing firmware module (emphasis added).”; paragraph [0044], “An update operation 218 performs the actual updating of firmware within the computing system. Since the resource managed by the now-halted firmware has its state preserved, the current firmware can be replaced by updated firmware within the computing system [based on the request, performing the firmware update subsequent to the workflow application being paused and the snapshot being captured] (emphasis added).”); and
subsequent to completion of an aspect of the firmware update, […] resume the execution of the workflow application based at least on the snapshot […] (paragraph [0046], “In the embodiment shown in FIG. 1, the update operation 218 starts execution of the new firmware using the customized, initial stack generated using the initial stack building operation 206 [subsequent to completion of the firmware update], which involves both initial, startup operations generally performed by a system organized according stack-based non-native architecture, and the various custom operations included in the stack. This generally includes restarting use of the halted partition using the updated firmware, thereby allowing the operating system to resume operation from where the previous firmware left off, thereby restarting operation of the firmware within the partition [resume the execution of the workflow application based at least on the snapshot] (emphasis added).”), wherein the workflow application resumes execution […] (paragraph [0048], “It additionally includes a workload resumption operation 224, in which the one or more applications 124 that were previously executing are resumed, thereby allowing continued execution from the point at which the previous firmware was interrupted to perform the firmware update (emphasis added).”).
Beale discloses “pause execution of a workflow application,” but Beale does not explicitly disclose:
[…] associated with a graphics processing unit (GPU) of a node; and
based on the request, causing an operating system (OS) driver associated with the GPU to pause execution of a workflow application being hosted or running on the GPU.
However, Ahmed discloses:
[…] associated with at least one graphics processing unit (GPU) of a node (paragraph [0048], “Host processing complex 1020 represents the main processing elements of information handling system 1000, including a main processor stack 1022 including one or more processors, chipset elements, storage devices, memory devices, I/O devices, and the like, general-purpose processing units (GPUs) 1024 and 1026, and a hot-plug control module 1028. GPUs 1024 and 1026 represent processing resources of host processing complex 1020 that can be utilized to offload main processor stack 1022 from various functions as needed or desired. An example of GPUs 1024 and 1026 include graphics co-processors, encoding co-processors, or media co-processors, and the like, such as various processing devices as my be supplied by different vendors or manufacturers (emphasis added).”); and
based on the request, causing an operating system (OS) driver associated with the GPU to [control] execution of a workflow application being hosted or running on the GPU (paragraph [0049], “Hosted OS 1032 operates to manage the runtime aspects of hosted environment 1030, to launch programs and applications on host processing complex 1020, and to launch, manage, maintain, and halt workloads on GPUs 1024 and 1026. For example, after a hot-plug event, a replacement GPU can be reset by hot-plug control module 1028, and hosted OS can detect the presence of the replacement GPU, and launch a workload on the replacement GPU (emphasis added).”).
As pointed out hereinabove, Beale and Ahmed are both analogous art to the claimed invention. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Ahmed into the teaching of Beale to include “[…] associated with a graphics processing unit (GPU) of a node; and based on the request, causing an operating system (OS) driver associated with the GPU to pause execution of a workflow application being hosted or running on the GPU.” The modification would be obvious because one of ordinary skill in the art would be motivated to utilize graphics co-processors to offload various compute intensive tasks and services from main processor stack (Ahmed, paragraph [0048]).
The combination of Beale and Ahmed does not explicitly disclose:
[…] a high-bandwidth memory (HBM) […].
However, Liu discloses:
[…] a high-bandwidth memory (HBM) […] (paragraph [0045], “It is known that GPU, as a dedicated processor, has strong computing capability due to a large number of kernels and high-bandwidth memory (emphasis added).”).
As pointed out hereinabove, Liu is an analogous art to the claimed invention. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Liu into the combined teachings of Beale and Ahmed to include “[…] a high-bandwidth memory (HBM) […].” The modification would be obvious because one of ordinary skill in the art would be motivated to utilize a computer memory interface for 3D-stacked synchronous dynamic random-access memory (SDRAM).
Beale discloses “after completion of the firmware update” and the combination of Beale, Ahmed, and Liu discloses “a high-bandwidth memory (HBM),” but the combination of Beale, Ahmed, and Liu does not explicitly disclose:
[…] restoring, after completion of the firmware update, a high-bandwidth memory (HBM) with content from the snapshot; and
[…] based on the content restored to the HBM.
However, Kuchibhotla discloses:
[…] restoring […] a [storage system] with content from the snapshot (paragraph [0032], “As illustrated, the storage manager 110 also includes a third module, a recovery manager 166 configured to restore the local storage system 105 to a state indicated by a snapshot stored in the snapshot storage 125. For example, a user may want to restore the local storage system 105 to a state reflected by a snapshot 117, such as in response to a failure at the local storage system 105 or to debug an issue with the compute 102 (emphasis added).”; paragraph [0085], “At block 704, in response to detecting the event, the storage manager restores the cloud-based storage system to a state indicated by a most recent snapshot of the cloud-based storage system captured prior to detecting the event (emphasis added).”); and
[…] based on the content restored to the [storage system] (paragraph [0032], “As illustrated, the storage manager 110 also includes a third module, a recovery manager 166 configured to restore the local storage system 105 to a state indicated by a snapshot stored in the snapshot storage 125. For example, a user may want to restore the local storage system 105 to a state reflected by a snapshot 117, such as in response to a failure at the local storage system 105 or to debug an issue with the compute 102 (emphasis added).”; paragraph [0085], “At block 704, in response to detecting the event, the storage manager restores the cloud-based storage system to a state indicated by a most recent snapshot of the cloud-based storage system captured prior to detecting the event (emphasis added).”).
As pointed out hereinabove, Kuchibhotla is an analogous art to the claimed invention. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Kuchibhotla into the combined teachings of Beale, Ahmed, and Liu to include “[…] restoring, after completion of the firmware update, a high-bandwidth memory (HBM) with content from the snapshot; and […] based on the content restored to the HBM.” The modification would be obvious because one of ordinary skill in the art would be motivated to restore an HBM to a state reflected by a snapshot, such as in response to a failure at the HBM or to debug an issue with the GPU (Kuchibhotla, paragraph [0032]).
Claims 3 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Beale in view of Ahmed, Liu, and Kuchibhotla as applied to Claims 1 and 17 above, and further in view of US 2003/0167380 (hereinafter “Green”).
Examiner’s Remarks: In order for a reference to be proper for use in an obviousness rejection under 35 U.S.C. § 103, the reference must be analogous art to the claimed invention. In re Bigio, 381 F.3d 1320, 1325, 72 USPQ2d 1209, 1212 (Fed. Cir. 2004). A reference is analogous art to the claimed invention if: (1) the reference is from the same field of endeavor as the claimed invention (even if it addresses a different problem); or (2) the reference is reasonably pertinent to the problem faced by the inventor (even if it is not in the same field of endeavor as the claimed invention). See MPEP § 2141.01(a)(I).
Note that the claimed invention is generally directed to providing efficient implementation of firmware updates on GPUs in a data center, while reducing disruption to workflows associated with certain workflow application (specification, paragraph [0007]). As for the “reasonably pertinent” test, Green is generally directed to maintaining a persistent snapshot (Abstract). Thus, Green is an analogous art to the claimed invention (even if it addresses a different problem).
As per Claim 3, the rejection of Claim 1 is incorporated; and the combination of Beale, Ahmed, Liu, and Kuchibhotla does not explicitly disclose:
wherein controlling the workflow application comprises deleting at least one pending command from the workflow application, wherein the snapshot omits the at least one pending command.
However, Green discloses:
wherein controlling the workflow application comprises deleting at least one pending command from the workflow application, wherein the snapshot omits the at least one pending command (paragraph [0087], “Turning now to FIG. 7, a third set of operations 700 (‘Write/Delete to Volume’) is shown in which ‘write and/or delete’ commands to a volume occur and the resulting impact on the snapshot caches are discussed.”; paragraph [0129], “It will be appreciated from a review of FIG. 34 that when a volume location is identified as no longer being subject to a snapshot, data at that location is not preserved before being replaced upon a write to that location even if there was a snapshot taken of the volume between the time that the omit command was made and the subsequent write occurred.”).
As pointed out hereinabove, Green is an analogous art to the claimed invention. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Green into the combined teachings of Beale, Ahmed, Liu, and Kuchibhotla to include “wherein controlling the workflow application comprises deleting at least one pending command from the workflow application, wherein the snapshot omits the at least one pending command.” The modification would be obvious because one of ordinary skill in the art would be motivated to not preserve a command in a snapshot when the command is identified as no longer needed (Green, paragraph [0129]).
As per Claim 18, the rejection of Claim 17 is incorporated; and the combination of Beale, Ahmed, Liu, and Kuchibhotla does not explicitly disclose:
wherein pausing the execution of the workflow application comprises deleting at least one pending command from the workflow application, wherein the snapshot does not include the at least one pending command.
However, Green discloses:
wherein pausing the execution of the workflow application comprises deleting at least one pending command from the workflow application, wherein the snapshot does not include the at least one pending command (paragraph [0087], “Turning now to FIG. 7, a third set of operations 700 (‘Write/Delete to Volume’) is shown in which ‘write and/or delete’ commands to a volume occur and the resulting impact on the snapshot caches are discussed.”; paragraph [0129], “It will be appreciated from a review of FIG. 34 that when a volume location is identified as no longer being subject to a snapshot, data at that location is not preserved before being replaced upon a write to that location even if there was a snapshot taken of the volume between the time that the omit command was made and the subsequent write occurred.”).
As pointed out hereinabove, Green is an analogous art to the claimed invention. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Green into the combined teachings of Beale, Ahmed, Liu, and Kuchibhotla to include “wherein pausing the execution of the workflow application comprises deleting at least one pending command from the workflow application, wherein the snapshot does not include the at least one pending command.” The modification would be obvious because one of ordinary skill in the art would be motivated to not preserve a command in a snapshot when the command is identified as no longer needed (Green, paragraph [0129]).
Claims 4-7, 19, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Beale in view of Ahmed, Liu, and Kuchibhotla as applied to Claims 1 and 17 above, and further in view of US 2005/0012749 (hereinafter “Gonzalez”).
Examiner’s Remarks: In order for a reference to be proper for use in an obviousness rejection under 35 U.S.C. § 103, the reference must be analogous art to the claimed invention. In re Bigio, 381 F.3d 1320, 1325, 72 USPQ2d 1209, 1212 (Fed. Cir. 2004). A reference is analogous art to the claimed invention if: (1) the reference is from the same field of endeavor as the claimed invention (even if it addresses a different problem); or (2) the reference is reasonably pertinent to the problem faced by the inventor (even if it is not in the same field of endeavor as the claimed invention). See MPEP § 2141.01(a)(I).
Note that the claimed invention is generally directed to providing efficient implementation of firmware updates on GPUs in a data center, while reducing disruption to workflows associated with certain workflow application (specification, paragraph [0007]). As for the “reasonably pertinent” test, Gonzalez is generally directed to processing of graphics instructions in computers (specification, paragraph [0001]). Thus, Gonzalez is an analogous art to the claimed invention (even if it addresses a different problem).
As per Claim 4, the rejection of Claim 1 is incorporated; and Beale further discloses:
[…] wherein the firmware update is accessible […] from a firmware orchestrator (paragraph [0045], “In the context of the computing system 100 of FIG. 1, the update operation 218 can be managed by the console program 116; however, alternative mechanisms could be used as well, for example through cooperative use of the native shell 112 or other native programs for updating and registering use of the updated firmware.”).
The combination of Beale, Ahmed, Liu, and Kuchibhotla does not explicitly disclose:
wherein the GPU corresponds to a primary GPU.
However, Gonzalez discloses:
wherein the GPU corresponds to a primary GPU (paragraph [0008], “One GPU is designated as a ‘primary’ GPU and the other as a ‘secondary’ GPU.”).
As pointed out hereinabove, Gonzalez is an analogous art to the claimed invention. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Gonzalez into the combined teachings of Beale, Ahmed, Liu, and Kuchibhotla to include “wherein the GPU corresponds to a primary GPU.” The modification would be obvious because one of ordinary skill in the art would be motivated to allow a single GPU to transfer a firmware update (Gonzalez, paragraph [0008]).
As per Claim 5, the rejection of Claim 4 is incorporated; and the combination of Beale, Ahmed, Liu, and Kuchibhotla discloses “the OS driver causes the execution of the workflow application,” and Beale further discloses:
receiving an indication of the completion of the firmware update […], and […] resume based on the indication of the completion (paragraph [0046], “In the embodiment shown in FIG. 1, the update operation 218 starts execution of the new firmware using the customized, initial stack generated using the initial stack building operation 206, which involves both initial, startup operations generally performed by a system organized according stack-based non-native architecture, and the various custom operations included in the stack. This generally includes restarting use of the halted partition using the updated firmware, thereby allowing the operating system to resume operation from where the previous firmware left off, thereby restarting operation of the firmware within the partition.”).
Beale discloses “the firmware update,” but the combination of Beale, Ahmed, Liu, and Kuchibhotla does not explicitly disclose:
wherein the primary GPU communicates the firmware update to a neighboring GPU.
However, Gonzalez discloses:
wherein the primary GPU communicates [information] to a neighboring GPU (paragraph [0008], “One GPU is designated as a ‘primary’ GPU and the other as a ‘secondary’ GPU. Although both GPUs independently process graphics commands that derive from an API, the secondary GPU must still route the information it processes (i.e., the digital representation for the portion of the screen assigned to it) through the primary GPU which, in turn, transfers a single, combined output video signal to the video display device.”).
As pointed out hereinabove, Gonzalez is an analogous art to the claimed invention. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Gonzalez into the combined teachings of Beale, Ahmed, Liu, and Kuchibhotla to include “wherein the primary GPU communicates the firmware update to a neighboring GPU.” The modification would be obvious because one of ordinary skill in the art would be motivated to allow a single GPU to transfer a firmware update (Gonzalez, paragraph [0008]).
As per Claim 6, the rejection of Claim 1 is incorporated; and the combination of Beale, Ahmed, Liu, and Kuchibhotla discloses “the OS driver,” but the combination of Beale, Ahmed, Liu, and Kuchibhotla does not explicitly disclose:
wherein the GPU comprises a communication interface, wherein the GPU communicates with the OS driver via the communication interface.
However, Gonzalez discloses:
wherein the GPU comprises a communication interface, wherein the GPU communicates […] via the communication interface (paragraph [0005], “As a result, every application that sought to utilize the high level functions of a GPU-based video card required a specialized piece of software, commonly referred to as a ‘driver’, which could understand the GPU’s ‘language.’ With hundreds of different GPU-based video cards on the market, application developers became bogged down in writing these specialized drivers.”; paragraph [0008], “One GPU is designated as a ‘primary’ GPU and the other as a ‘secondary’ GPU. Although both GPUs independently process graphics commands that derive from an API, the secondary GPU must still route the information it processes (i.e., the digital representation for the portion of the screen assigned to it) through the primary GPU which, in turn, transfers a single, combined output video signal to the video display device.”).
As pointed out hereinabove, Gonzalez is an analogous art to the claimed invention. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Gonzalez into the combined teachings of Beale, Ahmed, Liu, and Kuchibhotla to include “wherein the GPU comprises a communication interface, wherein the GPU communicates with the OS driver via the communication interface.” The modification would be obvious because one of ordinary skill in the art would be motivated to allow a single GPU to transfer a firmware update (Gonzalez, paragraph [0008]).
As per Claim 7, the rejection of Claim 6 is incorporated; and Beale further discloses:
wherein the request to perform the firmware update is received from a firmware orchestrator (paragraph [0045], “In the context of the computing system 100 of FIG. 1, the update operation 218 can be managed by the console program 116; however, alternative mechanisms could be used as well, for example through cooperative use of the native shell 112 or other native programs for updating and registering use of the updated firmware.”).
The combination of Beale, Liu, Kuchibhotla, and Gonzalez does not explicitly disclose:
wherein the node comprises a second GPU that does not have the communication interface, wherein the second GPU not having the communication interface is unable to receive the request to perform the firmware update from the firmware orchestrator.
However, Ahmed discloses:
wherein the node comprises a second GPU that does not have the communication interface, wherein the second GPU not having the communication interface is unable to receive the request to perform the firmware update from the firmware orchestrator (paragraph [0049]1, “Hosted OS 1032 operates to manage the runtime aspects of hosted environment 1030, to launch programs and applications on host processing complex 1020, and to launch, manage, maintain, and halt workloads on GPUs 1024 and 1026. For example, after a hot-plug event, a replacement GPU can be reset by hot-plug control module 1028, and hosted OS can detect the presence of the replacement GPU, and launch a workload on the replacement GPU.”; paragraph [0054], “[…] GPU interface module 1042 directs GPU handler module 1036 to retrieve the requested information from hosted environment 1030, from hosted OS 1032, or directly from the selected one of GPUs 1024 and 1026, and to provide the retrieved information to the GPU interface module.”).
1Examiner’s Remarks: Note that Ahmed discloses that the hosted OS launches, manages, maintains, and halts workloads on GPUs. And that the GPUs provide requested information to the GPU interface module. Thus, one of ordinary skill in the art would readily comprehend that the hosted OS does not communicate with an GPU not having a communication interface.
As pointed out hereinabove, Ahmed is an analogous art to the claimed invention. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Ahmed into the combined teachings of Beale, Liu, Kuchibhotla, and Gonzalez to include “wherein the node comprises a second GPU that does not have the communication interface, wherein the second GPU not having the communication interface is unable to receive the request to perform the firmware update from the firmware orchestrator.” The modification would be obvious because one of ordinary skill in the art would be motivated to utilize graphics co-processors to offload various compute intensive tasks and services from main processor stack (Ahmed, paragraph [0048]).
As per Claim 19, the rejection of Claim 17 is incorporated; and Beale further discloses:
[…] wherein the firmware update is accessible […] from a firmware orchestrator (paragraph [0045], “In the context of the computing system 100 of FIG. 1, the update operation 218 can be managed by the console program 116; however, alternative mechanisms could be used as well, for example through cooperative use of the native shell 112 or other native programs for updating and registering use of the updated firmware.”).
The combination of Beale, Ahmed, Liu, and Kuchibhotla does not explicitly disclose:
wherein the GPU corresponds to a primary GPU.
However, Gonzalez discloses:
wherein the GPU corresponds to a primary GPU (paragraph [0008], “One GPU is designated as a ‘primary’ GPU and the other as a ‘secondary’ GPU.”).
As pointed out hereinabove, Gonzalez is an analogous art to the claimed invention. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Gonzalez into the combined teachings of Beale, Ahmed, Liu, and Kuchibhotla to include “wherein the GPU corresponds to a primary GPU.” The modification would be obvious because one of ordinary skill in the art would be motivated to allow a single GPU to transfer a firmware update (Gonzalez, paragraph [0008]).
As per Claim 20, the rejection of Claim 19 is incorporated; and the combination of Beale, Ahmed, Liu, and Kuchibhotla discloses “the OS driver causes the execution of the workflow application,” and Beale further discloses:
receiving an indication of the completion of the aspect of the firmware update […], and […] resume based on the indication of the completion (paragraph [0046], “In the embodiment shown in FIG. 1, the update operation 218 starts execution of the new firmware using the customized, initial stack generated using the initial stack building operation 206, which involves both initial, startup operations generally performed by a system organized according stack-based non-native architecture, and the various custom operations included in the stack. This generally includes restarting use of the halted partition using the updated firmware, thereby allowing the operating system to resume operation from where the previous firmware left off, thereby restarting operation of the firmware within the partition.”).
Beale discloses “the firmware update,” but the combination of Beale, Ahmed, Liu, and Kuchibhotla does not explicitly disclose:
wherein the primary GPU communicates the firmware update to a neighboring GPU.
However, Gonzalez discloses:
wherein the primary GPU communicates [information] to a neighboring GPU (paragraph [0008], “One GPU is designated as a ‘primary’ GPU and the other as a ‘secondary’ GPU. Although both GPUs independently process graphics commands that derive from an API, the secondary GPU must still route the information it processes (i.e., the digital representation for the portion of the screen assigned to it) through the primary GPU which, in turn, transfers a single, combined output video signal to the video display device.”).
As pointed out hereinabove, Gonzalez is an analogous art to the claimed invention. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Gonzalez into the combined teachings of Beale, Ahmed, Liu, and Kuchibhotla to include “wherein the primary GPU communicates the firmware update to a neighboring GPU.” The modification would be obvious because one of ordinary skill in the art would be motivated to allow a single GPU to transfer a firmware update (Gonzalez, paragraph [0008]).
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Beale in view of Ahmed, Liu, Kuchibhotla, and Gonzalez as applied to Claim 6 above, and further in view of US 2016/0239370 (hereinafter “Chen”).
Examiner’s Remarks: In order for a reference to be proper for use in an obviousness rejection under 35 U.S.C. § 103, the reference must be analogous art to the claimed invention. In re Bigio, 381 F.3d 1320, 1325, 72 USPQ2d 1209, 1212 (Fed. Cir. 2004). A reference is analogous art to the claimed invention if: (1) the reference is from the same field of endeavor as the claimed invention (even if it addresses a different problem); or (2) the reference is reasonably pertinent to the problem faced by the inventor (even if it is not in the same field of endeavor as the claimed invention). See MPEP § 2141.01(a)(I).
Note that the claimed invention is generally directed to providing efficient implementation of firmware updates on GPUs in a data center, while reducing disruption to workflows associated with certain workflow application (specification, paragraph [0007]). As for the “reasonably pertinent” test, Chen is generally directed to providing a rack having automatic recovery function (specification, paragraph [0011]). Thus, Chen is an analogous art to the claimed invention (even if it addresses a different problem).
As per Claim 8, the rejection of Claim 6 is incorporated; and the combination of Beale, Ahmed, Liu, and Kuchibhotla discloses “the GPU,” but the combination of Beale, Ahmed, Liu, Kuchibhotla, and Gonzalez does not explicitly disclose:
wherein the request to perform the firmware update is received from a firmware orchestrator via a baseboard management controller (BMC) of the node, wherein the request is accessed within the node by the GPU from the BMC.
However, Chen discloses:
wherein the request to perform the firmware update is received from a firmware orchestrator via a baseboard management controller (BMC) of the node, wherein the request is accessed within the node […] from the BMC (paragraph [0020], “The control module 2 and the nodes 3 are respectively arranged in the rack 1, and the control module 2 is electrically connected with each node 3. As a result, the RMC 22 in the control module 2 can communicate with each BMC 32 in each node 3, and can control all of the nodes 3, collect information from the nodes 3 and transmit necessary files (for example, updated file for updating a firmware) to the nodes 3 via the BMCs 32.”).
As pointed out hereinabove, Chen is an analogous art to the claimed invention. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Chen into the combined teachings of Beale, Ahmed, Liu, Kuchibhotla, and Gonzalez to include “wherein the request to perform the firmware update is received from a firmware orchestrator via a baseboard management controller (BMC) of the node, wherein the request is accessed within the node by the GPU from the BMC.” The modification would be obvious because one of ordinary skill in the art would be motivated to collect information from nodes and transmit necessary files (for example, updated file for updating a firmware) to the nodes via BMCs (Chen, paragraph [0020]).
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Beale in view of Ahmed, Liu, and Kuchibhotla as applied to Claim 11 above, and further in view of US 2012/0188270 (hereinafter “Diard”).
Examiner’s Remarks: In order for a reference to be proper for use in an obviousness rejection under 35 U.S.C. § 103, the reference must be analogous art to the claimed invention. In re Bigio, 381 F.3d 1320, 1325, 72 USPQ2d 1209, 1212 (Fed. Cir. 2004). A reference is analogous art to the claimed invention if: (1) the reference is from the same field of endeavor as the claimed invention (even if it addresses a different problem); or (2) the reference is reasonably pertinent to the problem faced by the inventor (even if it is not in the same field of endeavor as the claimed invention). See MPEP § 2141.01(a)(I).
Note that the claimed invention is generally directed to providing efficient implementation of firmware updates on GPUs in a data center, while reducing disruption to workflows associated with certain workflow application (specification, paragraph [0007]). As for the “reasonably pertinent” test, Diard is generally directed to blending rendered images from multiple applications (specification, paragraph [0003]). Thus, Diard is an analogous art to the claimed invention (even if it addresses a different problem).
As per Claim 12, the rejection of Claim 11 is incorporated; and Beale discloses “the firmware update,” but the combination of Beale, Ahmed, Liu, and Kuchibhotla does not explicitly disclose:
accessing a respective tagging for a plurality of GPUs; and
determining, from the plurality of GPUs, which GPU of the plurality of GPUs has a respective tagging indicative of a primary GPU tagging, and wherein the request to perform the firmware update is transmitted to the GPU having the respective tagging indicative of the primary GPU tagging for communication to neighboring GPUs not having the respective tagging.
However, Diard discloses:
accessing a respective tagging for a plurality of GPUs (paragraph [0022], “The graphics subsystem 314 includes a first and a second graphics adapters 315 and 317, each with a single GPU, namely primary GPU 326 and secondary GPU 332, respectively.”); and
determining, from the plurality of GPUs, which GPU of the plurality of GPUs has a respective tagging indicative of a primary GPU tagging (paragraph [0022], “The graphics subsystem 314 includes a first and a second graphics adapters 315 and 317, each with a single GPU, namely primary GPU 326 and secondary GPU 332, respectively.”), and wherein the request to perform […] is transmitted to the GPU having the respective tagging indicative of the primary GPU tagging for communication to neighboring GPUs not having the respective tagging (paragraph [0028], “Using the computing device 400 to illustrate such a process, the primary GPU 426 and the secondary GPU 432 perform the rendering operations associated with two different applications independently in steps 450 and 452, respectively. In one implementation, the computing device 400 allocates a block of memory from system memory 402 for use as a temporary buffer 406. When a secondary GPU 432 renders a frame associated with the application B, the application B requests to flip this rendered frame by transmitting it to the temporary buffer 406 in step 454. After the primary GPU 426 renders the frame associated with the application A, it then pulls the rendered image from the temporary buffer 406, applies the appropriate blending weights to the two rendered images, and blends the two weighted images in step 456. Here, the primary GPU 426 treats the rendered frame from the secondary GPU 432 as texture. In one implementation, the primary GPU 426 stores the blended results in a primary frame buffer in video memory 428 to be scanned out to a display device 438. It should be noted that the resources of the chipset 412 and also the primary GPU 426 in this implementation are utilized to carry out the blending operation.”).
As pointed out hereinabove, Diard is an analogous art to the claimed invention. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Diard into the combined teachings of Beale, Ahmed, Liu, and Kuchibhotla to include “accessing a respective tagging for a plurality of GPUs; and determining, from the plurality of GPUs, which GPU of the plurality of GPUs has a respective tagging indicative of a primary GPU tagging, and wherein the request to perform the firmware update is transmitted to the GPU having the respective tagging indicative of the primary GPU tagging for communication to neighboring GPUs not having the respective tagging.” The modification would be obvious because one of ordinary skill in the art would be motivated to execute commands and certain tasks, which are defined by the commands, by GPUs (Diard, paragraph [0023]).
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Beale in view of Ahmed, Liu, and Kuchibhotla as applied to Claim 11 above, and further in view of US 2016/0239370 (hereinafter “Chen”).
As per Claim 14, the rejection of Claim 11 is incorporated; and the combination of Beale, Ahmed, Liu, and Kuchibhotla discloses “the OS driver,” but the combination of Beale, Ahmed, Liu, and Kuchibhotla does not explicitly disclose:
receiving, from a firmware orchestrator, software associated with the firmware update, wherein the request to perform the firmware update is transmitted, via the OS driver to a baseboard management controller (BMC) of the node.
However, Chen discloses:
receiving, from a firmware orchestrator, software associated with the firmware update, wherein the request to perform the firmware update is transmitted, […] to a baseboard management controller (BMC) of the node (paragraph [0020], “The control module 2 and the nodes 3 are respectively arranged in the rack 1, and the control module 2 is electrically connected with each node 3. As a result, the RMC 22 in the control module 2 can communicate with each BMC 32 in each node 3, and can control all of the nodes 3, collect information from the nodes 3 and transmit necessary files (for example, updated file for updating a firmware) to the nodes 3 via the BMCs 32.”).
As pointed out hereinabove, Chen is an analogous art to the claimed invention. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Chen into the combined teachings of Beale, Ahmed, Liu, and Kuchibhotla to include “receiving, from a firmware orchestrator, software associated with the firmware update, wherein the request to perform the firmware update is transmitted, via the OS driver to a baseboard management controller (BMC) of the node.” The modification would be obvious because one of ordinary skill in the art would be motivated to collect information from nodes and transmit necessary files (for example, updated file for updating a firmware) to the nodes via BMCs (Chen, paragraph [0020]).
Response to Arguments
Applicant’s arguments filed on June 24, 2026 with respect to the 35 U.S.C. § 103 rejections of the claims have been fully considered, but they are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the Applicant’s arguments.
In the Remarks, the Applicant argues:
The amended claim is materially different. Amended claim 1 does not merely require preserving a general partition state or resuming operation after a firmware update. Rather, amended claim 1 requires causing the OS driver to resume execution of the workflow application by restoring the HBM with workflow-related content from the snapshot, such that the workflow application resumes execution based on the workflow-related content restored to the HBM. Thus, the amended claim requires a specific GPU-memory restoration operation after completion of the firmware update.
[…]
Accordingly, even if Beale teaches preserving a partition state during a firmware update, Ahmed teaches GPU workload management, and Liu teaches that GPUs may include HBM, the cited combination still fails to teach or suggest the amended limitation requiring restoration of GPU HBM with workflow-related content from the snapshot and resumption of the workflow application based on the workflow-related content restored to the HBM.
The proposed amendment therefore clarifies that the claimed resume operation is not merely a generic restart or continuation from preserved state. Instead, the OS driver resumes the workflow application by restoring GPU HBM with workflow-related content from the snapshot, such that the workflow application resumes execution based on the restored HBM content. This refinement introduces a concrete structural and operational distinction absent from the cited combination.
(See Remarks – pages 5-7.)
Examiner’s response:
Examiner respectfully disagrees. With respect to the Applicant’s assertion that “[…] amended claim 1 requires causing the OS driver to resume execution of the workflow application by restoring the HBM with workflow-related content from the snapshot, such that the workflow application resumes execution based on the workflow-related content restored to the HBM. Thus, the amended claim requires a specific GPU-memory restoration operation after completion of the firmware update,” the Applicant’s arguments are not persuasive for at least the following reasons:
First, the Examiner respectfully submits the relevant portions of MPEP § 2145(VI) and 37 CFR § 1.75(a) with emphasis added for purposes of convenience in discussion and illustration:
MPEP § 2145(VI) ARGUING LIMITATIONS WHICH ARE NOT CLAIMED
Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993) (Claims to a superconducting magnet which generates a “uniform magnetic field” were not limited to the degree of magnetic field uniformity required for Nuclear Magnetic Resonance (NMR) imaging. Although the specification disclosed that the claimed magnet may be used in an NMR apparatus, the claims were not so limited.); Constant v. Advanced Micro-Devices, Inc., 848 F.2d 1560, 1571-72, 7 USPQ2d 1057, 1064-1065 (Fed. Cir.), cert. denied, 488 U.S. 892 (1988) (Various limitations on which appellant relied were not stated in the claims; the specification did not provide evidence indicating these limitations must be read into the claims to give meaning to the disputed terms.); Ex parte McCullough, 7 USPQ2d 1889, 1891 (Bd. Pat. App. & Inter. 1987) (Claimed electrode was rejected as obvious despite assertions that electrode functions differently than would be expected when used in nonaqueous battery since “although the demonstrated results may be germane to the patentability of a battery containing appellant’s electrode, they are not germane to the patentability of the invention claimed on appeal.”).
37 CFR § 1.75(a) Claim(s).
(a) The specification must conclude with a claim particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention or discovery.
According to the portions of the MPEP and the patent rule provided hereinabove, the Examiner would like to point out that the Applicant’s arguments are not commensurate in scope with the claim language. The limitations on which the Applicant relies (i.e., causing the OS driver to resume execution of the workflow application by restoring the HBM with workflow-related content from the snapshot, such that the workflow application resumes execution based on the workflow-related content restored to the HBM) are not explicitly recited in the claims. In particular, the claims do not recite causing the OS driver to resume execution of the workflow application and workflow-related content. Rather, Claim 1, for example, only requires “restoring, after completion of the firmware update, the HBM with content from the snapshot, wherein the workflow application resumes execution based on the content restored to the HBM.” Applicant is reminded that in order for such limitations to be considered, the claims are required to explicitly recite such limitations, otherwise broadest reasonable interpretations of the broadly claimed limitations are deemed to be proper.
Second, the Examiner respectfully submits that the combination of Beale, Ahmed, Liu, and Kuchibhotla discloses “restoring, after completion of the firmware update, the HBM with content from the snapshot, wherein the workflow application resumes execution based on the content restored to the HBM.” See the 35 U.S.C. § 103 rejection of Claim 1 hereinabove.
Therefore, for at least the reasons set forth above, the rejection made under 35 U.S.C. § 103 with respect to Claim 1 is proper.
As the 35 U.S.C. § 103 rejection of independent Claim 1 is maintained for at least the reasons stated hereinabove, the rejections with respect to the remaining independent claims are also maintained for at least the identical reasons set forth hereinabove, and the rejections with respect to their dependent claims are also maintained since the Applicant has not pointed out any further deficiencies of the 35 U.S.C. § 103 rejections with respect to their dependent claims.
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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the Examiner should be directed to Qing Chen whose telephone number is 571-270-1071. The Examiner can normally be reached on Monday through Friday from 9:00 AM to 5:00 PM ET.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, the Applicant is encouraged to use the USPTO Automated Interview Request (AIR) at https://www.uspto.gov/ interviewpractice.
If attempts to reach the Examiner by telephone are unsuccessful, the Examiner’s supervisor, Wei Mui, can be reached at 571-272-3708. 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 more 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.
/Qing Chen/
Primary Examiner, Art Unit 2191
Prosecution Insights