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 .
Claims 1-18 are pending.
This is in response to communications filed on 7/23/24.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969). A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b). The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13. The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-18 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-18 of U.S. Patent No. 12045627. Although the claims at issue are not identical, they are not patentably distinct from each other because of the claim correspondence given below:
Claim 10 of the pending application
Claim 1 of the patent
An apparatus, comprising: a plurality of compute nodes, wherein the plurality of compute nodes [[includes a plurality of boot controllers]] configured for remote boot installation and a board management controller (BMC) configured for managing system startup of the [[plurality of]] compute node,
A method performing a system start up, comprising: receiving at a board management controller (BMC) a startup configuration instruction to boot up a compute node with an operating system, wherein the compute node is located on a sled including a plurality of compute nodes,
wherein the BMC is configured for sending a boot instruction to a compute node to load an operating system, wherein a boot controller of the compute node in response to receiving the boot instruction is configured for loading the operating system using corresponding basic input/output system (BIOS) firmware that is stored remote from the compute node.
sending a boot instruction from the BMC to a boot controller of the compute node over a first communication interface of the plurality of communication interfaces to execute a basic input/output system (BIOS) firmware that is stored remote from the compute node; performing execution of the BIOS firmware on the compute node to initiate loading of the operating system for execution by the compute node;
For the limitations “compute nodes include a plurality of boot controllers” and “BMC configured for managing system startup of the plurality of compute nodes”, claim 11 mentions “rebooting each of the plurality of compute nodes of the rack assembly, rebooting a compute node includes sending a boot instruction from the BMC to a boot controller of the compute node.” Therefore, compute nodes include plurality of boot controllers and BMC is configured for managing system startup of the plurality of compute nodes.
For claim 1, claim 1 of the patent recites limitations of claim 1 as explained in the above table. For the plural rack assembly including sled including plurality of compute nodes and a cloud controller sending message to BMC to start up the compute nodes, claims 6, 9 and 11 teach the corresponding limitations.
For claims 2 and 11, claims 3 and 4 teach the corresponding limitations.
For claims 3 and 12, claims 2 and claim 3 teach the corresponding limitations.
For claims 4 and 13, the claims of the patent do not explicitly mention about hardware initialization. However, claim 1 mentions executing BIOS to load OS for execution, which requires hardware to be initialized.
For claims 5 and 14, claim 3 teach the corresponding limitations. Claim 3 does not explicitly mention the limitation “internal memory”; however, “sending BIOS firmware from BMC” requires BMC to store the firmware into its memory.
For claims 6 and 15, claim 3 teach the corresponding limitations.
For claims 7 and 16, claim 9 and claim 11 of the patent teach the corresponding limitations.
For claims 8 and 17, claim 9 of the patent recites the plurality of applications.
For claims 9 and 18, the claims of patent do not mention about video game application. Video game applications are well known in the art. The plurality of application can include a video game application.
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.
Claim(s) 1-6, 8-9, 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Faasse (US Patent 11927999), further in view of Wu (US Patent Application Publication 20210200555) and further in view of Khan (US Patent Application Publication 20190196907; cited in IDS).
For claim 1, Faasse et al teach the following limitations: A network architecture (Fig 1A), comprising: (lines 1-22 of col 5 mention rack mounted server and rack mounted enclosure; thus there is rack assemblies to include server), wherein rack assemblies include one or more sleds of compute nodes (lines 1-22 of col 5 mention computer platform 100-1 includes a chassis; thus the rack has sled or chassis; lines 1-22 of col 5 further mention each chassis has multiple motherboard with multiple multicore CPU chips; Fig 1A shows 100-1 has host 101 and NIC 140 – thus each sled or chassis has multiple compute nodes – host and NIC); a cloud management controller (server 197 in Fig 1A; line 64, col 6 through line 7, col 7 mention that server 197 manages BMC and Fig 1A shows that the system is a cloud – lines 33-48 of col 4 ) configured for managing remote boot installation of the plurality of compute nodes (Fig 3 mentions that remote server performs the management of host, NIC and BMC; management of host and NIC includes booting – lines 55-57 of col 12 and lines 44-50 of col 14); wherein each sled includes: a plurality of compute nodes (lines 1-22 of col 5 mention computer platform 100-1 includes a chassis; thus the rack has sled or chassis; Fig 1A shows computer platform 100-1 has host 101 and NIC 140 – thus each sled or chassis has multiple compute nodes – host and NIC), wherein the plurality of compute nodes includes a plurality of boot controllers configured for remote boot installation (Fig 1A – boot controller of host 101 includes processor, memory, power controller and boot firmware, lines 1-10 of col 9, lines 1-15 of col 10; NIC is shown in Fig 1B, NIC has boot controller – lines 40-50 of col 14 mention NIC booting by BMC); a board management controller (BMC) (BMC 129 shown in Fig 1A, 1B, 1C and Fig 2, lines 25-30 of col 6) configured for managing system startup of the plurality of compute nodes (Fig 4, Fig 5, Fig 6 mention the startup of the platform 100, platform 100 includes startup of BMC, host and NIC; the startup particularly mentioned in line 55, col 12 through line 18, col 14 and line 43-50 of col 14), wherein the cloud management controller sends a boot instruction to the BMC (Fig 5 step 504; line 42, col 13 through line 2, col 14; lines 5-17 of col 14 mention that BMC receives boot command from 197) to load an operating system on a compute node (lines 1-18 of col 14 – to effect loading and loading of the OS), wherein the BMC is configured for sending the boot instruction to a boot controller of the compute node to load the operating system (lines 44-54 of col 3 – BMC receives communication including command from the remote server 197 requesting a change of power state for the platform; lines 1-20 of col 14 mention that remote server communicates with BMC and BMC communicates with boot service firmware to effect loading and booting of OS), wherein the boot controller of the compute node in response to receiving the boot instruction is configured for loading the operating system (lines 1-15 of col 10; lines 1-20 of col 14; BMC communicates with boot service firmware to effect loading and booting of OS; thus boot controller receives boot instruction from BMC).
For the limitations “using corresponding basic input/output system (BIOS) firmware that is stored remote from the compute node”, Fasse teaches BMC to select boot device, PXE network boot (lines 10-18 of col 14) and BMC to execute firmware stack for control operation of the computer platform (lines 24-34 of col 11 and lines 35-42 of col 13). Therefore, BMC firmware, which is stored remote from the compute node, communicates with BIOS firmware 175 (Fig 1A) and is used to load the OS for the compute node. For further clarification Examiner cites WU that teaches the following limitations wherein the boot controller of the compute node is configured for loading the operating system using corresponding basic input/output system (BIOS) firmware that is stored remote from the compute node ([0028][0031] the remote side stores the major BIOS and the host loads the desired BIOS via the BMC). It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to use the remote BIOS from the compute node to load the OS, since that way a desired BIOS can be used (as taught in Wu, [0026] [0039]-[0040]). Fasse uses a selection of boot path from the BMC using communication from the remote server (lines 1-15 of col 14), therefore, the BIOS loading from BMC to the compute node further facilitates the proper selection, which facilitates desired selection of BIOS and corresponding functionality.
For the limitation “plurality of rack assemblies”, Fasse in view of Wu mention about rack assemblies (Wu [0002] mentions data center, rack and plural chassis), but not plural racks (though Wu mention “each rack” only). Data center with plural racks, each rack with plural nodes/sled is well known in the art (Fig 6; [0047] Khan). It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to use a plurality of rack devices in the data center because plural racks can hold increased number of nodes; thus, increases the capacity of the data center.
For claim 2, Wu teaches, wherein the boot controller is configured for receiving the BIOS firmware, wherein the BIOS firmware is executed on the compute node to initiate the loading of the operating system ([0037], Fig 6A Wu loading BIOS from remote side via BMC).
For claim 3, Wu teaches, wherein the boot controller is configured for determining an address of remote storage storing the BIOS firmware based on the boot instruction ([0030] – early stages of BIOS startup, network initialization specifies the network address to load the remaining BIOS), wherein the boot controller sends a request to access the address to the BMC ([0031] the remote site is accessible by BMC to provide BIOS image; [0037] – BIOS will load the remaining code stored on a remote site), wherein the BMC forwards the request to access the address to remote storage to access the BIOS firmware ([0031][0037]-[0038] – the BMC accesses the remote site; therefore, BMC requests the access to remote site), wherein the BMC receives the BIOS firmware from the remote storage and forwards the BIOS firmware to the compute node (Fig 6A; [0043] – BIOS communicates with BMC for major BIOS image and then major BIOS image is loaded from the BMC).
For claim 4, wherein system hardware on the compute node is initialized when executing the BIOS firmware (Wu [0026] BIOS DXE code provides hardware initialization; Fasse Fig 4 lines 1-42 col 13 provides hardware initialization by BIOS).
For claim 5, Wu teaches wherein the BMC accesses the BIOS firmware from internal memory, wherein the BMC sends the BIOS firmware to the compute node (Fig 4, Fig 5, Fig 6A and [0031] BMC memory is enabled and it is sync with BIOS system memory and CPU executes the BIOS code from the system memory).
For claim 6, Fasse teaches sending the boot instruction from BMC to compute node and Wu teaches sending BIOS firmware from BMC to compute node (lines 1-20 of col 14 Fasse; [0031][0037] Wu). Thus, combination makes obvious of the limitations the BIOS firmware is sent with the boot instruction to the compute node from the BMC.
For claim 8, Fasse teaches each of the plurality of compute nodes on the sled is configured is configured for executing one or more instances of the plurality of applications (Fig 1A; application layer 160 and containers 172; Fig 1B application layer in NIC; lines 40-45 of col 5; lines 60-63 of col 10).
For claim 9, Khan teaches that the compute system can be gaming console with graphics processing unit ([0049]). However, the combination does not explicitly mention that the one of the plurality of applications is a video game. Examiner takes official notice that the video game is known in the art as the application. It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to have the video game application, since it provides the user a video game playing environment.
For claim 16, Fasse teaches the BMC receives a start configuration instruction from a cloud management controller to load the operating system on the compute node, (line 64, col 6 through line 7, col 7; line 1-20 of col 14; lines 39-41 of col 13 – 197 communicates with BMC, then BMC communicates with boot service firmware) wherein the cloud management controller (server 197 in Fig 1A; line 64, col 6 through line 7, col 7 mention that server 197 manages BMC and Fig 1A shows that the system is a cloud – lines 33-48 of col 4 ) configured for managing remote boot installation of the plurality of compute nodes (Fig 3 mentions that remote server performs the management of host, NIC and BMC; management of host and NIC includes booting – lines 55-57 of col 12 and lines 44-50 of col 14) located on a rack assembly (lines 1-22 of col 5 mention rack mounted server and rack mounted enclosure; thus there is rack assemblies to include server), rack assemblies include one or more sleds of compute nodes (lines 1-22 of col 5 mention computer platform 100-1 includes a chassis; thus the rack has sled or chassis; lines 1-22 of col 5 further mention each chassis has multiple motherboard with multiple multicore CPU chips; Fig 1A shows 100-1 has host 101 and NIC 140 – thus each sled or chassis has multiple compute nodes – host and NIC). For the limitation “plurality of rack assemblies”, Fasse in view of Wu mention about rack assemblies (Wu [0002] mentions data center, rack and plural chassis), but not plural racks - though Wu mention “each rack” only. Data center with plural racks, each rack including plural sleds is well known in the art (Fig 6; [0047] Khan). It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to use a plurality of rack devices in the data center because plural racks can hold increased number of nodes; thus, increases the capacity of the data center.
Claim(s) 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Fasse (US Patent 11927999), further in view of Wu (US Patent Application Publication 20210200555) and further in view of Khan (US Patent Application Publication 20190196907; cited in IDS), further in view of Sonoda (US Patent Application Publication 2015/0263943; cited in IDS)
For claim 7, Fasse teaches wherein the cloud management controller sends a start configuration instruction, including the boot instruction to load the operating system on the compute node (line 64, col 6 through line 7, col 7; line 1-20 of col 14; lines 39-41 of col 13 – 197 communicates with BMC, then BMC communicates with boot service firmware). Fasse in view of Wu, in view of Khan does not explicitly mention a rack controller located on a rack assembly, wherein the rack controller forwards the start configuration instruction to the BMC of a sled including the compute node. Sonoda teaches a cloud controller communicating with the rack controller, which further communicates with the nodes (Fig 1). It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to include a rack controller in the system so that the commands and instructions can flow in a proper sequence from cloud controller to rack controller and then rack controller to BMC of the sled/chassis, which facilitates modularity/hierarchy in the system, which further facilitates simpler data center management.
Claim(s) 10-15, 17-18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Fasse (US Patent 11927999), further in view of Wu (US Patent Application Publication 20210200555)
For claim 10, Fasse teaches the following limitations: An apparatus, comprising: a plurality of compute nodes (lines 1-22 of col 5 mention computer platform 100-1 includes a chassis; thus the rack has sled or chassis; Fig 1A shows computer platform 100-1 has host 101 and NIC 140 – thus each sled or chassis has multiple compute nodes – host and NIC), wherein the plurality of compute nodes includes a plurality of boot controllers configured for remote boot installation (Fig 1A – boot controller of host 101 includes processor, memory, power controller and boot firmware, lines 1-10 of col 9, lines 1-15 of col 10; NIC is shown in Fig 1B, NIC has boot controller – lines 40-50 of col 14 mention NIC booting by BMC); and a board management controller (BMC) (BMC 129 shown in Fig 1A, 1B, 1C and Fig 2, lines 25-30 of col 6) configured for managing system startup of the plurality of compute nodes (Fig 4, Fig 5, Fig 6 mention the startup of the platform 100, platform 100 includes startup of BMC, host and NIC; the startup particularly mentioned in line 55, col 12 through line 18, col 14 and line 43-50 of col 14), wherein the BMC is configured for sending a boot instruction to a compute node to load an operating system (lines 44-54 of col 3 – BMC receives communication including command from the remote server 197 requesting a change of power state for the platform; lines 1-20 of col 14 mention that remote server communicates with BMC and BMC communicates with boot service firmware to effect loading and booting of OS), wherein the boot controller of the compute node in response to receiving the boot instruction is configured for loading the operating system (lines 1-15 of col 10; lines 1-20 of col 14; BMC communicates with boot service firmware to effect loading and booting of OS; thus boot controller receives boot instruction from BMC).
For the limitations “using corresponding basic input/output system (BIOS) firmware that is stored remote from the compute node”, Fasse teaches BMC to select boot device, PXE network boot (lines 10-18 of col 14) and BMC to execute firmware stack for control operation of the computer platform (lines 24-34 of col 11 and lines 35-42 of col 13). Therefore, BMC firmware, which is stored remote from the compute node, communicates with BIOS firmware 175 (Fig 1A) and is used to load the OS for the compute node. For further clarification Examiner cites WU that teaches the following limitations wherein the boot controller of the compute node is configured for loading the operating system using corresponding basic input/output system (BIOS) firmware that is stored remote from the compute node ([0028][0031] the remote side stores the major BIOS and the host loads the desired BIOS via the BMC).
It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to use the remote BIOS from the compute node to load the OS, since that way a desired BIOS can be used (as taught in Wu, [0026] [0039]-[0040]). Fasse uses a selection of boot path from the BMC using communication from the remote server (lines 1-15 of col 14), therefore, the BIOS loading from BMC to the compute node further facilitates the proper selection, which facilitates desired selection of BIOS.
For claim 11, Wu teaches, wherein the boot controller is configured for receiving the BIOS firmware, wherein the BIOS firmware is executed on the compute node to initiate the loading of the operating system ([0037], Fig 6A Wu loading BIOS from remote side via BMC).
For claim 12, Wu teaches, wherein the boot controller is configured for determining an address of remote storage storing the BIOS firmware based on the boot instruction ([0030] – early stages of BIOS startup, network initialization specifies the network address to load the remaining BIOS), wherein the boot controller sends a request to access the address to the BMC ([0031] the remote site is accessible by BMC to provide BIOS image; [0037] – BIOS will load the remaining code stored on a remote site), wherein the BMC forwards the request to access the address to remote storage to access the BIOS firmware ([0031][0037]-[0038] – the BMC accesses the remote site; therefore, BMC requests the access to remote site), wherein the BMC receives the BIOS firmware from the remote storage and forwards the BIOS firmware to the compute node (Fig 6A; [0043] – BIOS communicates with BMC for major BIOS image and then major BIOS image is loaded from the BMC).
For claim 13, wherein system hardware on the compute node is initialized when executing the BIOS firmware (Wu [0026] BIOS DXE code provides hardware initialization; Fasse Fig 4 lines 1-42 col 13 provides hardware initialization by BIOS).
For claim 14, Wu teaches wherein the BMC accesses the BIOS firmware from internal memory, wherein the BMC sends the BIOS firmware to the compute node (Fig 4, Fig 5, Fig 6A and [0031] BMC memory is enabled and it is sync with BIOS system memory and CPU executes the BIOS code from the system memory).
For claim 15, Fasse teaches sending the boot instruction from BMC to compute node and Wu teaches sending BIOS firmware from BMC to compute node (lines 1-20 of col 14 Fasse; [0031][0037] Wu). Thus, combination makes obvious of the limitations the BIOS firmware is sent with the boot instruction to the compute node from the BMC.
For claim 17, Fasse teaches each of the plurality of compute nodes on the sled is configured is configured for executing one or more instances of the plurality of applications (Fig 1A; application layer 160 and containers 172; Fig 1B application layer in NIC; lines 40-45 of col 5; lines 60-63 of col 10).
For claim 18, Fasse in view of Wu does not explicitly mention that the one of the plurality of applications is a video game. Examiner takes official notice that the video game is known in the art as the application. It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to have the video game application, since it provides the user a video game playing environment. With a video game application, user can enjoy the playing game smoothly.
Conclusion
PTO-892 cites additional references that are not relied upon for rejection, but provide background information as related art.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FAHMIDA RAHMAN whose telephone number is (571)272-8159. The examiner can normally be reached Monday - Friday 10 AM - 7 PM. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Andrew Jung can be reached at 571-270-3779. 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.
/FAHMIDA RAHMAN/Primary Examiner, Art Unit 2175