CTNF 18/677,496 CTNF 87640 Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. DETAILED ACTION This is the initial Office action based on the application filed on May 29, 2024. Claims 1-20 are presently pending in the application have been examined below, of which, claims 1, 10, and 19 are presented in independent form. Allowable Subject Matter 12-151-08 AIA 07-43 12-51-08 Claim s 6 and 8 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. Claims 15 and 17 are substantially similar to claims 6 and 8 and objected to under the same rationale. 112(f) interpretation 07-30-03 AIA The following is a quotation of 35 U.S.C. 112(f): (f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof. The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph: An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof. 07-30-05 The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked. As explained in MPEP 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph: (A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function; (B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as "configured to" or "so that"; and (C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function. Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function. Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. 07-30-06 This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: management controller in claim 19 . Because claim limitation(s) of claim 19 are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, they are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof. If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. Claim Rejections - 35 USC § 112 (b) 07-30-02 The following is a quotation of the first paragraph 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. 07-34-01 Claims 9 and 18 are rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, 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 pre-AIA the applicant regards as the invention. Claims 9 and 18 recite the limitation “… performed the HTTP boot service”. There is insufficient antecedent basis for this limitation in the claims. For the purpose of compact prosecution, the claim is interpreted as “… performed a HTTP boot service”. Appropriate correction is required. Claim Rejections - 35 USC § 103 07-20-aia AIA 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 of this title, 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. 07-21-aia AIA Claims 1-2, 4-5, 7, 10-11, 13-14, 16, and 19-20 are r ejected under 35 U.S.C. 103 as being unpatentable over U S 2024/0028343 (hereinafter "Haryadi”), in view of US 2017/0185418 (hereinafter “Huang”), in view of EP 2378416 A1 (hereinafter “BHADAURIA”), and further in view of US 2014/0181490 (hereinafter “Campbell”) . I n the following claim analysis, Applicant’s claim limitations are presented in bold text, the Examiner’s explanations, notes, and remarks are enclosed in square brackets; and emphasized portions are underlined. As to claim 1, Haryadi discloses An operating system update method (Haryadi, Abstract, various embodiments for a unified boot image that can be used to install an operating system onto a host machine and a respective operating system onto a data processing units (DPU) installed on a host machine) , comprising: during a computer equipment power-on startup stage, controlling a system boot processor (Haryadi, ¶ 27, the DPU bootloader 147 can represent a program responsible for booting the DPU operating system 142 in response to the DPU 106 being powered on. Once execution of the DPU bootloader 147 is initiated, the bootloader can select the DPU boot image 133 to boot the DPU operating system 142); querying first system version information of a data processing unit (DPU) operating system (OS) in the computer equipment (Haryadi, Fig. 2, ¶ 34, the host OS installer 121 can initiate the installation workflow for provisioning the host operating system 112 and/or the DPU operating system 142 on the host machine 103 and/or DPU 106 according to the unified boot image 127; ¶ 35, the host OS installer 121 determines whether a DPU has been selected for an operating system installation … a user can select the DPU 106 for installation of the DPU operating system 142 … the user can request specific details associated with the DPU 106 such as, … a version [first system version information] of the current operating system, a unique identifier, and/or other details) ; obtaining a system image file of the DPU OS (Haryadi, ¶ 37, the DPU OS orchestrator 136a identifies the installation depot 130 included in the unified boot image 127. The installation depot 130 corresponds to an offline depot that includes the binaries associated with the operating system to be installed on the DPU 106 … the binaries of the operating system to be installed on the DPU 106 can be packaged in the unified boot image 127) ; controlling DPU to update the DPU OS according to the system image file (Haryadi, ¶ ¶ 38-39, the DPU OS orchestrator 136a initiates the install of the DPU operating system 142; ¶ 41, the DPU 106 downloads the DPU boot image 133 provided by the server process created by the DPU OS orchestrator 136a. The DPU boot image 133 can represent an installation image that can be installed by the DPU OS installer 151 or another provisioning service on the DPU 106 [It is noted that Haryadi discloses that the DPU OS orchestrator initiates installation of the OS by downloading and installing a boor image, which constitutes controlling the DPU to update the DPU OS according to the system image file]); and controlling the system boot processor to continue the computer equipment startup process ( Haryadi, ¶ 43, the DPU OS installer 151 provides an indication of completion to the BMC 109. For example, the, the DPU bootloader 147 can boot a DPU boot image when the installer workflow has completed so that the DPU 106 is powered on and begins to boot. The DPU operating system 142 can provide a success signal upon bootup of the DPU 106 if the DPU 106 successfully boots the DPU boot image 133). Haryadi discloses controlling a system boot processor, does not explicitly disclose controlling a system boot processor to interrupt a computer equipment startup process. However, Huang teaches controlling a system boot processor to interrupt a computer equipment startup process (Huang, ¶ 24, the device 100 halts the boot process and enters a state in which the device 100 waits for a command from the connected device 100. The device 100 may send a message to the connected device 108 indicating that the device 100 is waiting for a command from the connected device 108; ¶ 44, The first device receives, from the connected device, an application image (216). In some examples, the first device may receive a command indicating that the first device will receive an application image from the connected device. The application image may be a firmware update or an operating system update It is noted that Huang teaches halting a boot process and placing the system in a waiting state, which constitutes interrupting a startup process, as both prevent completion of the normal boot sequence]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Haryadi with the teaching taught by Huang including controlling a system boot processor to interrupt a computer equipment startup process. The modification would be obvious because one of ordinary skill in the art would be motivated to control or halt a boot process that allows a user to update firmware, an operating system, or both, on a device during a software development process or when a software update is available without manual configuration of the device by the user for the update, e.g., without manual selection of a button or control. In some implementations, the use of a device identifier to control or halt a boot process may allow a user to recover a device when software on the device does not work correctly (Huang, ¶ 8). Haryadi as modified does not explicitly disclose in response to determining that the first system version information does not match second system version information of a current host OS in the computer equipment obtaining a system image file and obtaining a system image file that matches the host OS. However, BHADAURIA teaches in response to determining that the first system version information does not match second system version information of a current host OS in the computer equipment obtaining a system image file (BHADAURIA, pg. 3, para. 3, the boot server is adapted to determine and send one of the different versions of the operating system image stored in the boot server as the updated version of the operating system image if said comparison results in a mismatch and the image identifier for the different versions of the operating system image is greater than the image version identifier of the current version [It is noted that BHADAURIA teaches determining whether a stored system image version differs from a current version and upon mismatch, selecting an updated system image from a boot server, which corresponds to obtaining a system image file in response to the mismatch]) and obtaining a system image file that matches the host OS (BHADAURIA, pg. 3, para. 3, directs the client device to download latest available operating system image from the boot server [if the comparison indicates a mismatch between a current version and one or more available versions stored, and an image identifier of one of the available version is greater than that of the current version]; pg. 5, para. 4, The information 14 about the different versions 12 includes an image identifier 22 in respect to each of the different versions 12. Alternatively, the information 14 can also include a client device identifier [The use of client identifier and version parison to select an operating system image indicates that the selected mage is tailored to the operating system of the client device, thereby corresponding to (i.e., the operating system of the device to make them compatible]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Haryadi as modified with the teaching taught by BHADAURIA including in response to determining that the first system version information does not match second system version information of a current host OS in the computer equipment obtaining a system image file. The modification would be obvious because one of ordinary skill in the art would be motivated to compare the information about the current version and the information about the different versions for determining an updated image version of said operating system for said client device (BHADAURIA, Abstract). Haryadi as modified discloses controlling DPU to update the DPU OS according to the system image file (Haryadi, ¶ ¶ 38-39 and 41) , but does not explicitly disclose restart DPU . However, Campbell teaches restart DPU (Campbell, ¶ 39, once the one or more updates are completed running, at block 430, the device 200 boots the device 200 from the modified image 110' instead of the main image 105 [It is noted that Campbell teaches that upon completion of installation, the DPU is powered on and proceeds to boot the operating system, which corresponds to controlling the system boot processes to continue the startup process after update]) . It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Haryadi as modified with the teaching taught by Campbell including restarting DPU. The modification would be obvious because one of ordinary skill in the art would be motivated to reduce and minimize the downtime to a time to reboot the device once when the device switches over to boot from the new image (Campbell, ¶ 13). As to claim 2, the rejection of claim 1 is incorporated. Haryadi as modified further discloses The method according to claim 1, further comprising: during a process of installing the current host OS in the computer equipment (Haryadi, ¶ 38-39) , obtaining the second system version information of the host OS (BHADAURIA, pg. 3, para. 3, the boot server is adapted to determine and send one of the different versions [including the second system version information of the host OS] of the operating system image stored in the boot server) , and a system image address of the system image file of the DPU OS that matches the host OS (BHADAURIA, pg. 3, para. 3, determine the current version of the operating system image 6 as the updated version 6, 12 and send a boot information 18 [inherently including a system image address of the system image file in order to have the download action to take place in the right address] to the client device to download the current version of the operating system image 6 stored inside the client device 4) ; downloading the system image file of the DPU OS according to the system image address (BHADAURIA, pg. 3, para. 3, download the current version of the operating system image 6 stored inside the client device 4 if said comparison results in a match or the image identifier 24 of the current operating system image 6 is greater than the image identifier 22 of the different versions of the operating system image 12) ; associating the system image file with the second system version information, and storing the system image file locally or in an external device and recording an access address for accessing the system image file in the external device (BHADAURIA, pg. 3, para. 3, when a comparison indicates a mismatch between a current version and one or more available versions stored at the boot server, and an image identifier of one of the available versions is greater than that of the current version, the boot server selects and sends that available version as the updated operating system image [stored inherently in an address of the external device]; when the comparison indicates a match, or when the image identifier of the current version is greater than that of the available versions, the boot server determines that the current version is the appropriate version and transmits boot information to the client device, enabling the client device to download the operating system image stored locally [stored inherently in an address]. the system directs the client device to obtain the most appropriate operating system image—either from the boot server or from the client device itself) ; wherein the obtaining the system image file of the DPU OS that matches the host OS includes: determining the system image file of the DPU OS stored in association with the second system version information ((BHADAURIA, pg. 3, para. 3, when the comparison indicates a match, or when the image identifier of the current version is greater than that of the available versions, the boot server determines that the current version is the appropriate version and transmits boot information to the client device, enabling the client device to download the operating system image stored locally) ; or retrieving the system image file of the DPU OS from the external device according to the access address. The motivation to combine the references is the same as set forth in the rejection of claim 1. As to claim 4, the rejection of claim 1 is incorporated. Haryadi as modified further discloses The method according to claim 1, further comprising: obtaining status information of the DPU OS (Haryadi, ¶ 45, The host OS installer 121 can determine whether the DPU operating system 142 has successfully booted) ; and based on the status information, determining that the DPU OS is in a running state (Haryadi, ¶ 43, The DPU operating system 142 can provide a success signal upon bootup of the DPU 106 if the DPU 106 successfully boots the DPU boot image 133) , and performing querying the first system version information of the DPU OS in the computer equipment (Haryadi, ¶ 35, the host OS installer 121 determines whether a DPU has been selected for an operating system installation … a user can select the DPU 106 for installation of the DPU operating system 142 … the user can request specific details associated with the DPU 106 such as, … a version of the current operating system, a unique identifier, and/or other details) . As to claim 5, the rejection of claim 4 is incorporated. Haryadi as modified further discloses The method according to claim 4, after determining that the DPU OS is in the running state, further comprising: outputting version check prompt information for the DPU OS (Haryadi, ¶ 35, a user can select the DPU 106 for installation of the DPU operating system 142 … the user can request specific details [outputs to the user] associated with the DPU 106 such as, … a version of the current operating system, a unique identifier, and/or other details) ; obtaining a confirmation check instruction for the version check prompt information (Haryadi, ¶ 35, a user can select the DPU 106 for installation of the DPU operating system 142 … the user can request specific details [outputs to the user] associated with the DPU 106 such as, … a version of the current operating system, a unique identifier, and/or other details. A user can use this information to make a decision on whether to install an operating system) , and performing querying the first system version information of the DPU OS in the computer equipment (Haryadi, ¶ 35, a user can select the DPU 106 for installation of the DPU operating system 142 … the user can request specific details [outputs to the user] associated with the DPU 106 such as, … a version of the current operating system, a unique identifier, and/or other details) ; and obtaining an exit check instruction for the version check prompt information (Haryadi, ¶ 35, a user can select the DPU 106 for installation of the DPU operating system 142 … the user can request specific details [outputs to the user] associated with the DPU 106 such as, … a version of the current operating system, a unique identifier, and/or other details. A user can use this information to make a decision [as an exit check] on whether to install an operating system) , and triggering the system boot processor to continue the computer equipment startup process (Haryadi, ¶ 43, the DPU bootloader 147 can boot a DPU boot image when the installer workflow has completed so that the DPU 106 is powered on and begins to boot. The DPU operating system 142 can provide a success signal upon bootup [startup] of the DPU 106 if the DPU 106 successfully boots the DPU boot image 133) . As to claim 7, the rejection of claim 4 is incorporated. Haryadi as modified further discloses The method according to claim 4, further comprising: according to the status information, determining that the DPU OS is not in the running state (Haryadi, ¶ 45, The host OS installer 121 can determine whether the DPU operating system 142 has successfully booted … Failure to receive a ready signal from the DPU operating system 142 within a predefined time period could serve as an indicator that the DPU operating system 142 has failed to boot) , and obtaining a startup duration of the DPU OS (Haryadi, ¶ 45, Failure to receive a ready signal from the DPU operating system 142 within a predefined time period could serve as an indicator that the DPU operating system 142 has failed to boot) ; and determining that the startup duration is longer than a preset duration ( Haryadi, ¶ 45, Failure to receive a ready signal from the DPU operating system 142 within a predefined time period [the duration] could serve as an indicator that the DPU operating system 142 has failed to boot) , and controlling the system boot processor to continue the computer equipment startup process (Haryadi, ¶ 44, the BMC 109 or DPU OS orchestrator 136 can determine after a timeout period that the DPU OS installer 151 did not successfully complete installation of the DPU operating system 142 from the DPU boot image 133 … the host OS installer 121 can restart the DPU installation workflow on the DPU 106 or power cycling [which inherently causes a startup process] the DPU 106) . As to claims 10-11, 13-14, and 16, the claims are essentially the same as method claim 1-2, 4-5, and 7 except the claimed invention is set forth as an apparatus and are rejected with the same reasoning as applied hereinabove to the method claims. Further, Haryadi as modified further discloses An operating system update apparatus comprising a memory storing a computer program and a processor couple to the memory, wherein when being executed by the processor, the computer program causes the processor to perform (Haryadi, claim 1). As to claims 19-20, the claims are essentially the same as method claim 1-2 except the claimed invention is set forth as a computer equipment and are rejected with the same reasoning as applied hereinabove to the method claims . 07-21-aia AIA Claim s 3, 9, 12, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over US 2024/0028343 (hereinafter "Haryadi”), in view of US 2017/0185418 (hereinafter “Huang”), in view of EP 2378416 A1 (hereinafter “BHADAURIA”), in view of US 2014/0181490 (hereinafter “Campbell”), and further in view of “Using HTTP Boot to Install an Operating System on Lenovo ThinkSystem servers”, an Internet article by CUI, May 2019 (Hereinafter “Cui”) . As to claim 3, the rejection of claim 1 is incorporated. Haryadi as modified does not appear to explicitly disclose The method according to claim 1, wherein controlling DPU to update the DPU OS according to the system image file comprises: configuring a hyper text transmission protocol (HTTP) boot service for the DPU OS, and generating a system update instruction including the HTTP boot service; and sending the system update instruction to DPU to control DPU to perform the HTTP boot service to update the DPU OS according to the system image file. However, Cui teaches The method according to claim 1, wherein controlling DPU to update the DPU OS according to the system image file comprises: configuring a hyper text transmission protocol (HTTP) boot service for the DPU OS (Cui, pg. 17-19, To install OS through HTTP Boot on the server, perform the following steps: … The HTTP Boot menu of OS installation modified in “Configuring HTTP Boot Server File Catalog” on page 14 appears as shown in Figure 33 on page 19 on the HTTP Boot client. 4. Choose the OS to be installed on your HTTP Boot client), and generating a system update instruction including the HTTP boot service (Cui, pg. 17-19, To install OS through HTTP Boot on the server, perform the following steps: step 1 through step 4) ; and sending the system update instruction to DPU to control DPU to perform the HTTP boot service to update the DPU OS according to the system image file (Cui, pg. 14, 1. Create a folder called ISO under the /srv/www directory for placing OS images, 2. Create a folder called sles12sp2 under the /srv/www/htdocs directory as the OS image mounting point. …; pg. 17-19) . It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Haryadi as modified with the teaching taught by Cui. The modification would be obvious because one of ordinary skill in the art would be motivated to implement a HTTP Boot, which is a client-server communication based application. It combines the Dynamic Host Configuration Protocol (DHCP), Domain Name System (DNS), and Hypertext Transfer Protocol (HTTP) to provide the capability for system deployment and configuration over the network (Cui, Abstract). As to claim 12, the rejection of claim 10 is incorporated and the claim is an apparatus claim corresponding to method 3. Therefore, it is rejected under the same rational set forth in the rejection of claim 3. As to claim 9, the rejection of claim 1 is incorporated. Haryadi as modified further discloses The method according to claim 1, further comprising: after determining a match between the first system version information and the second system version information (BHADAURIA, pg. 3, para. 2, the boot server to objectively compare the information about the current version and the information about the different versions, so that the boot server can determine the updated version of the operating system image uniquely) , controlling the system boot processor to continue the computer equipment startup process (Haryadi, ¶ 44, the host OS installer 121 can restart the DPU installation workflow on the DPU 106 or power cycling [which inherently causes a startup process] the DPU 106) ; after determining no match between the first system version information and the second system version information (BHADAURIA, pg. 3, para 3, if said comparison results in a match or the image identifier of the current version of the operating system image is greater than the image identifier of the different versions of the operating system image) , determining whether DPU has already performed ( BHADAURIA, pg. 4, para. 4, the boot server 16 and the client device 4 interacts with each other to determine an updated version of the operating system image 6, 12 to be used by the client device 4) the HTTP boot service (Cui, pg. 17-19, To install OS through HTTP Boot on the server, perform the following steps: … The HTTP Boot menu of OS installation modified in “Configuring HTTP Boot Server File Catalog” on page 14 appears as shown in Figure 33 on page 19 on the HTTP Boot client. 4. Choose the OS to be installed on your HTTP Boot client) ; in response to DPU having already performed the HTTP boot service, controlling the system boot processor to continue the computer equipment startup process (Haryadi, ¶ 44, the BMC 109 or DPU OS orchestrator 136 can determine after a timeout period that the DPU OS installer 151 did not successfully complete installation of the DPU operating system 142 from the DPU boot image 133 … the host OS installer 121 can restart the DPU installation workflow on the DPU 106 or power cycling [which inherently causes a startup process] the DPU 106) ; and in response to DPU having not performed the HTTP boot service, obtaining the system image file of the DPU OS that matches the host OS (BHADAURIA, pg. 6, para. 1, Each of the image identifiers 22 is compared to the image identifier 14 to determine the update version of the operating system image (6, 12). On a basis of the comparison, the boot sever is adapted to determine and send one of the different versions of the operating system image 12 stored in the boot server 16 as the updated version of the operating system image 6) . The motivation to combine the references is the same as set forth in the rejections of claims 1 and 3. As to claim 18, the rejection of claim 10 is incorporated and the claim is an apparatus claim corresponding to method 9. Therefore, it is rejected under the same rational set forth in the rejection of claim 9 . Conclusion 07-96 AIA The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. US 2023/0325203 teaches provisioning a data processing unit (DPU) management operating system (OS). A host device boots a host provisioning image, which executes a host provisioning agent. The host provisioning agent launches a server component that serves a DPU management OS. A provisioning command is transmitted to a DPU device installed to the host device. The server component transmits the DPU management OS from the host device to the DPU device. A host OS is executed once an indication that the DPU device is executing on the DPU management OS is received; and US 2020/0341743 teaches installing or updating an operating system (OS), wherein the update platform can learn from the OS management platform that the new OS install is scheduled or is going to be scheduled. The OS management platform can provide details about the OS. Contact Information Any inquiry concerning this communication or earlier communications from the examiner should be directed to DAXIN WU whose telephone number is (571) 270-7721. The examiner can normally be reached on M-F (7 am - 11:30 am; 1:30- 5 pm). 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 an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form. /DAXIN WU/ Primary Examiner, Art Unit 2191 Application/Control Number: 18/677,496 Page 2 Art Unit: 2191 Application/Control Number: 18/677,496 Page 3 Art Unit: 2191 Application/Control Number: 18/677,496 Page 4 Art Unit: 2191 Application/Control Number: 18/677,496 Page 5 Art Unit: 2191 Application/Control Number: 18/677,496 Page 6 Art Unit: 2191 Application/Control Number: 18/677,496 Page 7 Art Unit: 2191 Application/Control Number: 18/677,496 Page 8 Art Unit: 2191 Application/Control Number: 18/677,496 Page 9 Art Unit: 2191 Application/Control Number: 18/677,496 Page 10 Art Unit: 2191 Application/Control Number: 18/677,496 Page 11 Art Unit: 2191 Application/Control Number: 18/677,496 Page 12 Art Unit: 2191 Application/Control Number: 18/677,496 Page 13 Art Unit: 2191 Application/Control Number: 18/677,496 Page 14 Art Unit: 2191 Application/Control Number: 18/677,496 Page 15 Art Unit: 2191 Application/Control Number: 18/677,496 Page 16 Art Unit: 2191
Prosecution Insights