DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
The present application is being examined under the claims filed 03/18/2026. Claims 1-11, 13-19, 21-26, and 28-30 are pending. Claims 12, 20, and 27 are canceled. Claims 1, 3-11, 13-19, 21-26, and 28 are amended. Claims 1-11, 13-19, 21-26, and 28-30 are rejected.
Response to Arguments
I. Applicant's arguments filed 03/18/2026 have been fully considered but they are not persuasive.
II. Regarding claim 8 applicant argues that Iyengar and Chen in view of Doerr does not teach claim 8, specifically the limitation “the integrated circuit device further comprising validation circuitry that is configured to output a boot complete signal based on the first validation status signal, the second validation status signal, and the third validation status signal.” Examiner respectfully disagrees.
Iyengar is directed towards a multi-stage boot-up sequence of a SoC containing multiple processors. Iyengar teaches the integrated circuit device further comprising validation circuitry that is configured to output a […] signal based on the first validation status signal, the second validation status signal (Iyengar par. 47, the multicore scheduling protocol keeps track (e.g., in suitable memory on SoC 100 such as SRAM, DRAM, etc.) of a state of each of the APs 112, 121, and 122 including whether the APs are in a powered off state; also see Iyengar claims 3 and 7, the first processor is used to perform tasks related to verification of the second processor and the second processor returns results [i.e., sends verification signals]). While Iyengar does not teach validation circuitry configured to output a boot complete signal based on the first validation status signal, the second validation status signal, and the third validation status signal, the deficiency is cured by Doerr, which is also directed to a method to complete a multiprocessor boot. Doerr teaches an integrated circuit device (Doerr Fig. 4, HW/SW operating stack of the multiprocessor architecture (see. par 49)), further comprising validation circuitry (Doerr Fig. 11B, secure boot control section [see par. 94]) configured to output a boot complete signal based on [input signals] (Doerr par. 173, signals boot is complete if boot code completes without errors). One of ordinary skill in the art having the boot status signals of Iyengar and the boot verification method of Doerr, the motivation being to accurately reflect the status of the system (Doerr par. 174 and 218, boot completing or not completing is signaled).
III. Applicant’s arguments with respect to claim 1 (and analogously claims 9, 17, and 25) have been considered but are moot due to the new grounds of rejection necessitated by the amendment.
Claim Interpretation
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.
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.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not 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 not 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 function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) (Claims 17-19 and 21-24) 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.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-7, 9-11, 13-15, 17-19, 21-23, and 25-26, and 28-30 are rejected under 35 U.S.C. 103 as being unpatentable over Iyengar (US 2019/0095220 A1) [previously cited] in view of Chen (US 2007/0157012 A1) [previously cited] and Chang et. al (US 2017/0206937 A1).
Regarding Claim 1, Iyengar discloses an integrated circuit device (Iyenger Fig. 1, SoC 100 is an integrated circuit with multiple CPUs [111, 112, 114, 121, 122], which constitute dies), comprising:
[a circuit board] (Iyengar FIG. 1 and par. 27, all components of the SoC are packaged together on a board; also see Iyengar par. 31, components of SoC communicate over a chip-to-chip interface (e.g., transport layer); also see instant app. par. 26, "IC chip in an IC package may be configured as an SoC"… IC chips are electrically coupled to other IC chips and/or to other components in the IC package through electrical coupling to metal lines in the package substrate");
a main die on [the circuit board] (Iyengar Fig. 6, first processor [i.e., main die]; and Iyengar Fig. 1, Cluster 110 and 120 and CPUSS 103 [i.e., processors are located within the board for SoC 100]; also see Iyengar par. 40-41, CPU core 111 may be used as the primary core and referred to as a boot strap processor (BSP) 111), wherein the main die is configured to execute a first boot-up sequence to prepare the main die for operation and a first validation test (Iyengar Fig. 6 and par. 78-79, step 605 first processor initiates the boot-up [i.e., boot-up sequence]; and Iyengar par. 50-51, each processor runs programs (such as SampleMpTest) [i.e., validation test] in the pre-boot environment; also see Iyengar par. 10, applications may be run in the pre-boot environment, such as applications that test and verify functionality of CPU core), and output a trigger signal (Iyengar Fig. 6 and par. 78-79, step 605 first processor [i.e., main die] initiates the boot-up, and step 610, it triggers [i.e., send a signal to start] a process of the second processor); and
a first companion die [on the circuit board] (Iyengar Fig. 6, second processor [i.e., companion die]; and Iyengar Fig. 1, Cluster 110 and 120 and CPUSS 103 [i.e., processors are located within the board for SoC 100]; also see Iyengar par. 41, CPU cores 112, 121, and 122 may be used as secondary cores and referred to as auxiliary processors (APs) 112, 121, and 122), wherein the first companion die is configured to execute a second boot-up sequence to prepare the first companion die for operation and a second validation test (Iyengar FIG, 6, second processor is scheduled for boot up tasks; and Iyengar par. 50-51, each processor runs programs (such as SampleMpTest) [i.e., validation test] in the pre-boot environment; also see Iyengar par. 10, applications may be run in the pre-boot environment, such as applications that test and verify functionality of CPU core), in response to the trigger signal received from main die via [the circuit board] (Iyengar Fig. 6, at step 615 second processor executes one or more boot up tasks [in response to signal sent by first processor in step 610]), wherein the first companion die is configured to provide peripheral functionality of the integrated circuit device (Iyengar par. 3, integrated circuit device supports peripheral functions; and Iyengar par. 55, serial port library 222 is a library that provides serial I/O support [i.e., peripheral functionality] for auxiliary processors), the first validation test at least partially overlapping the second boot-up sequence or the second validation test in time (Iyengar Fig. 6, step 620, one or more of tasks executed by the first processor are in parallel with the second processor completing boot up tasks; and Iyengar par. 61, SampleMpTest 316 and SampleMpTest 318 are running on AP 112 and AP 121 respectively [i.e., the first test is overlapping the second test in time]; also see Iyengar par. 74, it is beneficial to run parallel pre-boot environments across multiple cores and allow multiple cores to be tested in the pre-boot environment), […].
Iyengar does not explicitly disclose:
a substrate;
a main die on the substrate;
a first companion die on the substrate;
wherein the first validation test comprises generating a test pattern configured to evaluate at least one of timing, speed, power consumption, or signal integrity of the first main die.
In the analogous art of performing a system boot of multiple components with verification, Chen teaches an integrated circuit device (Chen FIG 1 and par. 18, multiple CPU system 100):
wherein the first validation test comprises generating a test pattern configured to evaluate at least one of timing, speed, power consumption, or signal integrity of the main die (Chen par. 24, during the boot, general processing instructions (GPIs) include instructions for running one or more test patterns so that the host CPU 214 may adjust an optimal clock rate [i.e., speed] prior to completion of the initial boot sequence);
Therefore, it would have been obvious of one of ordinary skill in the art, having the teachings of Iyengar and Chen before him, before the effective filing date of the claimed invention, to combine Iyengar’s implementation of using a validation test for speed and timing at boot with Chen’s use of a test pattern to run a validation test, the motivation being to ensure optimal configuration settings for the system (Chen par. 41, test patterns determine configuration settings, such as an optimal clock rate, that provide maximum performance during data processing within the multiple CPU system).
Iyengar in view of Chen does not explicitly teach:
a substrate;
a main die on the substrate;
a first companion die on the substrate;
In the analogous art of arranging dies on a SoC, Chang teaches an integrated circuit device (Chang FIG. 1, PCB 10), comprising:
a substrate (Chang par. 19, PCB 10 mechanically supports and electrically connects electronic components using conductive tracks, traces, pads and other features etched from copper sheets laminated onto a non-conductive substrate);
a main die on the substrate (Chang par. 21, Package-on-Package (PoP) stacks chips in a 3D structure that allows for denser packing and it is used for memories on top of processors [i.e., dies] to form a PoP SoC configuration);
a first companion die on the substrate (Chang par. 22, PoP 20 comprises a bottom package 21 comprising a SoC 211 that may integrate one or more processing cores [i.e., secondary processors are companion dies]);
Therefore, it would have been obvious of one of ordinary skill in the art, having the teachings of Iyengar, Chen, and Chang before him, before the effective filing date of the claimed invention, to combine Iyengar and Chen’s implementation of using a validation test for speed and timing at boot on a system-on-chip (SoC) with Chang’s use of a substrate in the packaging, the motivation being to improve power usage and optimize size (Chang par. 4, in order to meet the stringent power and space constraints common to mobile devices, these chips combine a central processing unit (CPU) with other components into a single compact physical package).
Regarding Claim 2, Iyengar in view of Chen and Chang discloses the integrated circuit device of claim 1, wherein the trigger signal initiates the second boot-up sequence before the first boot-up sequence completes (Iyengar Claim 1, first processor schedules [i.e., triggers] boot-up tasks for second processor and first processor executes one or more additional tasks in parallel with the second processor executing the one or more boot-up tasks [also see par. 40-41]).
Regarding Claim 3, Iyengar in view of Chen and Chang discloses the integrated circuit device of claim 1, the first main die comprises a plurality of first subsystems brought up by the first boot-up sequence (Iyengar par. 33, first bootloader [which runs on the first processor] may initialize DRAM controller 170 and DRAM 190, storage controller 180 and storage 195, boot I/F controller 183 [which are subsystems]; and par. 33, BL1 a may further boot by controlling execution of additional firmware images by other subsystems); and
the first companion die comprises a plurality of second subsystems brought up by the second boot-up sequence (Iyengar par. 33, BL1 controlling execution of additional firmware images, such as bootloaders BL2, BL3, and BL4; and Iyengar par. 34, the first firmware image executed on the SoC enables a scheduler to enable multi core optimizations to allow multiple CPU cores [i.e. dies] to execute additional firmware images during boot), at least a portion of the plurality of first subsystems and at least a portion of the plurality of second subsystems being brought up concurrently in time (Iyengar Claim 1 and Fig. 6, step 620, one or more of tasks executed by the first processor are in parallel with the second processor completing boot up tasks).
Regarding Claim 4, Iyengar in view of Chen and Chang discloses the integrated circuit device of claim 1, wherein:
the first main die comprises a first controller configured to perform the first validation test of the first main die (Iyengar par. 53, core driver 212 (e.g., referred to as MpCoreDxe) [i.e., controller] executes on BSP 111 [i.e., main die] and is the core driver that implements the scheduling and I/O services; and Iyengar par. 57, to execute code (e.g., an application shown as SampleMpTest) [i.e., validation test], an entry point entity 312 receives a system table 350 (e.g., a UEFI system table) that points to code for services that execute on the BSP; also see); and
the first companion die comprises a second controller configured to perform the second validation test of first companion die (Iyengar par. 42-43, each auxiliary processor 112, 121, and 122 [i.e., multiple dies] runs an auxiliary kernel (AK) [i.e., controller] to perform services provided as part of the core pre-boot environment stack; and Iyengar par. 58, AK 314 is used to execute SampleMpTest 316 [i.e., validation test]).
Regarding Claim 5, Iyengar in view of Chen and Chang discloses the integrated circuit device of claim 1, further comprising:
a second companion die coupled to the first companion die (Iyenger Fig. 1, SoC 100 is an integrated circuit with multiple CPUs in clusters [111, 112, 114, 121, 122]) and […].
wherein the [main die] is configured to execute a [first] boot-up sequence to prepare the [first companion die] for operation (Iyengar Fig. 6 and par. 78-79, step 605 first processor initiates the boot-up [i.e., boot-up sequence]; and Iyengar par. 50-51, each processor runs programs (such as SampleMpTest) [i.e., validation test] in the pre-boot environment; also see Iyengar par. 10, applications may be run in the pre-boot environment, such as applications that test and verify functionality of CPU core), wherein the [first] boot-up sequence of the [first main die] is configured to trigger the [second] boot-up sequence (Iyengar Fig. 6 and par. 78-79, step 605 first processor [i.e., main die] initiates the boot-up, and step 610, it triggers a process of the second processor [i.e., companion die]), and the [first] boot-up sequence at least partially overlapping the [second] boot-up sequence in time (Iyengar Fig. 6, step 620, one or more of tasks executed by the first processor are in parallel with the second processor completing boot up tasks; and Iyengar par. 61, SampleMpTest 316 and SampleMpTest 318 are running on AP 112 and AP 121 respectively [i.e., the first test is overlapping the second test in time]; also see Iyengar par. 74, it is beneficial to run parallel pre-boot environments across multiple cores and allow multiple cores to be tested in the pre-boot environment).
Iyengar in view of Chen and Chang does not explicitly disclose:
a second companion die […], wherein the second companion die is configured to execute a third boot-up sequence to prepare the second companion die for operation, wherein the second boot-up sequence of the first companion die configured to trigger the third boot-up sequence, and the second boot-up sequence at least partially overlapping the third boot-up sequence in time.
While Iyengar does not explicitly teach this operation between a first and second companion die, the operation is explicitly described between a first main die and first companion die as mapped above and in respect to claim 1.
Therefore, it would have been obvious of one of ordinary skill in the art, having the teachings of Iyengar, before the effective filing date of the claimed invention, to continue the same approach of booting and verification for further dies (which are disclosed, see Iyenger Fig. 1, SoC 100 is an integrated circuit with multiple CPUs in clusters [111, 112, 114, 121, 122]) in order to beneficially reduce boot time (Iyengar par. 41) and to allow multiple cores to be tested in the pre-boot environment (Iyengar par. 41).
Regarding Claim 6, Iyengar in view of Chen and Chang discloses the integrated circuit device of claim 5, wherein the [first] validation test of the first [main die] at least partially overlaps the [second] boot-up sequence in time (Iyengar Fig. 6, step 620, one or more of tasks executed by the first processor are in parallel with the second processor completing boot up tasks, where validation is a boot up task [see par. 32]; and Iyengar par. 61, SampleMpTest 316 and SampleMpTest 318 are running on AP 112 and AP 121 respectively [i.e., the first test is overlapping the second test in time]; also see Iyengar par. 74, it is beneficial to run parallel pre-boot environments across multiple cores and allow multiple cores to be tested in the pre-boot environment).
Iyengar in view of Chen and Chang does not explicitly teach:
wherein the second validation test of the first companion die at least partially overlaps the third boot-up sequence in time.
While Iyengar does not explicitly teach this operation between a first and second companion die, the operation is explicitly described between a first main die and first companion die as mapped above. Therefore, it would have been obvious of one of ordinary skill in the art, having the teachings of Iyengar, before the effective filing date of the claimed invention, to continue the same approach of booting and verification for further dies (which are disclosed, see Iyenger Fig. 1, SoC 100 is an integrated circuit with multiple CPUs in clusters [111, 112, 114, 121, 122]) in order to beneficially reduce boot time (Iyengar par. 41) and to allow multiple cores to be tested in the pre-boot environment (Iyengar par. 41).
Regarding Claim 7, Iyengar in view of Chen and Chang discloses the integrated circuit device of claim 5,
wherein the first validation test of the first main die at least partially overlaps the second boot-up sequence […] in time (Iyengar Fig. 6, step 620, one or more of tasks executed by the first processor are in parallel with the second processor completing boot up tasks, where validation is a boot up task [see par. 32]; and Iyengar par. 61, SampleMpTest 316 and SampleMpTest 318 are running on AP 112 and AP 121 respectively [i.e., the first test is overlapping the second test in time]; also see Iyengar par. 74, it is beneficial to run parallel pre-boot environments across multiple cores and allow multiple cores to be tested in the pre-boot environment).
Iyengar in view of Chen and Chang does not explicitly teach:
wherein the first validation test of the first main die at least partially overlaps the second boot-up sequence and the third boot-up sequence in time.
While Iyengar does not explicitly teach this operation between a first, second and third die, the operation is explicitly described between a first main die and first companion die as mapped above and in respect to claim 1. Therefore, it would have been obvious of one of ordinary skill in the art, having the teachings of Iyengar, before the effective filing date of the claimed invention, to continue the same approach of booting and verification for further dies (which are disclosed, see Iyenger Fig. 1, SoC 100 is an integrated circuit with multiple CPUs in clusters [111, 112, 114, 121, 122]) in order to beneficially reduce boot time (Iyengar par. 41) and to allow multiple cores to be tested in the pre-boot environment (Iyengar par. 41).
Regarding Claim 9, Iyengar discloses a method of booting an integrated circuit device (ICD) comprising a main die and a first companion die on a [circuit board] (Iyenger Fig. 1, SoC 100 is an integrated circuit with multiple CPUs [111, 112, 114, 121, 122] packaged together; and Iyengar par. 12, disclosure provides a method of enabling a multicore framework in a pre-boot environment).
The remaining limitations of claim 9 are similar in scope to claim 1 as addressed above and are thus rejected under the same rationale.
Regarding Claim 10, the claim is similar in scope to claim 2 as addressed above and is thus rejected under the same rationale.
Regarding Claim 11, the claim is similar in scope to claim 3 as addressed above and is thus rejected under the same rationale
Regarding Claim 13, the claim is similar in scope to claim 5 as addressed above and is thus rejected under the same rationale.
Regarding Claim 14, the claim is similar in scope to claim 6 as addressed above and is thus rejected under the same rationale.
Regarding Claim 15, the claim is similar in scope to claim 7 as addressed above and is thus rejected under the same rationale.
Regarding Claim 17, Iyengar discloses an integrated circuit device comprising a main die and a first companion die on a [circuit board] (Iyenger Fig. 1, SoC 100 is an integrated circuit with multiple CPUs [111, 112, 114, 121, 122] packaged together).
The remaining limitations of claim 17 are similar in scope to claim 1 as addressed above and are thus rejected under the same rationale.
Regarding Claim 18, the claim is similar in scope to claim 2 as addressed above and is thus rejected under the same rationale.
Regarding Claim 19, the claim is similar in scope to claim 3 as addressed above and is thus rejected under the same rationale.
Regarding Claim 21, the claim is similar in scope to claim 5 as addressed above and is thus rejected under the same rationale.
Regarding Claim 22, the claim is similar in scope to claim 6 as addressed above and is thus rejected under the same rationale.
Regarding Claim 23, the claim is similar in scope to claim 7 as addressed above and is thus rejected under the same rationale.
Regarding Claim 25, Iyengar discloses a main die on a [circuit board] included in an integrated circuit device (ICD) (Iyenger Fig. 1, SoC 100 is an integrated circuit with multiple CPUs in clusters [111, 112, 114, 121, 122] packaged together), comprising:
a plurality of subsystems (Iyengar par. 33, first bootloader [which runs on the first processor] may initialize DRAM controller 170 and DRAM 190, storage controller 180 and storage 195, boot I/F controller 183 [which are subsystems]);
one or more processors configured to prepare the plurality of subsystems for operation by executing a first boot-up sequence (Iyengar par. 33, first bootloader may initialize DRAM controller 170 and DRAM 190, storage controller 180 and storage 195, boot I/F controller 183); and
the one or more processors being configured to trigger a second boot-up sequence configured to prepare a second first companion die on the [circuit board] included in the ICD for operation, the first boot-up sequence at least partially overlapping the second boot-up sequence in time (Iyengar Fig. 6, step 620, one or more of tasks executed by the first processor are in parallel with the second processor completing boot up tasks [where initializing subsystem is a boot up task]; and Iyengar Figure 1B, showing multiple firmware tasks [for the boot up process] operating on different CPUS concurrently)).
The remaining limitations of claim 25 are similar in scope to claim 1 as addressed above and are thus rejected under the same rationale.
Regarding Claim 26, Iyengar in view of Chen and Chang discloses main die of claim 25, wherein the one or more processors are further configured to output a trigger signal that initiates the second boot-up sequence before the first boot-up sequence completes (Iyengar Fig. 6, at step 615 second processor executes one or more boot up tasks [in response to signal sent in step 610] and first processor continues to perform tasks in step 620).
Regarding Claim 27, Iyengar in view of Chen and Chang discloses main die of claim 25, wherein the first validation test is at least partially overlapping a second validation test of the first companion die in time (Iyengar Claim 1 and Fig. 6, step 620, one or more of tasks executed by the first processor are in parallel with the second processor completing boot up tasks, where validation is a boot up task [see par. 32]).
Regarding Claim 29, Iyengar in view of Chen discloses the integrated circuit device of claim 1, wherein the test pattern comprises at least one of clock signals, control signals, or test vectors (Chen par. 31, test patterns adjust an optimal clock rate prior to completion of the initial boot sequence, the test patterns were generated and an optimal clock rate [i.e., clock signals] of the host CPU).
Regarding Claim 30, the claim is similar in scope to claim 29 as addressed above and is thus rejected under the same rationale.
Claims 8, 16, and 24 are rejected under 35 U.S.C. 103 as being unpatentable over Iyengar in view of Chen and Chang, further in view of Doerr (US 2015/0026451 A1) [previously cited].
Regarding Claim 8, Iyengar in view of Chen discloses the integrated circuit device of claim 5,
wherein the second companion die comprises a third controller that is configured to perform a third validation test of the second companion die (Iyengar par. 42-43, each auxiliary processor 112, 121, and 122 [i.e., multiple dies, e.g., first, second, and third] runs an auxiliary kernel (AK) [i.e., controller] to perform services provided as part of the core pre-boot environment stack; and Iyengar par. 58, AK 314 is used to execute SampleMpTest 316 [i.e., validation test]), the first controller being configured to output a first validation status signal, the second controller being configured to output a second validation status signal, the third controller being configured to output a third validation status signal (Iyengar par. 47, multicore scheduling protocol keeps track (e.g., in suitable memory on SoC 100 such as SRAM, DRAM, etc.) of a state of each of the APs 112, 121, and 122 including whether the APs are in a powered off state, in a low powered on state (e.g., a WFI state), or in a powered on state running another task [i.e., status of the controllers is tracked by a protocol, which would require signals from each processor]; also see Iyengar claims 3 and 7, the first processor is used to perform tasks related to verification of the second processor and the second processor returns results [i.e., sends verification signals]);
Iyengar in view of Chen does not explicitly teach:
the integrated circuit device further comprising validation circuitry configured to output a boot complete signal based on the first validation status signal, the second validation status signal, and the third validation status signal.
In the analogous art of secure booting of a device with multiple processors, Doerr teaches an integrated circuit device (Doerr Fig. 4, HW/SW operating stack of the multiprocessor architecture (see. par 49)):
further comprising validation circuitry (Doerr Fig. 11B, secure boot control section [see par. 94]) configured to output a boot complete signal based on [input signals] (Doerr par. 173, signals boot is complete if boot code completes without errors).
Therefore, it would have been obvious of one of ordinary skill in the art, having the teachings of Iyengar, Chen, Chang, and Doerr before them, before the effective filing date of the claimed invention, to combine Iyengar, Chen, and Chang’s communication between booting concurrently booting processors with Doerr’s validation circuitry, the motivation being to accurately reflect the status of the system (Doerr par. 174 and 218, boot completing or not completing is signaled).
Regarding Claim 16, the claim is similar in scope to claim 8 as addressed above and is thus rejected under the same rationale.
Regarding Claim 24, the claim is similar in scope to claim 8 as addressed above and is thus rejected under the same rationale.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to COLE JIAWEI WENTZEL whose telephone number is (703) 756-4762. The examiner can normally be reached 9:30am-5:30pm ET (Mon-Fri).
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 on (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.
/C.J.W./Examiner, Art Unit 2175
/ANDREW J JUNG/Supervisory Patent Examiner, Art Unit 2175