DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This action is in response to the application filed on 09/24/2024.
Priority
Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d). The certified copy has been filed in parent Application No. CN202211516606.1, filed on 11/30/2022. Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 09/24/2024 is in compliance with the provisions of 37 CFR 1.97 and is being considered by the examiner.
Examiner’s Notes
Examiner cites particular paragraphs, figures, and line number in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part
Claim Objections
Claims 1-17 , 19, and 20 are objected to because of the following informalities:
In Claim 1, line 1, “BMC” should be changed to --BMC (baseboard management controller)--.
In Claim 2, replace “a target” in line 1, “an installation” and “a target image” in line 2, and “a target device” in line 3 with --the target--, --the installation--, --a target image--, and --the target device--, respectively.
In Claim 3, replace “a target” in line 1, “an installation” in lie 2, and “a target device” in line 3 with --the target--, --the installation--, and --the target device--, respectively.
Claims 4-17, 19, and 20 also objected to based on their dependency to the objected claim.
Appropriate correction is required.
Claim Rejections - 35 USC § 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.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 4-17 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
In lines 4-5 of Claim 4, line 3 of Claim 6, line 5 of Claim 7, line 4 of Claim 8, line 3 of Claim 9, line 3 of Claim 14, and lines 1-2 of Claim 15, “the current image” lacks antecedent basis and should be corrected to --a current image--. Or, Claims 4, 6-9, 14, and 15 becoming dependent on Claim 2 may also solve this issue. For the purposes of examination, “the current image” of Claims 4, 6-9, 14, and 15, will be treated as --a current image--.
In Claim 6, line 3, “the file format” and “the received image file” lack proper antecedent basis.
In Claim 7, line 3, “the version” and “the target image file” lack proper antecedent basis.
In Claim 8, line 2, “the version” and “the image file” lack proper antecedent basis.
In Claim 9, line 2, “the converted file” lacks antecedent basis and should be corrected to --a converted file. Or, Claim 9 becoming dependent on Claim 8 may also solve this issue. For the purposes of examination, “the converted file” of Claim 9, line 2, will be treated as --a converted file--.
In Claim 10, line 3, “the size” should be changed to --a size--.
In Claim 11, line 2 “the memory” should be changed to --a memory--. As a result, lines 2-3 of Claim 13, “the memory” will have proper antecedent basis.
In Claim 13, line 2, “the memory” lacks proper antecedent basis. For the purposes of examination, the examiner will assume the above correction to --a memory-- in Claim 11.
In Claim 15, line 2, “the compressed format” should be changed to --a compressed format--. Or, Claim 15 should depend on Claim 14 in order for “the compressed format” to have proper antecedent basis. For the purposes of examinations, the examiner will treat “the compressed format” in Claim 15 as --a compressed format--.
In Claim 16, line 2, “the backup memory” should be changed to --a backup memory --. Or, Claim 16 should depend on Claim 15 in order for “the backup memory” to have proper antecedent basis. For the purposes of examinations, the examiner will treat “the backup memory” in Claim 16 as --a backup memory --.
In Claim 17, line 2, “the backup memory” should be changed to --a backup memory --. Or, Claim 17 should depend on Claim 15 in order for “the backup memory” to have proper antecedent basis. For the purposes of examinations, the examiner will treat “the backup memory” in Claim 16 as --a backup memory --. Line 3, “the main memory” lacks proper antecedent basis.
Claim 5 depends on the rejected Claim 4; Claim 12 depends on the rejected Claim 11. Therefore, Claims 5 and 12 are also rejected under 112(b) based on their dependency.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-5 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Ramachandra et al. (U.S. Publication No. 20240036896 A1, hereinafter Ramachandra) in view of Maddukuri et al. (U.S. Publication No. 20220398320 A1, hereinafter Maddukuri).
Regarding Claim 1:
Ramachandra discloses, method
“generating a target image installation program based on an installation method of a target image” (As stated in the Abstract, “Multiple installation images can be generated for different data processing units having varying requirements in a heterogeneous environment”. In paragraph [0016], “The orchestrator 128 can also oversee provisioning of one or more DPU 106 of the host machine 103 utilizing the DPU installation file 123, from which platform specific DPU installation images can be generated depending upon the requirements of the particular DPU 106”. Where the image installation program is mapped to the DPU installer image 139, in paragraph [0023], “A DPU installer image 139 can be generated by the orchestrator 128 from the DPU installation file 123 depending upon the requirements of the hardware manufacturer, the DPU firmware 133, and/or the DPU installer image 139”, in paragraph [0023], “The DPU installer image 139 represents a disk image containing a copy of the current version of the DPU operating system 129 to be executed by the DPU 106”. The DPU installer image 139 is a portable program used for installation, in paragraph [0024], “The orchestrator 128 can manage the installation process of a DPU installer image 139 on a DPU 106”. In paragraph [0024], “In one example, the orchestrator 128 can create or provide an installation executable or image that can be installed by the DPU bootloader 136 or another process on the DPU 106. The installation executable or image can be the DPU installer image 139 that is provided to the DPU 106 to provision a DPU operating system 129 on the DPU 106”.);
“and sending the target image installation program to a target device” (The DPU 106 is mapped as the claimed target device. In paragraph [0041], “At step 219, the DPU 106 can download the DPU installer image 139 provided by the server process created by the orchestrator 128”. Where the download is made possible, in other words, for the installation program (DPU installer image 139) to be sent to the target device (DPU 106) via a server process, as explained in paragraph [0039], “the orchestrator 128 can create a server process for each DPU 106 in the host machine. In another implementation, the orchestrator 128 can create a single server process that can handle requests from multiple DPU 106 that are utilizing the same format of DPU installer image 139”.);
“and sending, in response to the execution of the target image installation program, the target image to the target device” (Once the DPU installer image 139 is executed by the DPU bootloader 136 In paragraph [0022], “The DPU bootloader 136 can represent a program responsible for booting the DPU operating system 129 in response to the DPU 106 being powered on. Once execution of the DPU bootloader 136 is initiated, the bootloader can select either the DPU installer image 139 or a DPU alternate boot image to boot the DPU operating system 129”. In paragraph [0037], “The host operating system 113 or the orchestrator 128 can continue execution of a host machine 103 installation flow that installs a host operating system 113 on the host machine 103”.
To further clarify that the mapped DPU installer image 139 is specifically executed, the execution is disclosed in paragraph [0050], ““executable” means a program file that is in a form that can ultimately be run by the processor”, and in paragraph [0024], “The installation executable or image can be the DPU installer image 139 that is provided to the DPU 106 to provision a DPU operating system 129 on the DPU 106”. The provisioning is the delivery of the DPU installer image 139 to the DPU operating system 129 via the DPU 106. The DPU installer image is executed by the bootloader, in regard to the above mapping of paragraph [0022], additionally supported in paragraph [0041], “The DPU installer image 139 can represent an installation image that can be installed by the DPU bootloader 136 or another provisioning service on the DPU 106”.);
“and installing the target image onto the target device through the target image installation program” (In paragraph [0042], “At step 221, the DPU 106 can initiate a DPU installation flow. The DPU installation flow can represent an installer that installs and configures an DPU operating system 129 onto the DPU 106 … The DPU installer workflow can install a DPU operating system 129 onto the DPU 106 that the DPU bootloader 136 can boot whenever DPU 106 is powered up or rebooted”. Where the DPU bootloader 136 may select the program from DPU installer image 139, in paragraph [0022], “Once execution of the DPU bootloader 136 is initiated, the bootloader can select either the DPU installer image 139 or a DPU alternate boot image to boot the DPU operating system 129”.).
Ramachandra does not disclose however Maddukuri discloses,
“A method for upgrading BMC heterogeneous, comprising” (In paragraph [0013], “FIG. 7 illustrates an example BMC firmware stack firmware update method that may be performed to install or flash a new BMC firmware stack image according to one embodiment of the present disclosure”.).
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Ramachandra by adopting the teachings of Maddukuri in the method of updating BMC, motivated by the common goal to improve the common drawbacks that occur when transitioning a BMC to OpenBMC standards, according to user-specific computing environments (Maddukuri [0020], [0023]).
Regarding Claim 2:
Ramachandra further discloses,
“wherein the generating a target image installation program based on an installation method of a target image, and sending the target image installation program to a target device comprises: embedding, based on a current image of the target device, the target image installation program into the current image to generate a temporary image” (Where the image installation program is mapped to the DPU installer image 139 as in claim 1, the DPU installer image is specified represent an image, in paragraph [0023], “The DPU installer image 139 represents a disk image containing a copy of the current version of the DPU operating system 129 to be executed by the DPU 106”. Where the DPU installer image has an installer embedded, In paragraph [0032], “The kickstart file for each DPU 106 can include instructions or commands that execute an installer process for a installer embedded within a DPU installer image 139”. The DPU installer image 139 is specified to be a program as supported in paragraph [0050], ““executable” means a program file that is in a form that can ultimately be run by the processor”, and in paragraph [0024], “The installation executable or image can be the DPU installer image 139”.
An image is generated in response to the embedded target image installation program within the image in paragraph [0033], “At step 209, the orchestrator 128 can generate a DPU installer image 139”, the image within DPU installer image 139 is sent to the DPU 106 via download, in paragraph [0041], “At step 219, the DPU 106 can download the DPU installer image 139 provided by the server process created by the orchestrator 128 … The DPU installer image 139 can represent an ISO image, a DD file, a PXE file, or an executable file”, which are then deleted in paragraph [0047], “The server process can be stopped upon completion of the DPU installation flow for the respective DPU 106 that obtained the DPU installer image 139 from the orchestrator 128. At step 225, the orchestrator 128 can delete the hosted DPU installer image 139”. Because the DPU installer image 139 is deleted, where DPU installer image 139 contains the image, the DPU installer image 139 is temporary.).
Regarding Claim 3:
Ramachandra further discloses,
“wherein the generating a target image installation program based on an installation method of a target image, and sending the target image installation program to a target device comprises: sending the temporary image to the target device and installing the temporary image onto the target device through an image system currently running on the target device” (Where the DPU installer image 139 is also temporary, as disclosed by the deletion in paragraph [0047], “At step 225, the orchestrator 128 can delete the hosted DPU installer image 139”. The DPU installer image 139 is sent to the target device DPU 106, in paragraph [0047], “the DPU installation flow for the respective DPU 106 that obtained the DPU installer image 139”. The image is installed based on the current operating system running on the DPU, in paragraph [0032], “At step 206, the orchestrator 128 can generate a kickstart file for each DPU 106 based upon the DPU inventory obtained at step 203. A kickstart file can represent an installation script that can guide the installation workflow to install and configure a DPU operating system 129 on a respective DPU 106… The kickstart file for each DPU 106 can include instructions or commands that execute an installer process for a installer embedded within a DPU installer image 139”.).
Regarding Claim 4:
Ramachandra further discloses,
“wherein the sending, in response to the execution of the target image installation program, the target image to the target device comprises: packaging, based on a file format of the current image, a file format of the target image into the same file format as the current image” (In paragraph [0039], “the orchestrator 128 can create a single server process that can handle requests from multiple DPU 106 that are utilizing the same format of DPU installer image 139”. The current DPUs are ensured to receive DPU installer images are generated in the same format necessary Further in paragraph [0034], “The orchestrator 128 can generate a DPU installer image 139 according to a format associated with the requirements of a particular DPU 106. For example, a DPU from one manufacturer might require an ISO file, a DD file, a preboot execution environment (PXE) file, an MSI file, or another file format that a bootloader, firmware, or preloaded operating system can utilize to provision or configure the DPU”.).
Regarding Claim 5:
Ramachandra further discloses,
“wherein the sending, in response to the execution of the target image installation program, the target image to the target device comprises” (In paragraph [0022], “The DPU bootloader 136 can represent a program responsible for booting the DPU operating system 129 in response to the DPU 106 being powered on. Once execution of the DPU bootloader 136 is initiated, the bootloader can select either the DPU installer image 139 or a DPU alternate boot image to boot the DPU operating system 129”. In paragraph [0037], “The host operating system 113 or the orchestrator 128 can continue execution of a host machine 103 installation flow that installs a host operating system 113 on the host machine 103”.);
“sending a packaged target image file to the target device” (In paragraph [0041], “At step 219, the DPU 106 can download the DPU installer image 139 … The DPU installer image 139 can represent an installation image that can be installed by the DPU bootloader 136 … The DPU installer image 139 can represent an ISO image, a DD file, a PXE file, or an executable file in a format that is compatible”.).
Regarding Claim 19:
Ramachandra further discloses,
“A computer device, comprising: at least one processor; and a memory, wherein the memory stores computer instructions executable on the processor, and the instructions, when executed by the processor, implement the steps of the method as claimed in claim 1” (In paragraph [0011], “The host machine 103 can include one or more processors, a memory, and/or a network interface”. In paragraph [0057], “one or more applications described herein can be executed in shared or separate computing devices or a combination thereof”. In paragraph [0055], “Also, any logic or application described herein that includes software or code can be embodied in any non-transitory computer-readable medium for use by or in connection with an instruction execution system such as a processor in a computer system or other system. In this sense, the logic can include statements including instructions and declarations that can be fetched from the computer-readable medium and executed by the instruction execution system. In the context of the present disclosure, a “computer-readable medium” can be any medium that can contain, store, or maintain the logic or application described herein for use by or in connection with the instruction execution system”. In paragraph [0056], “the computer-readable medium can be a random access memory (RAM) …or other type of memory device”.).
Regarding Claim 20:
Ramachandra further discloses,
“A non-transitory computer readable storage medium, wherein the non-transitory computer readable storage medium stores a computer program, and the computer program, when executed by a processor, implements the steps of the method as claimed in claim 1” (In paragraph [0055], “any logic or application described herein that includes software or code can be embodied in any non-transitory computer-readable medium for use by or in connection with an instruction execution system such as a processor in a computer system or other system. In this sense, the logic can include statements including instructions and declarations that can be fetched from the computer-readable medium and executed by the instruction execution system”.).
Claims 6-7 are rejected under 35 U.S.C. 103 as being unpatentable over Ramachandra in view of Maddukuri as applied to Claim 1 above, and further in view of Haryadi et al. (U.S. Publication No. 20210311716 A1, hereinafter Haryadi) and Chen et al. (U.S. Publication No. 20230367574 A1, hereinafter Chen).
Regarding Claim 6:
Ramachandra in view of Maddukuri does not disclose however Haryadi discloses,
“wherein the installing the target image onto the target device through the target image installation program comprises: parsing, [], the received image file through the target image installation program to obtain an identification code and a core file, and confirming that the target image is correct through the identification code” (The software specification 105 contains the information needed to composite a base image, in paragraph [0026], “Image manager 112 consumes software specification 105 to composite a desired image that is modeled as a hierarchical software stack, including (1) the base image”. Where the image manager is mapped as the claimed target image installation program, the image depot is mapped to the claimed core file, and the version number is mapped as the claimed identification code, in the context of Haryadi’s reference; The image manager then obtains the core file and version numbers by parsing the software specification, in paragraph [0038], “After software specification 105 is generated, image manager 112 parses it to determine the selections of the base image, add-on, solution, firmware package, and one or more user components made by the end user. Then, image manager 112 retrieves the metadata corresponding to the selected base image, the selected add-on, and the selected solution from image depot 120”. The firmware package contains the version number, supported in paragraph [0043], “The method of FIG. 5 begins at step 512 at which image manager 112 creates a list of firmware and drivers that are in desired image 125, along with their version numbers”. Note that the firmware package is parsed from the software specification, which may also be defined as a firmware manifest, the firmware manifest specifying the version numbers as supported in paragraph [0035], “OEMs also define the content of their firmware packages, in the form of a firmware manifest”, and in paragraph [0050], “version that that specified by the firmware manifest”. The version numbers are then used to confirm the image is correct, in paragraph [0044], “At step 520, image manager 112 retrieves version details of drivers and firmware of the selected device in the list created at step 512 … The version details of the drivers and firmware retrieved at step 520 and the version details of the drivers and firmware retrieved at step 522 are then compared at step 524. If there is a match, i.e., the version details of the drivers and firmware retrieved at step 520 can be found in the version details of the drivers and firmware retrieved at step 522, the selected device is marked as compatible at step 526”.
Note image manager installs the image in paragraph [0028], “image manager 152 installs desired image 125”, the image manager 152 being connected to the image manager 112 via API as shown in Figure 1 and in paragraph [0030], “With these APIs, the end user is able to manage the image of the virtualization software installed in hosts 131 and the firmware installed in hosts 131 from a single “pane of glass,” in this case, through UI 101 of VM management server 100”.).
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Ramachandra in view of Maddukuri by adopting the teachings of Haryadi; motivated by the common goal to improve the convenience of upgrade methods for customers according to system specific dependencies (Haryadi [0002], [0004], [0007]), and to prevent users from downloading incompatible update packages (Haryadi [0005], [0022]).
Ramachandra in view of Maddukuri and Haryadi does not disclose however Chen discloses,
“based on the file format of the current image” (The configuration file creates OS installation images, in paragraph [0033], “configuration files for creating different OS installation images”. The configuration file is based on the file format, in paragraph [0033], “The example configuration files include the version of OS components (e.g., vmlinuz, initramfs.img, firmware.tar.xz, and module.tar.xz), the system environment (e.g., root file system setting and environment configuration) … the bundle manager 210 first parses the content of the configuration file”. The parsing is based on the configuration file, thus the parsing is also based file format by the way of the configuration file.).
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Ramachandra in view of Maddukuri and Haryadi by adopting the teachings of Chen; motivated by the common goal to decrease the server downtime when enacting upgrades on firmware (Chen [0004]).
Regarding Claim 7:
Ramachandra in view of Maddukuri does not disclose however Haryadi further discloses,
“wherein the installing the target image onto the target device through the target image installation program comprises: installing, in response to confirming that the version of the target image file is not the target image based on the identification code, the target image based on an installation method of the current image” (The confirmation of the version is not the same when there is no match, as disclosed in paragraph [0044], “If there is a match, i.e., the version details of the drivers and firmware retrieved at step 520 can be found in the version details of the drivers and firmware retrieved at step 522, the selected device is marked as compatible at step 526. On the other hand, if there is no match, i.e., the version details of the drivers and firmware retrieved at step 520 cannot be found in the version details of the drivers and firmware retrieved at step 522, the selected device is marked as incompatible at step 528”. Where the incompatible firmware manifest may be marked as non-compliant in certain cases, in paragraph [0050], “In cases where hardware support manager 170 supports downgrading of the firmware, the firmware compliance report will indicate “non-compliant” instead of “incompatible”) if the host has installed therein firmware that is of a higher version that that specified by the firmware manifest”. A check is performed to confirm whether an upgrade install can be done, in paragraph [0052], “hardware support manager 170 at step S11 performs a check on each host 131 to determine whether or not the firmware in the host can be upgraded to the firmware specified by the firmware manifest in desired image 125 at that time”.
Figure 6 shows that when the image is in non-compliance, (i.e., does not match the required version number), then installs a current image in compliance. The following paragraphs explain the process further: In paragraph [0050], ““non-compliant” if the host has installed therein firmware that is of a lower version than that specified by the firmware manifest … If the compliance state is “non-compliant” for any host, the firmware compliance report for that host also indicates the impact on the host, i.e., whether the host needs to enter into a maintenance mode or needs to be rebooted”. In paragraph [0055], “After staging the payloads, coordinator 114 at step S17 instructs each host 131 to enter into maintenance mode if the cluster compliance report indicates that the maintenance mode is required to bring hosts 131 into compliance. In response to such an instruction (if issued), hosts 131 enter into maintenance mode”. In paragraph [0057], “At step S19, coordinator 114 instructs each host 131 to reboot if the cluster compliance report indicates that hosts 131 are required to be rebooted to bring the virtualization software in the host and the associated firmware into compliance”. In paragraph [0058], “In the embodiments, the end user carries out the process of FIG. 6 to “remediate” hosts 131. The remediation process may be executed, in one embodiment, to bring the cluster of hosts 131 back into compliance with the desired state of the virtualization software specified in software specification 105. In another embodiment, the process is carried out to deliver and install a new desired image of the virtualization software that is generated from software specification 105. The process of FIG. 6 includes the scan subprocess, the pre-check subprocess, the stage subprocess, and the apply subprocess”.).
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Ramachandra in view of Maddukuri by adopting the teachings of Haryadi; motivated by the common goal to improve the convenience of upgrade methods for customers according to system specific dependencies (Haryadi [0002], [0004], [0007]), and to prevent users from downloading incompatible update packages (Haryadi [0005], [0022]).
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Ramachandra in view of Maddukuri, Haryadi, and Chen as applied to Claim 6 above, and further in view of Kannan et al. (U.S. Publication No. 20200125352 A1, hereinafter Kannan).
Regarding Claim 8:
Ramachandra in view of Maddukuri, Haryadi, and Chen does not disclose however Kannan discloses,
“further comprising: converting, in response to confirming that the version of the image file is the target image based on the identification code, the core file into a predetermined format used by the current image” (The test image is mapped as the claimed core file being converted. The gold image is the current version of deployment, in paragraph [0069], “a gold image of a database having a base release 310”, the base release being the current version in paragraph [0049], “the base release version of the database software may be the same version as the version currently installed at a customer's site”. In paragraph [0057], “Upon successfully completing the testing of the test image, the test image is transformed into the requested format at 260 … Yet as another example, if the output type requested is a .ova file … all of the files starting from the home directory of the test image is archived/transformed into the .ova file format … The test image is converted into a .ova file to be deployed on virtual machines”. Note that the test image becomes a gold image once tested in paragraph [0063], “Zip 321 is an output type that zips up a fully tested test image as a gold image for deployment by the user”. The version compatibility is confirmed by RU identifiers when requested, in paragraph [0051], “The RU identifiers uniquely identifying which RUs have already been installed at the customer's site for the corresponding base release version requested”, further in paragraph [0052], “a conflict checker determines whether conflicts arise between the one-off patch updates (identified as one-off patch update identifiers), the release version of the software, and/or the RUs (identified as RU identifiers) … the conflict checker may resolve the conflict (if any) by removing any conflicted one-off patch update(s) and/or RU(s) from the list of requested one-off patch update(s) and/or RU(s) to be included in the building/creation of the test image that will eventually be converted to the gold image”.).
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Ramachandra in view of Maddukuri, Haryadi, and Chen by adopting the teachings of Kannan; motivated by the common goal to provide environment-specific support for upgrade installation; specifically, by improving computing functionality during an update (Kannan [0011], [0056]), by checking customer specific configuration to adapt to (Kannan [0008], [0040]), such as error detection in “patch updates provided by the vendor to help fix particular bugs/issues associated to a particular configuration of the database software that may be unique to the particular user” (Kannan [0071]). Additionally, Kannan is motivated to prevent manual processes done by the user to perform an upgrade, “the technological area of software upgrades is greatly improved from a manual process performed by each customer on a regular basis” (Kannan [0024]); similar to the examined case motivated to prevent the inconvenience caused by manual processes done by a worker to re-burn an OpenBMC update on a server, as described in lines 15-19 of page 2 in the examined case specification.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Ramachandra in view of Maddukuri, Haryadi, and Chen as applied to Claim 6 above, and further in view of Warkentin et al. (U.S. Publication No. 20230229480 A1, hereinafter Warkentin).
Regarding Claim 9:
Ramachandra in view of Maddukuri, Haryadi, and Chen does not disclose however Warkentin discloses,
“further comprising: writing the converted core file and other files in the target image into a main memory and/or a backup memory based on a write method of the current image” (In paragraph [0056], “In step 315, the DPU UEFI 163 can flash the DPU management OS image capsule 161 directly to memory … The contents of the DPU management OS image capsule 161 can be written byte-by-byte”.).
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Ramachandra in view of Maddukuri, Haryadi, and Chen by adopting the teachings in Warkentin; motivated by the common goal to improve the arrangements for program control using stored programs, such as using a BMC to manage the delivery of firmware updates (Warkentin [0011], [0037], [0035]).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Ramachandra in view of Maddukuri, Haryadi, Chen, and Kannan as applied to Claim 8 above, and further in view of Warkentin et al. (U.S. Publication No. 20230229480 A1, hereinafter Warkentin).
Regarding Claim 10:
Ramachandra in view of Maddukuri does not disclose however Haryadi further discloses,
“in response to confirming that the version of the image file is the target image based on the identification code” (In paragraph [0044], “At step 520, image manager 112 retrieves version details of drivers and firmware of the selected device in the list created at step 512 … The version details of the drivers and firmware retrieved at step 520 and the version details of the drivers and firmware retrieved at step 522 are then compared at step 524. If there is a match, i.e., the version details of the drivers and firmware retrieved at step 520 can be found in the version details of the drivers and firmware retrieved at step 522, the selected device is marked as compatible at step 526”.).
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Ramachandra in view of Maddukuri by adopting the teachings of Haryadi; motivated by the common goal to improve the convenience of upgrade methods for customers according to system specific dependencies (Haryadi [0002], [0004], [0007]), and to prevent users from downloading incompatible update packages (Haryadi [0005], [0022]).
Ramachandra in view of Maddukuri, Haryadi, Chen, and Kannan does not disclose however Warkentin discloses,
“further comprising: modifying, [], the size of the target image to a predetermined value before writing the target image” (In paragraph [0038], “The capsule header can also specify parameters including a header size, a set of header flags, a capsule image size … The DPU UEFI 163 can use the other parameters to ensure that the image is the proper size. The DPU UEFI 163 can also verify signatures of the individual binaries in the capsule before writing and booting the DPU management OS 165”.).
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Ramachandra in view of Maddukuri, Haryadi, Chen, and Kannan by adopting the teaching of modifying a target image size in Warkentin; motivated by the common goal to improve the arrangements for program control using stored programs, such as using a BMC to manage the delivery of firmware updates (Warkentin [0011], [0037], [0035]).
Claims 11 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Ramachandra in view of Maddukuri, Haryadi, Chen, and Kannan as applied to Claim 8 above, and further in view of Yeh et al. (U.S. Publication No. 20230009689 A1, hereinafter Yeh) and Gilbert et al. (U.S. Publication No. 20140026124 A1, hereinafter Gilbert).
Regarding Claim 11:
Ramachandra in view of Maddukuri, Haryadi, Chen, and Kannan does not disclose however Yeh discloses,
“such that the target device loads both a boot program and a kernel program of the target image from the same memory” (In paragraph [0011], “In this embodiment, the boot image file corresponds to a bootloader that is a program to execute the boot image file, and the OS image file corresponds to a Linux kernel that is a program to execute the OS image file”. The loading of both programs occur from the same corresponding first non-volatile memory. Note that Yeh discloses different secondary memory that is used for execution, not for loading of the program. The boot program is loaded from the boot image file in paragraph [0006], “loading the boot image file from the corresponding one of the first non-volatile memory unit”; The kernel program is loaded from the OS image file in paragraph [0006], “loading the OS image file from the corresponding one of the first non-volatile memory unit”.).
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Ramachandra in view of Maddukuri, Haryadi, Chen, and Kannan by adopting the teachings of Yeh; motivated by the common goal to create a more efficient and prepared system for BMC to load images in case of failure (Yeh [0006], Abstract).
Ramachandra in view of Maddukuri, Haryadi, Chen, Kannan, and Yeh does not disclose however Gilbert discloses,
“further comprising: rebooting, in response to the completion of writing the target image into the memory, the target device and setting a predetermined register” (The images are written in paragraph [0073], “a program called bosboot is invoked to re-write the AIX Boot Image1 with AIX Boot Image2”. Note that Boot-Image is a register as defined in paragraph [0086], “where PCR1, PCR2, PCR3 are registers in the TPM”, and in paragraph [0088], “PCR2=AIX Boot-Image”. In response to the changes in register from the boot image re-write, a reboot may be enacted, in paragraph [0064], “The attestation system can detect if the agreed registers (for example first and second agreed registers PCR17 and 18) are set and is able to prepare for the reboot and subsequent change of the currently trusted registers (for example PCR1,2 and 3)”.).
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Ramachandra in view of Maddukuri, Haryadi, Chen, Kannan, and Yeh by adopting the teachings of Gilbert; motivated by the common goal to improve methods of managing an update by verifying version compatibility (Gilbert [0009]), in the context of a large-scale system with numerous computing systems, “Computer systems are frequently updated with new features and software fixes … With many systems and many updates this scales into a larger difficult management problem” (Gilbert [0003]).
Regarding Claim 13:
Ramachandra further discloses,
“… after waiting for a predetermined time” (In paragraph [0045], “The host bootloader 116 can determine whether the DPU operating system 129 has successfully booted by polling the BMC 109 to determine whether the DPU operating system 129 has sent a ready signal to the BMC 109. Failure to receive a ready signal from the DPU operating system 129 within a predefined time period could serve as an indicator that the DPU operating system 129 has failed to boot”. Where the remedial actions is combined by Yeh’s reference to include switching the memory that stores the image to reboot.).
Ramachandra in view of Maddukuri, Haryadi, Chen, and Kannan does not disclose however Yeh further discloses,
“further comprising: in response to abnormal operation of the boot program and/or the kernel program, and switching the memory that stores the image to reboot the target device …” (Where the abnormal operation is the failure in paragraph [0015], “When the BMC (13, 23) fails to load the OS image file or fails to execute the operating system, the flow goes to step S3”. The OS image file being mapped to the claimed kernel program, in paragraph [0011], “the OS image file corresponds to a Linux kernel that is a program to execute the OS image file”. When failure to load the OS image file occurs in step 2, in step 3, the BMC switches the storage location in paragraph [0016] “In step S3, the BMC (13, 23) causes a corresponding one (i.e., the one on the same mainboard (11, 21) as the BMC (13, 23)) of the first network adapter 14 and the second network adapter 24 to communicate with the other one of the first network adapter 14 and the second network adapter 24 via the PXE mechanism, so as to acquire the OS image file from the other one (i.e., the one on a different mainboard (11, 21) as the BMC (13, 23)) of the first non-volatile memory unit 12 and the second non-volatile memory unit 22”.).
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Ramachandra in view of Maddukuri, Haryadi, Chen, and Kannan by adopting the teachings of Yeh; motivated by the common goal to create a more efficient and prepared system for BMC to load images in case of failure (Yeh [0006], Abstract).
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Ramachandra in view of Maddukuri, Haryadi, Chen, Kannan, Yeh, and Gilbert as applied to Claim 11 above, and further in view of Friedman et al. (U.S. Publication No. 20090300057 A1, hereinafter Friedman).
Regarding Claim 12:
Ramachandra in view of Maddukuri, Haryadi, Chen, and Kannan does not disclose however Yeh further discloses,
“and the kernel program” (In paragraph [0011], “the OS image file corresponds to a Linux kernel that is a program to execute the OS image file”. Where in paragraph [0026], “in addition to loading the boot image file to execute the boot procedure, loading the OS image file to execute the operating system, loading the file system image file to execute the file system and loading the application image file to execute the at least one application, the BMC (13, 23) may further activate other components (e.g., another system on a chip (SoC)) on the same mainboard (11, 21), and/or execute environmental monitoring … wherein the HA software program determines which one of the mainboards 11, 12 is to serve as an active and which one of the mainboards 11, 12 is to serve as a backup; the system monitoring program acquires an ambient temperature and determines whether the embedded system 100 functions normally, and periodically provides the system status acquired by the active to the backup”).
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Ramachandra in view of Maddukuri, Haryadi, Chen, and Kannan by adopting the teaching of the kernel program in Yeh; motivated by the common goal to create a more efficient and prepared system for BMC to load images in case of failure (Yeh [0006], Abstract).
Ramachandra in view of Maddukuri, Haryadi, Chen, Kannan, Yeh, and Gilbert does not disclose however Friedman discloses,
“further comprising: monitoring a running status of the boot program [runtime logs may be displayed in an operation 560. For example, as noted above, the hosted runtime environment may include a monitoring engine having one or more appliance management utilities for monitoring the execution that occurs during operation 520”. The booting is monitored with runtime logs during operation 520, in paragraph [0116], “the image may then be executed within the contained runtime environment in operation 520 … in one implementation, the image may be booted within a guest operating system associated with the contained runtime environment”.).
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Ramachandra in view of Maddukuri, Haryadi, Chen, Kannan, Yeh, and Gilbert by adopting the teachings of Friedman; motivated by the common goal to improve the server management of updates according to specifications of a computing environment where “existing systems for developing virtual appliances tend to lack adequate mechanisms for simplifying the management” (Friedman [0005]), where the management may be improved by preventing the use of an incompatible version, “Thus, in response to the repository metadata server detecting an upstream update to one or more packages … any reusable archives associated with the updated packages … may be invalidated because such archives include outdated information. The build engine may then be invoked to rebuild such archives to incorporate the upstream updates.” (Friedman [0027]).
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Ramachandra in view of Maddukuri as applied to Claim 1 above, and further in view of Haryadi et al. (U.S. Publication No. 20210311716 A1, hereinafter Haryadi).
Regarding Claim 14:
Ramachandra in view of Maddukuri does not disclose however Haryadi discloses,
“further comprising: creating, in response to an image system of the target device being the target image and an image to be installed being the current image, the current image in a compressed format using a first predetermined method” (The compressed format of the image is stored in a zip in paragraph [0063], “Phase 1—Export Depot. In this phase, the end user, through a user interface (UI), exports a depot given the software specification of a ROBO cluster to a zipped file, e.g., depot.zip”. Where the depot contains the image in paragraph [0034], “The provider of the virtualization software defines the components that make up the base image in an image specification 210, and image publishing kit 220 publishes the metadata of the base image in image depot 120”. In paragraph [0071], “At step S39, the coordinator issues an API to apply the desired image at the depot_location to the hosts. In response, the hosts at S40 retrieves the desired image from the depot_location and applies the image”.).
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Ramachandra in view of Maddukuri by adopting the teachings of Haryadi; motivated by the common goal to improve the convenience of upgrade methods for customers according to system specific dependencies (Haryadi [0002], [0004], [0007]), and to prevent users from downloading incompatible update packages (Haryadi [0005], [0022]).
Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over Ramachandra in view of Maddukuri as applied to Claim 1 above, and further in view of Manders et al. (U.S. Publication No. 20160328242 A1, hereinafter Manders).
Regarding Claim 15:
Ramachandra in view of Maddukuri does not disclose however Manders discloses,
“further comprising: writing the current image in the compressed format to a backup memory through the target image” (In paragraph [0023], “Object store 330 may generally be used for archival storage and/or backup storage and may also be referred to herein as an “archival storage component””.
In paragraph [0039], “Due to the predictive writing of bootable images … the initial instantiation of a particular bootable image … the particular bootable image may only be stored in object store 330”.
Note that in the context of Manders, the initial instantiation refers to booting as shown in paragraph [0042], “initiating instantiation (i.e., booting) of the bootable image”. In paragraph [0041], “The initial writing of the requested bootable image, because it is performed from the relatively slow object store”.).
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Ramachandra in view of Maddukuri by adopting the teachings of Manders; motivated by the common goal to provide better customer experience (Manders [0013]), when providing arrangements for executing specific programs (i.e., boot images) (Manders [0001], [0003]), in turn improving the performance of servers (e.g., a group of remote servers used in cloud computing) where “particular bootable image, when requested by customer, can be quickly brought online for the customer. In this manner, customers may be provided with a good cloud computing experience” (Manders [0013]).
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Ramachandra in view of Maddukuri as applied to Claim 1 above, and further in view of Peay et al. (U.S. Publication No. 20070038821 A1, hereinafter Peay).
Regarding Claim 16:
Ramachandra in view of Maddukuri does not disclose however Peay discloses,
“further comprising: switching an image loading path of the target device to the backup memory to reboot the target device” (The loading path of the target device, such as a directory path of the user in Peay, may first copied into a backup system as disclosed in paragraph [0036], “system information may be user-designated for temporal backup in several different ways. One way is to merely store all important files in a named directory on the primary drive, such as c:/myfiles/documents. That directory is designated by the user for temporal backup”. In paragraph [0045], “It is expected that the temporal backup application is loaded automatically at system boot up … the temporal backup process identifies all backup parameter values … the process creates a listing of all files and directories to be temporally backed up and the conditions for executing a temporal backup”. The switch occurring during reboot in paragraph [0059], “The most recently modified files have been backed up to the temporal backup device and are readily available for restoration. Furthermore, the temporal backup memory also contains a current, and often very comprehensive, boot image from which to reboot and restore the system with a new drive, or from which a boot disk may be created for the initial system boot-up”.).
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Ramachandra in view of Maddukuri by adopting the teachings of Peay; motivated by the common goal to improve the preservation of data in servers within in large scale businesses, to avoid complete replacement of data after failure (Peay [0006], [0007]).
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Ramachandra in view of Maddukuri and Haryadi as applied to Claim 14 above, and further in view of Peay et al. (U.S. Publication No. 20070038821 A1, hereinafter Peay).
Regarding Claim 17:
Ramachandra in view of Maddukuri and Haryadi does not disclose however Peay discloses,
“further comprising: writing, in response to the target device booting from the backup memory, the current image in the backup memory to the main memory through a rollback function” (In response to the booting from the backup drive in paragraph [0061], “Next, the system is booted from the temporal backup drive, or if booting directly from the temporal backup drive is not possible, from a boot disk created from a boot image on temporal backup memory.” Further, where the image is written to main memory by restoration in paragraph [0061], “Finally, an archived image is restored to the replacement primary drive (step 612)”. Backup drive contains memory as specified in paragraph [0028], “Hard drive assembly 100 differs from prior art hard drives in that it comprises both primary drive 102 and mass storage file backup 122 (referred to below as temporal backup 122). Mass storage file backup 122 includes removable mass storage device or memory 120”. Primary drive contains memory as specified in paragraph [0010], “a primary drive assembly with the primary memory”.).
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Ramachandra in view of Maddukuri and Haryadi by adopting the teachings of Peay; motivated by the common goal to improve the preservation of data in servers within in large scale businesses, to avoid complete replacement of data after failure (Peay [0006], [0007]).
Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over Ramachandra in view of Maddukuri and Haryadi as applied to Claim 14 above, and further in view of Zou et al. (U.S. Publication No. 20220237144 A1, hereinafter Zou).
Regarding Claim 21:
Ramachandra in view of Maddukuri and Haryadi does not disclose however Zou discloses,
“further comprising: the target device is a baseboard management controller, BMC, device running a conventional BMC system, the target image is an OpenBMC image” (In paragraph [0038], “the OpenBMC software framework is an open source software framework used to construct a complete Linux operating system image of the baseboard management controller”. In paragraph [0044], “the processor 101 of the baseboard management controller is configured to execute the OpenBMC system stored in the memory 102”.);
“the current image refers to an image corresponding to the BMC system that is currently running on the BMC of a server” (In paragraph [0052], “In addition, the baseboard management controller is also connected to the southbridge PCH of the server to manage the hardware system of the server”.).
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Ramachandra in view of Maddukuri by adopting the teachings of a OpenBMC in Zou; motivated by the common goal to improve the management of server systems, in particular to a baseboard management controller of a server (Zou [0004], [0002]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure Balakrishnan et al. (U.S. Publication No. 20240152344 A1, hereinafter Balakrishnan) relating to the method of updating of BMC with BMC images (Balakrishnan [0001]), to provide improved convenience in BMC upgrades according to varying hardware specifications (Balakrishnan [0006]).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Beza D Nigatu whose telephone number is (571)272-9643. The examiner can normally be reached Monday - Friday 7:30am-5:00pm, alternate Fridays off.
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 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.
/BEZA D NIGATU/Examiner, Art Unit 2192
/S. Sough/SPE, Art Unit 2192
Prosecution Insights