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 application has been examined. Claims 1-19, 23 are pending. Claims 20-22 are cancelling.
The Group and/or Art Unit location of your application in the PTO has changed. To aid in correlating any papers for this application, all further correspondence regarding this application should be directed to Group Art Unit 2175.
Specification
The title of the invention is not descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed.
Claim Rejections - 35 USC § 112
The following is a quotation of the second paragraph of 35 U.S.C. 112:
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 7–9 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor regards as the invention.
Claim 7 depends from claim 1 and recites “the target shared interface in the target hardware interface” and “a reference processor core in the plurality of groups of processor cores.” Claim 1 recites neither a “target shared interface” nor a “plurality of groups of processor cores.” Accordingly, the recitations “the target shared interface” and “the plurality of groups of processor cores” lack proper antecedent basis, rendering the scope of the claim unclear (is the “target shared interface” the same as the “target hardware interface” of claim 1, or a distinct interface of the type introduced only in claim 6?). Claims 8 and 9 depend from claim 7 and incorporate the same indefinite recitations. Examiner suggests amending claim 7 to depend from a claim that introduces the “target shared interface” and the “plurality of groups of processor cores” (e.g., claim 6), or expressly reciting those elements within claim 7.
Claim 23 is rejected under 35 U.S.C. 112(b) as being indefinite.
Claim 23 recites “reading a code of the SPL and a verification code,” then “comparing the calculated value with a read verification code.” The later recitation “a read verification code” uses an indefinite article and does not make clear whether it refers back to the previously introduced “verification code” or introduces a further, distinct code. For consistency and antecedent basis, Examiner suggests “comparing the calculated value with the verification code.” For purposes of the prior-art rejection below, the limitation is treated as comparing the calculated value against the read verification code.
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 t which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 12, 18-19 are rejected under AIA 35 U.S.C. § 103 as being unpatentable over Cudak et al. (“Cudak”) (US No. 12,067,404) in view of Quinn et al. (“Quinn”) (US No. 11,397,587).
In order to expedite and avoid piecemeal prosecution, the following rejection is made to the extent that the claims are understood, by considering those elements which are understood and interpreting their function in a manner which is consistent with the recited goals of the claims, and then applying the best available art.
The examiner relies on the entire teachings of Cudak and Quinn references; the applicant should carefully consider the entire teachings of the above-mentioned references to better understand the examiner’s position.
In regard to claim 1, Cudak teaches a system running method of a Baseboard Management Controller (BMC), wherein the system running method comprises: starting up a target operating system on a BMC, wherein the target operating system is configured to manage a target hardware partition among a plurality of hardware partitions divided on a server host system (as shown in Fig. 1 & 3, which is reproduced below for ease of reference and convenience, Cudak discloses program instructions executable by a processor of a baseboard management controller (BMC) in a multi-processor system (Abstract; FIG. 3, BMC CPU 111 executing application program 119; FIG. 1, BMC 62). Cudak further teaches the multi-processor (host) system is divided into a plurality of independent partitioned nodes P1/P2 (hardware partitions) and the single BMC independently monitors and manages each partitioned node (Summary; FIGS. 19-20, P1/P2).
PNG
media_image1.png
1031
749
media_image1.png
Greyscale
PNG
media_image2.png
588
595
media_image2.png
Greyscale
loading a target hardware interface for the target operating system, wherein the target hardware interface is configured to establish a connection between the target operating system and the target hardware partition (in Cudak: the BMC provides separate sets of management interfaces for each partitioned node (FIG. 13) and uses its I/O ports (PECI/APML, PCIe, NC-SI (FIG. 3, ports 115-118)) to establish the connection to, and manage, each partition; the BMC causes loading of a firmware interface for a partition (Summary)) and running the target operating system on the BMC, wherein the target operating system is configured to manage the target hardware partition through the target hardware interface (in Cudak: the BMC independently monitors and manages each partitioned node in the same manner it would manage a unified node, attributing each interface to the partition to which it is assigned (Summary)). But Cudak does not expressly teach starting up a target operating system on the BMC that is dedicated to managing one target partition. In the same field of endeavor, Quinn teaches starting up a target operating system on the BMC that is dedicated to managing one target partition (as shown in Fig. 1, which is reproduced below for ease of reference and convenience, Quinn supplies booting a distinct operating system on a dedicated subset of the cores of a single multicore processor booting a first OS on a first subset of cores and a second, different OS on a second subset, each OS having isolated, unscheduled control without overlap in assigned resources (Abstract; claim 1; FIG. 1)).
PNG
media_image3.png
747
614
media_image3.png
Greyscale
Cudak already contemplates a single BMC providing independent management to each of a plurality of host hardware partitions through separate interface sets. Quinn teaches that a single multicore processor can be operated so that distinct, concurrently executing operating systems each control a dedicated, isolated subset of cores “as if each core… was an independent CPU… without overlap in assigned resources.” It would have been obvious to one of ordinary skill before the effective filing date to apply Quinn’s per-core operating-system isolation to Cudak’s BMC so that the BMC runs an independent management operating system for each host hardware partition. The motivation is Cudak’s own goal of independently managing each partitioned node without a separate controller per node, and Quinn’s stated benefit of isolated per-core execution; the combination predictably yields a target OS started on the BMC that manages a target host partition through a loaded interface, with a reasonable expectation of success (this also matches Applicant’s stated purpose of avoiding BMC re-design and reducing cost).
Claim 12 recites the BMC of claim 1 in apparatus form (a target operating system and a target hardware interface configured to connect the target OS to a target host hardware partition and to manage it). It is rejected under the mapping of claim 1 above (Cudak FIGS. 1, 3, 13 in view of Quinn).
In regard to claim 18, Cudak teaches a server, comprising a Baseboard Management Controller (BMC) and a server host system, wherein the BMC comprises a target operating system and a target hardware interface, the server host system comprises a plurality of hardware partitions, and the target hardware interface establishes a connection between the target operating system and a target hardware partition among the plurality of hardware partitions (in Cudak: a server = multi-processor host system (plurality of partitioned nodes) plus a single BMC that manages each partitioned node through its interfaces (Abstract; FIGS. 1-2).
PNG
media_image4.png
522
379
media_image4.png
Greyscale
But Cudak does not expressly teach the BMC is configured to manage the target hardware partition through the target operating system. In the same field of endeavor, Quinn expressly teaches a target OS on the BMC (Abstract). Cudak’s PCIe multiplexer that selectably connects a single shared video/USB (KVM) controller to either of two partitioned nodes is a partition switching device connecting a shared interface to plural partitions, while exclusive resources are directly assigned to a single partition. Combined with Quinn’s per-core OS on the BMC, claim 18 are obvious for the reasons given for claim 1.
In regard to claim 19, Cudak teaches wherein the target hardware interface comprises: a target exclusive interface and/or a target shared interface, wherein the target exclusive interface is designed as a hardware interface that is only allowed to be accessed by a target processor core in which the target operating system is located, and the target shared interface is designed as a hardware interface that is allowed to be accessed by the target processor core and a reference processor core in a plurality of groups of processor cores; the target exclusive interface is directly connected to the target hardware partition; and the target shared interface is connected to a partition switching device, and the partition switching device is separately connected to the target hardware partition and a reference hardware partition corresponding to the reference processor core (in Cudak: exclusive resources are directly connected/assigned to their partition (FIGS. 4-5), and a shared interface (video/USB/KVM) is connected through a PCIe multiplexer/switch, a partition switching device, that is selectably and separately connected to either partitioned node (FIG. 7, PCIe multiplexers 153/154 to CPUs 151/152; Summary). Quinn expressly teaches a target OS on the BMC (Abstract). Cudak’s PCIe multiplexer that selectably connects a single shared video/USB (KVM) controller to either of two partitioned nodes is a partition switching device connecting a shared interface to plural partitions, while exclusive resources are directly assigned to a single partition.
6. Claims 2-6, 13-14, 19 are rejected under AIA 35 U.S.C. § 103 as being unpatentable over Cudak et al. (“Cudak”) (US No. 12,067,404) in view of Quinn et al. (“Quinn”) (US No. 11,397,587) and further in view of Applicants Admitted Prior Arts (“AAPA”).
The examiner relies on the entire teachings of Cudak and Quinn and AAPA references; the applicant should carefully consider the entire teachings of the above-mentioned references to better understand the examiner’s position.
In regard to claim 2, Cudak teaches wherein loading the target hardware interface for the target operating system comprises: finding, from processor cores and hardware interfaces having a correspondence relationship, the target hardware interface corresponding to a target processor core used by the target operating system, wherein the hardware interfaces on the BMC are allocated to each group of processor cores according to hardware architectures of the hardware partitions corresponding to each group of processor cores, so as to obtain the processor cores and the hardware interfaces having the correspondence relationship; and loading the target hardware interface for the target operating system on the target processor core (in Cudak: resources (interfaces, PCIe ports, endpoint devices) are allocated to each partition according to that partition’s architecture/needs, and the corresponding interface is used to reach the partition (Summary; FIGS. 4-5). Cudak allocates host resources to host partitions; it does not describe allocating the BMC’s own hardware interfaces to groups of the BMC’s processor cores (each group running an OS) and locating the interface corresponding to the target core. Quinn expressly teaches allocating the BMC’s own hardware interfaces to groups of the BMC’s processor cores (each group running an OS) and locating the interface corresponding to the target core (in Quinn, supplies dedicating cores of a single multicore processor to different OSes with mutually-exclusive assigned resources (Abstract; claim 1). Combined with the conventional Linux device-tree mechanism admitted by Applicant (AAPA; Spec. pp. 16–17, 39: DTS/DTB describing each device’s address/interrupt, loaded and analyzed by the kernel), allocating the BMC interfaces per BMC core group and loading the target interface on the target core is obvious). Applicant’s own specification admits that describing hardware to an operating system per-core via a device tree is conventional. Given Quinn’s isolated per-core OSes and Cudak’s per-partition resource assignment, using a per-core device tree to allocate each BMC hardware interface to the BMC core group whose OS manages the corresponding host partition, and loading that interface on the target core, is the predictable use of a known technique to yield a predictable result.
In regard to claim 3, AAPA teaches wherein loading the target hardware interface for the target operating system on the target processor core comprises: analyzing a target device tree of the target processor core to obtain the target hardware interface, wherein the hardware interfaces on the BMC are allocated to each group of processor cores to obtain the processor cores and the hardware interfaces having the correspondence relationship, and physical addresses of the hardware interfaces on the BMC use a unified addressing scheme; loading a driver of the target hardware interface on the target processor core; and booting a file system of the target operating system on the target processor core, so as to complete bootstrapping process of the target operating system (in AAPA (Spec. pp. 16–17, 39): the Linux device tree (DTS compiled to DTB) is analyzed by the kernel to provide each device’s address/interrupt, the driver is loaded, and the file system is booted, admitted conventional. Cudak: resources assigned to different partitions occupy mutually-exclusive (non-overlapping) address/port assignments so partitions do not conflict (Summary; FIGS. 4-5) - a unified addressing scheme. Quinn: each OS boots on its dedicated core subset (Abstract). The combination renders obvious analyzing a per-core device tree, loading the driver, and booting the target OS file system on the target BMC core). The device-tree analysis, driver loading, and file-system boot are Applicant-admitted conventional Linux operations; a unified (mutually-exclusive) address space for per-partition/per-core resources is taught by Cudak and is inherent in independent per-core device trees that supply non-overlapping hardware views. Combining these with Quinn’s per-core OS boot is obvious.
In regard to claim 4, Cudak teaches wherein before loading the target hardware interface for the target operating system, the method further comprises: acquiring the plurality of hardware partitions of a host system; allocating the processor cores on the BMC for each target hardware partition among the plurality of hardware partitions to obtain the target processor cores, and allocating the hardware interfaces on the BMC for each target hardware partition to obtain the target hardware interfaces, wherein the target processor core at least meets a management running requirement of the target hardware partition, and the target hardware interface at least meets a hardware connection requirement of the target hardware partition; and establishing a correspondence relationship between the target processor core and the target hardware interface, so as to obtain the processor cores and the hardware interfaces having the correspondence relationship (in Cudak: the BMC obtains an inventory of the system and its resource types before the firmware interface boots, determines the partitioning configuration, and assigns cores/memory/I-O to each partitioned node so the node’s requirements are met (Summary: “obtaining an inventory… before a firmware interface boots”; assigning resources to “approximate the processor ratio”). Cudak assigns host resources to host partitions rather than establishing a correspondence between the BMC’s own cores and the BMC’s own interfaces. However, Quinn expressly teaches establishing a correspondence between the BMC’s own cores and the BMC’s own interfaces (in Quinn supplies dedicating BMC cores to OSes (Abstract; claim 1); applying Cudak’s pre-boot acquire/allocate methodology to the BMC’s cores and interfaces yields the claimed correspondence). Cudak expressly acquires the partition inventory and allocates resources to satisfy each partition’s requirements before boot. Extending that same acquire-and-allocate methodology to the BMC’s own cores/interfaces (per Quinn’s per-core OS model) to establish a core-to-interface correspondence is an obvious application of a known technique.
In regard to claim 5, Cudak teaches wherein allocating the processor cores on the BMC for each target hardware partition among the plurality of hardware partitions to obtain the target processor cores comprises at least one of the following: evenly allocating the processor cores on the BMC to each target hardware partition; or allocating one or more processor cores on the BMC for the target hardware partition according to a running architecture of each target hardware partition among the plurality of hardware partitions, so as to obtain the target processor cores (in Cudak expressly teaches both allocation options: assigning resources evenly, and assigning resources to each partitioned node proportionally to the partition’s architecture/needs (to “approximate the processor ratio”) (Summary; FIGS. 6A-6B)).
In regard to claim 6, Cudak teaches wherein allocating the hardware interfaces on the BMC for each target hardware partition to obtain the target hardware interfaces comprises at least one of the following: when there is a first type of hardware interfaces on the BMC that has a number of resources greater than or equal to a number of resources required in the plurality of hardware partitions, allocating, according to the hardware architecture of each target hardware partition, the first type of hardware interfaces to the target hardware partition as target exclusive interfaces in the target hardware interfaces, wherein the target exclusive interface is designed as a hardware interface that is only allowed to be accessed by the target processor core; or when there is a second type of hardware interfaces on the BMC that has a number of resources less than a number of the resources required in the plurality of hardware partitions, establishing, as a target shared interface in the target hardware interfaces, a shared relationship between the target processor core and a reference processor core in a plurality of groups of processor cores on the BMC with respect to the second type of hardware interfaces, wherein the target shared interface is designed as a hardware interface that is allowed to be accessed by the target processor core and the reference processor core in the plurality of groups of processor cores (in Cudak teaches both an exclusive assignment (a PCIe port/endpoint device assigned to one partition, the port not initialized for the other partition, so the resource is isolated to that node) and a shared assignment (a multi-host controller / CXL-shared DIMMs / a PCIe-multiplexed KVM shared between two partitioned nodes) (Summary; FIGS. 5A-5B, 6A-6B, 7). Quinn teaches exclusive, non-overlapping per-core resource assignment (Abstract; claim 1). The ‘≥/< resources required’ selection logic (assign exclusively when supply suffices; share when scarce) is an obvious resource-optimization consistent with Cudak’s ratio-based assignment and its multi-host sharing of scarce resources. Cudak teaches allocating a resource exclusively to a partition when it can be dedicated, and sharing a multi-host resource (e.g., a PCIe device behind a multiplexer, or CXL-shared memory) between partitions when it cannot be dedicated. Selecting exclusive vs. shared allocation based on whether the interface has resources sufficient for the partitions is the obvious, predictable resource-management choice; combined with Quinn’s per-core OS/resource isolation the limitation is met.
Claim 13 (target exclusive interface and/or target shared interface) is rejected under the mapping of claim 6. Claim 14 (a target device tree deployed in the target OS configured to load a driver of the target hardware interface; unified addressing scheme) is rejected under the mapping of claims 2-3 (Cudak + Quinn + AAPA device tree).
In regard to claim 19, Cudak teaches the target exclusive interface is directly connected to the target hardware partition; and the target shared interface is connected to a partition switching device separately connected to the target hardware partition and a reference hardware partition corresponding to the reference processor core (in Cudak: exclusive resources are directly connected/assigned to their partition (FIGS. 4-5), and a shared interface (video/USB/KVM) is connected through a PCIe multiplexer/switch, a partition switching device, that is selectably and separately connected to either partitioned node (FIG. 7, PCIe multiplexers 153/154 to CPUs 151/152; Summary). Quinn: per-core OS (Abstract). Cudak’s PCIe multiplexer that selectably connects a single shared video/USB (KVM) controller to either of two partitioned nodes is a partition switching device connecting a shared interface to plural partitions, while exclusive resources are directly assigned to a single partition. Combined with Quinn’s per-core OS on the BMC, claim 19 are obvious for the reasons given for claim 6.
7. Claims 7-9 under 35 U.S.C. 103 over Cudak in view of Quinn and further in view of Bonola et al. (“Bonola”) (US No. 9,032,128).
The examiner relies on the entire teachings of Cudak and Quinn and Bonola references; the applicant should carefully consider the entire teachings of the above-mentioned references to better understand the examiner’s position.
In regard to claim 7, Cudak teaches a shared interface (PCIe-multiplexed KVM / multi-host device) is shared between two partitioned nodes and a mechanism selects which node accesses it (FIG. 7; Summary). Quinn: per-core OSes. Cudak/Quinn do not disclose the request/grant handshake by inter-core interrupts. In the same field of endeavor, Bonola teaches when the target OS needs to access the target shared interface, sending, by the target OS, a first interrupt request to the reference processor core requesting use of the shared interface; receiving a second interrupt request returned by the reference OS indicating the shared interface has been released; and, in response, accessing the shared interface (as shown in Fig. 1, which is reproduced below for ease of reference and convenience, Bonola teaches the request/grant handshake by inter-core interrupts Bonola: generating and delivering inter-processor interrupts (IPIs) among cores of a multi-core processor to coordinate/communicate between cores, in a system including a PCIe switch (Abstract; FIG. 1, PCIe switch 136; IPI generation).
PNG
media_image5.png
943
718
media_image5.png
Greyscale
Cudak establishes that a scarce interface is shared between partitions and that access must be arbitrated so the partitions do not conflict; Quinn establishes independent per-core OSes on the BMC; and Bonola teaches inter-processor (inter-core) interrupts as the mechanism for cores to signal one another in a multi-core, PCIe-switched system. It would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention to arbitrate access to Cudak’s shared interface between the two BMC core OSes using a request/grant/release/notify handshake carried by inter-core interrupts (Bonola), because inter-core interrupts are the conventional, predictable means of mutual-exclusion signaling between cores running independent OSes, yielding conflict-free time-shared access with a reasonable expectation of success. Applicant’s disclosure implements the handshake with standard Linux Software-Generated Interrupts (SGIs), confirming the use of a conventional inter-core interrupt mechanism.
In regard to claim 8, Bonola teaches wherein sending, by the target operating system, the first interrupt request to the reference processor core in the plurality of groups of processor cores on the BMC comprises: determining, by the target operating system, whether the target shared interface has been occupied; and when the target operating system does not occupy the target shared interface, sending the first interrupt request to the reference processor core by the target operating system (in Bonola: checking whether the shared resource is currently occupied before signaling an IPI request is an obvious mutual-exclusion refinement). Same rationale/reason to combine as claim 7.
In regard to claim 9, Bonola teaches wherein after accessing the target shared interface through the target operating system, the method further comprises: receiving, by the target operating system, a third interrupt request sent by the reference operating system, wherein the third interrupt request is used for requesting the use of the target shared interface; determining, by the target operating system, whether the target shared interface is being used; when the target shared interface is being used, waiting for an end of the use of the target shared interface; when the target shared interface is not used or the use of the target shared interface is ended, releasing the target shared interface; and sending a fourth interrupt request to the reference operating system by the target operating system, wherein the fourth interrupt request is used for indicating that the target shared interface has been released (in Bonola: the reciprocal request/wait/release/notify handshake, implemented with distinct inter-core interrupt requests, is the obvious counterpart of the claims 7-8 protocol for arbitrating mutually-exclusive access to the shared interface between the two cores). Same rationale/reason to combine as claim 7.
8. Claims 10, 11, 15, 16, 17 and 23 under 35 U.S.C. 103 over Cudak in view of Quinn and further in view of Żyjewski et al. (“Żyjewski”) “Overview of Secure Boot state in the ARM-based SoCs (2nd Edition),” (Open Source Firmware, BMC and Bootloader devroom, FOSDEM 2023)
The examiner relies on the entire teachings of Cudak and Quinn and Żyjewski references; the applicant should carefully consider the entire teachings of the above-mentioned references to better understand the examiner’s position.
In regard to claim 10, Cudak teaches BMC boot with a Root of Trust and firmware images loaded per partition (Summary; FIG. 1, RoT 66, firmware flash) and Quinn teaches a kernel per core group (Abstract), but Cudak/Quinn do not teach/name wherein starting up the target operating system on the BMC comprises: executing, on the BMC, a Secondary Program Loader (SPL) to load a Universal Boot Loader (Uboot loader); and starting up a kernel of a corresponding target operating system on each group of processor cores by the Uboot loader. In the same field of endeavor, Żyjewski expressly names the SPL[Wingdings font/0xE0] U-Boot chain (as shown in Fig. 1, which is reproduced below for ease of reference and convenience, Żyjewski teaches the conventional ARM-SoC boot chain in which the SPL loads U-Boot, which in turn boots the OS kernel (‘SPL verifies U-Boot which verifies Kernel’). Żyjewski documents the standard, well-known ARM/BMC-SoC chain of trust: a boot ROM verifies the SPL, the verified SPL loads and verifies U-Boot, and U-Boot boots the OS kernel, each stage using a computed hash compared against a stored/signed verification value. Cudak already provides a Root-of-Trust secure boot on the BMC. It would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention to implement Cudak/Quinn’s BMC boot using this conventional SPL[Wingdings font/0xE0] Boot verified-boot sequence to obtain the recited staged secure boot with a predictable result and a reasonable expectation of success. Applicant’s specification itself describes these boot operations as conventional (‘can be, but is not limited to’).
In regard to claim 11, Żyjewski teaches wherein executing, on the BMC, the SPL to load the Uboot loader comprises: powering on the BMC, and waking up one processor core; booting a boot loader in a boot storage to execute on the processor core; performing secure boot verification on the SPL through the boot loader; and when the SPL passes the secure boot verification, executing the SPL to boot the Uboot loader to execute a code (in Żyjewski: on power-up the boot ROM (boot loader in boot storage) establishes the root of trust and verifies the SPL; upon successful verification the SPL executes and boots U-Boot (BootROM [Wingdings font/0xE0] SPL [Wingdings font/0xE0] U-Boot verified-boot chain). Same rationale/reason to combine as claim 10.
In regard to claim 15, Żyjewski teaches further a Universal Boot Loader (Uboot loader), wherein the Uboot loader is configured to start up a kernel of a corresponding target operating system on each group of processor cores on the BMC; and a kernel of the target operating system is configured to analyze the driver of the target hardware interface loaded by the target device tree (in Żyjewski: U-Boot boots the kernel. AAPA: the kernel analyzes the device-tree-loaded driver (Spec. pp. 16-17). Quinn: per-core OS). Same rationale/reason to combine as claim 10.
In regard to claim 16, Żyjewski teaches further a Secondary Program Loader (SPL), wherein the SPL is configured to boot the Uboot loader to execute a code (in Żyjewski: SPL boots U-Boot). Same rationale/reason to combine as claim 10.
In regard claim 17, Żyjewski teaches further a boot storage, wherein the boot storage is configured to perform secure boot verification on the SPL (in Żyjewski: the boot ROM/boot storage verifies the SPL. Cudak: RoT verification (Summary). Same rationale/reason to combine as claim 10.
In regard to claim 23, Żyjewski teaches wherein performing the secure boot verification on the SPL through the boot loader, comprises: reading a code of the SPL and a verification code by the boot loader; obtaining a calculated value by performing an operation on the code of the SPL through an agreed-upon calculation method; comparing the calculated value with a read verification code; and when the calculated value is consistent with the verification code, a check the verification code, the checking result is abnormal (in Żyjewski: FIT verified-boot, a hash (e.g., SHA) of the image, is computed and compared against the signed/stored verification value; a match yields a valid (normal) result and a mismatch yields an invalid (abnormal) result. Cudak: RoT hash/signature verification (Summary). Same rationale/reason to combine as claim 10.
Examiner's note:
Examiner has cited particular columns and line numbers in the references applied to the claims above for the convenience of the Applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the Applicant in preparing responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passages as taught by the prior art or disclosed by the Examiner.
Conclusion
Claims 1-19, 23 are rejected. Claims 20-22 are cancelled.
The prior arts made of record and not relied upon are considered pertinent to applicant's disclosure.
Cudak et al., US 11,983,540, teach “Partitioning a multi-processor system having a single baseboard management controller” (parent of the Cudak family; single BMC managing plural host partitions).
Cudak et al., US 11,934,661, teach companion partitionable-BMC family members (disparate-memory partitioning; KVM multiplexer to plural CPUs).
Fukyo et al., US 11,809,364, teach adaptable BMC using firmware-less interface chips for multi-node configurations.
Bhatia et al., US 9,367,419, teach single BMC providing out-of-band access to multiple managed computer nodes.
Huawei, CN 103608792, teaches resource isolation under a multi-core architecture; a boot loader stores and runs a separate OS kernel image per processing core (very close to the per-core-OS aspect).
Su et al., US 9,519,652, teach operating a shared hardware resource in an asynchronous multiprocessing system (lock-register arbitration).
Nash et al., US 10,503,687, teach multi-host PCIe switching based on interrupt vector from a PCIe device (shared PCIe + interrupt routing).
Zimmer et al., US 8,151,027, teach system-management-mode inter-processor-interrupt redirection.
Itkin et al., US 10,148,746, teach multi-host NIC in which a common BMC controls shared resources for multiple hosts.
Cho et al., US 11,151,255, teach BMC secure-boot chain of trust with staged hash verification.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to examiner Raymond Phan, whose telephone number is (571) 272-3630. The examiner can normally be reached on Monday-Friday from 6:30AM- 3:00PM. The Group Fax No. (571) 273-8300.
Communications via Internet e-mail regarding this application, other than those under 35 U.S.C. 132 or which otherwise require a signature, may be used by the applicant and should be addressed to [raymond.phan@uspto.gov].
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.
All Internet e-mail communications will be made of record in the application file. PTO employees do not engage in Internet communications where there exists a possibility that sensitive information could be identified or exchanged unless the record includes a properly signed express waiver of the confidentiality requirements of 35 U.S.C. 122. This is more clearly set forth in the Interim Internet Usage Policy published in the Official Gazette of the Patent and Trademark on February 25, 1997 at 1195 OG 89.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see hop://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
Any inquiry of a general nature or relating to the status of this application should be directed to the TC 2100 central telephone number is (571) 272-2100.
/RAYMOND N PHAN/
Primary Examiner, Art Unit 2175
Prosecution Insights