DETAILED ACTION
Claims 1-15 are pending.
Notice of Pre-AIA or AIA Status
This Office Action is sent in response to Applicant’s Communication received on 04/29/2025 for application number 19/125,467.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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”) 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.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “flash boot loader module” in claim 11.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 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.
Claims 1, 2, 4-6, 8-10, 12, 13, 15 are rejected under 35 U.S.C. 103 as being unpatentable over Thompson (US 2019/0012483 A1) in view of Soenkens et al. (US 2021/0406375 A1) and in further view of Yamamoto et al. (US 2022/0300612 A1).
Regarding claim 1, Thompson teaches an electronic control unit for a vehicle, the electronic control unit (Figure 1, ECU 1) comprising:
a main processor (Figure 1, processor 2),
a memory (Figure 1, memory 14),
a hardware security module (Figure 1, hardware security module 15),
and the trust anchor is further configured to verify the integrity and authenticate the boot loader within the plurality of application cores (“The HSM is typically the only trusted part of the system, and can be used as the basis for a secure boot of a system, by authenticating the lowest-level bootloader” par 0005 and “In another embodiment, only a small so-called ‘boot-loader’ will be checked by the HSM, and the application processor will then execute that code. Within this code (which is now trusted) will reside the functions which check the remainder of the code” par 0028) and, if the boot loader is not authenticated, to download the rescue computer code, to install said rescue computer code in place of a first boot sequence of the boot loader and have the main processor execute said rescue computer code on the plurality of application cores (“If it is determined that the data in the non-volatile memory 14 b does not match its signature, the HSM 15 will read a fallback image from external memory 21 [downloading rescue code]… This fallback image is written to the non-volatile member 14 b [writing the retrieved fallback image into main system’s non-volatile memory 14b, corresponding to installing rescue code]. The fallback image will also be signed, and the HSM 15 will use its key to verify that the contents of the fallback image have not been tampered with. Only then will the HSM 15 allow the processor core 13 to execute the fallback image.” Par 0111).
However, Thompson does not explicitly teach a plurality of application cores, the memory being connected to the main processor via a data communication bus and storing a boot loader and application code intended to be executed by the main processor, on the plurality of application cores, said boot loader comprising several boot sequences and being configured, when executed by the main processor, to request verification of the integrity and authentication of the application code stored in the memory and to execute said application code on the plurality of application cores when said application code has been authenticated, the hardware security module comprising a trust anchor and a memory, the trust anchor being connected to the main processor and to the memory via the data communication bus and being configured to verify the integrity and authenticate the application code stored in the memory and to authorize the execution of said application code on the plurality of application cores, the application cores being connected to the main processor via the data communication bus.
In the analogous art, Soenkens teaches a plurality of application cores (“The control units include a processor including one or, typically including multiple processor cores” par 0003);
the memory being connected to the main processor via a data communication bus (“The shared memory may be connected to the host core and to the HSM core via individual connections or via a bus.” Par 0031) and storing a boot loader and application code intended to be executed by the main processor, on the plurality of application cores (“a host memory 8, in which programs… a loader program and application programs, and data are stored. Host core 2 is configured to execute programs stored in host memory 8.” Par 0028 and “The control units include a processor including one or, typically including multiple processor cores (also simply referred to as host or host system), which execute programs stored in a memory in order to achieve the functions of the control unit.” Par 0003) [memory stores loader and application programs to be executed on main processor’s cores],
said boot loader comprising several boot sequences (“The term “startup sequence” or startup refers in this case to steps carried out by the control unit initially after the startup until application programs, which implement the actual control functionality of the control unit, are up and running.” Par 0007 and Figure 2) and being configured, when executed by the main processor, to request verification of the integrity and authentication of the application code stored in the memory and to execute said application code on the plurality of application cores when said application code has been authenticated (“a loader program, which is configured to carry out initializations and to call up at least one of the application programs when it is executed by the host,” par 0009 and “authenticating at least one application program of the one or of the multiple application programs by the HSM using at least one application program signature stored in the data memory of the HSM; and executing the at least one application program by the host when the authentication of the at least one application program is successful.” Claim 15 and paragraphs 37, 31 and Figure 3),
the hardware security module comprising a trust anchor and a memory (“HSM 4 includes an HSM core 10, i.e., a processor, a program memory 12 for programs to be executed by the HSM core, and a data memory 14,” par 0029) [the HSM core may correspond to the trust anchor], the trust anchor being connected to the main processor and to the memory via the data communication bus (“The shared memory may be connected to the host core and to the HSM core via individual connections or via a bus.” Par 0031) and being configured to verify the integrity and authenticate the application code stored in the memory and to authorize the execution of said application code on the plurality of application cores (“The HSM is configured, in particular, to check the integrity of memory areas of the host memory in order to check the authenticity of computer programs contained in the respective memory area or of software and/or data contained therein.” Par 0010 and “authenticating at least one application program of the one or of the multiple application programs by the HSM using at least one application program signature stored in the data memory of the HSM; and executing the at least one application program by the host when the authentication of the at least one application program is successful.” Claim 15 and “HSM 4 includes an HSM core 10, i.e., a processor, a program memory 12 for programs to be executed by the HSM core” par 0029 and paragraphs 9, 37),
the application cores being connected to the main processor via the data communication bus (“The shared memory may be connected to the host core and to the HSM core via individual connections or via a bus.” Par 0031).
It would have been obvious to a person having ordinary skill in the art, having the teachings of Thompson and Soenkens before him before the effective filing date of the claimed invention, to have modified Thompson to incorporate the teachings of Soenkens to check the authenticity of the code to prevent a manipulated program from being executed. (Soenkens, paragraph 14)
However, Thompson and Soenkens do not explicitly teach the memory of the hardware security module stores rescue computer code, said rescue computer code being intended to be executed by the main processor on the plurality of application cores, and being configured to implement at least one diagnostic function of the electronic control unit when it is executed by the main processor, if the boot loader is not authenticated, to download the rescue computer code from the memory of the hardware security module to the memory.
In the analogous art, Yamamoto teaches the memory of the hardware security module stores rescue computer code (“each data such as a functional safety determination table 24, a key value/MAC value 25 for encryption/decryption, a reprogramming fail-safe code 26, and a fail-safe configuration 27 are mounted in a secure area (HSM Core) 20 in the CPU 3.” Par 0021 and Figure 1, secure area 20), said rescue computer code being intended to be executed by the main processor on the plurality of application cores, and being configured to implement at least one diagnostic function of the electronic control unit when it is executed by the main processor (“a diagnosis program which is mounted in the secure area and diagnoses abnormality of the code of the operation program” par 0008 and “the invalid program A11 in the non-secure area is rewritten to the reprogramming fail-safe code 26 (fail-safe program code) of the secure area (HSM Core) 20.” Par 0035) [the secure area stores diagnosis program for identifying error and a fail-safe rescue code that replaces and runs in place of invalid code],
if the boot loader is not authenticated, to download the rescue computer code from the memory of the hardware security module to the memory (“the invalid program A11 in the non-secure area is rewritten to the reprogramming fail-safe code 26 (fail-safe program code) of the secure area (HSM Core) 20.” Par 0035 and “in a case where the abnormality of the operation program in the non-secure area is diagnosed by the diagnosis program in the secure area, the control part rewrites the operation program in which the abnormality in the non-secure area is diagnosed with a fail-safe program code stored in the secure area on a basis of a determination result of the type of the abnormality.” Claim 4 and Figure 1 and Figure 3).
It would have been obvious to a person having ordinary skill in the art, having the teachings of Thompson, Soenkens and Yamamoto before him before the effective filing date of the claimed invention, to have modified Thompson and Soenkens to incorporate the teachings of Yamamoto to include rescue computer code to prevent malfunctions in the diagnostics themselves if the main processor is tampered with or becomes compromised. (Yamamoto, paragraph 6)
Regarding claim 2, Thompson, Soenkens and Yamamoto teach the electronic control unit as claimed in claim 1. Soenkens further teaches wherein the memory the hardware security module is a non-volatile memory (“A shared memory, in particular a flash memory, is typically provided, in which various memory areas are provided for host memory 8, program memory 12 of the HSM and data memory 14 of the HSM.” Par 0031) [flash memory is non-volatile memory].
Regarding claim 4, Thompson, Soenkens and Yamamoto teach the electronic control unit as claimed in claim 1. Yamamoto further teaches wherein the rescue computer code is stored in an application portion of the memory of the hardware security module (“the invalid program A11 in the non-secure area is rewritten to the reprogramming fail-safe code 26 (fail-safe program code) of the secure area (HSM Core) 20.” Par 0035 and paragraph 8, Figure 1) [fail-safe code 26 (recovery application) corresponds to an application portion of the secure area 20].
Regarding claim 5, Thompson, Soenkens and Yamamoto teach the electronic control unit as claimed in claim 1. Thompson further teaches wherein the trust anchor is further configured to verify the integrity and authenticate the rescue computer code (“If it is determined that the data in the non-volatile memory 14 b does not match its signature, the HSM 15 will read a fallback image from external memory 21. … This fallback image is written to the non-volatile member 14 b. The fallback image will also be signed, and the HSM 15 will use its key to verify that the contents of the fallback image have not been tampered with. Only then will the HSM 15 allow the processor core 13 to execute the fallback image.” Par 0111 and paragraph 20).
Regarding claim 6, Thompson, Soenkens and Yamamoto teach the electronic control unit as claimed in claim 1. Thompson further teaches wherein the trust anchor is further configured to execute an instruction to reset the electronic control unit (“writing of the changed loader program signature into the program memory of the HSM; and, preferably a restart of the control unit.” Par 0015 and paragraphs 13, 14).
Regarding claim 8, Thompson, Soenkens and Yamamoto teach a method of operation of an electronic control unit for a vehicle as claimed in claim 1. Thompson further teaches wherein the method comprises:
the trust anchor verifying the integrity of the boot loader within the plurality of application cores (“The HSM is typically the only trusted part of the system, and can be used as the basis for a secure boot of a system, by authenticating the lowest-level bootloader” par 0005 and “In another embodiment, only a small so-called ‘boot-loader’ will be checked by the HSM, and the application processor will then execute that code. Within this code (which is now trusted) will reside the functions which check the remainder of the code” par 0028);
if the verification of the integrity of the boot loader within the plurality of application cores is positive, the trust anchor authenticating the boot loader (“The HSM can also check that the bootloader has been correctly decrypted and that the decrypted bootloader matches its cryptographic signature using the same key that the HSM holds.” Par 0106 and “Within this code (which is now trusted) will reside the functions” par 0028) [if initial verification is successful, trust anchor authenticates boot loader by classifying it as trusted] and:
the boot loader sending the trust anchor a request to verify the integrity and to authenticate the application code stored in the memory (“Within this code (which is now trusted) will reside the functions which check the remainder of the code (which will typically form the application of the system).” Par 0028) [checks integrity of remaining system application code];
the trust anchor verifying the integrity and authenticating the application code stored in the memory (“The functions which check the remainder of the code will utilise the functions of the HSM to provide determinations of whether the application code (and any associated data) has been tampered with.” Par 0028) [the trust anchor verifies and authenticates whether application code has been tampered with];
the trust anchor authorizing the execution of said application code on the plurality of application cores (“the HSM controls the whole boot process and the application processor is blocked from performing any tasks at all until the HSM has validated the code that the processor will be running.” Par 0027 and “Thus, the data will only be allowed to be executed if the signature (typically cryptographic) is correctly verified.” Par 0023); and
the main processor executing, via the boot loader, said application code on the plurality of application cores (“the HSM controls the whole boot process and the application processor is blocked from performing any tasks at all until the HSM has validated the code that the processor will be running.” Par 0027 and “Thus, the data will only be allowed to be executed if the signature (typically cryptographic) is correctly verified.” Par 0023);
if the verification of the integrity of the boot loader within the plurality of application cores is negative (“If it is determined that the data in the non-volatile memory 14 b does not match its signature” par 0111):
the trust anchor downloading the rescue computer code (“If it is determined that the data in the non-volatile memory 14 b does not match its signature, the HSM 15 will read a fallback image [rescue code] from external memory 21 [downloading rescue code]” par 0111);
the trust anchor installing said rescue computer code in place of a first boot sequence of the boot loader (“This fallback image is written to the non-volatile member 14 b [writing the retrieved fallback image into main system’s non-volatile memory 14b, corresponding to installing rescue code].” Par 0111); and
the main processor executing said rescue computer code on the plurality of application cores (The fallback image will also be signed, and the HSM 15 will use its key to verify that the contents of the fallback image have not been tampered with. Only then will the HSM 15 allow the processor core 13 to execute the fallback image.” Par 0111).
Yamamoto further teaches the trust anchor downloading the rescue computer code from the memory of the hardware security module to the memory (“the invalid program A11 in the non-secure area is rewritten to the reprogramming fail-safe code 26 (fail-safe program code) of the secure area (HSM Core) 20.” Par 0035 and “in a case where the abnormality of the operation program in the non-secure area is diagnosed by the diagnosis program in the secure area, the control part rewrites the operation program in which the abnormality in the non-secure area is diagnosed with a fail-safe program code stored in the secure area on a basis of a determination result of the type of the abnormality.” Claim 4 and Figure 1 and Figure 3).
Contingent Limitation
Claim 8 recites the following contingent limitations:
(a) if the verification of the integrity of the boot loader within the plurality of application cores is positive, the trust anchor authenticating the boot loader …
(b) if the verification of the integrity of the boot loader within the plurality of application cores is negative, the trust anchor downloading the rescue computer code from the memory of the hardware security module to the memory …
These limitations are contingent because they recite steps that are only required to be performed if their conditions are met. Limitation (a) only needs to be performed if the verification of the boot loader is positive. Limitation (b) only needs to be performed if the verification of the boot loader is negative. These conditions are mutually exclusive, and therefore only one of limitations (a) and (b) can be performed. Therefore, the broadest reasonable interpretation (BRI) only requires one of either limitation (a) or (b).
Regarding claim 9, Thompson, Soenkens and Yamamoto teach the method as claimed in claim 8. Thompson further teaches wherein, if the verification of the integrity of the boot loader within the plurality of application cores is negative, the method further comprises a step of the trust anchor verifying the integrity and authenticating the rescue computer code (“If it is determined that the data in the non-volatile memory 14 b does not match its signature, the HSM 15 will read a fallback image from external memory 21… The fallback image will also be signed, and the HSM 15 will use its key to verify that the contents of the fallback image have not been tampered with. ” Par 0111) [trust anchor retrieves and authenticates fallback image if bootloader fails integrity verification].
Regarding claim 10, Thompson, Soenkens and Yamamoto teach the method as claimed in claim 8. Soenkens further teaches wherein, if the verification of the integrity of the boot loader within the plurality of application cores is negative, the method further comprises a step of the trust anchor executing an instruction to reset the electronic control unit (“when the authentication of the loader program is unsuccessful: stopping the control unit and/or sending or outputting an error message.” Claim 19 and paragraphs 17, 18, 42 and “The host is initially started by starting up or switching on the control unit in step 26 and the HSM is started in step 28. In the process, a firmware is typically executed by the host, which carries out or provides basic initializations and functions. A loader program 30 of the host is then called up by the firmware, which may carry out the further initializations” par 0033, and paragraph 43 and Figure 3).
Claim 15 corresponds to claim 10 and is rejected accordingly.
Regarding claim 12, Thompson, Soenkens and Yamamoto teach a non-transitory computer program product (Thompson, Figure 1, ECU 1) comprising a set of program code instructions which, when they are executed by a processor (Thompson, Figure 1, processor 2), configure the processor to implement one or more steps of the method as claimed in claim 8, said computer program product constituting the rescue computer code (Thompson, fallback image, paragraphs 111-112), said processor being the main processor (Thompson, Figure 1, processor 2).
Regarding claim 13, Thompson, Soenkens and Yamamoto teach the electronic control unit as claimed in claim 1. Soenkens further teaches wherein the memory of the hardware security module is a flash memory (“A shared memory, in particular a flash memory, is typically provided, in which various memory areas are provided for host memory 8, program memory 12 of the HSM and data memory 14 of the HSM.” Par 0031).
Claims 3 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Thompson, Soenkens and Yamamoto in further view of Wang (US 9,792,440 B1).
Regarding claim 3, Thompson, Soenkens and Yamamoto teach the electronic control unit as claimed in claim 1. However, Thompson, Soenkens and Yamamoto do not explicitly teach wherein a compressed image of the rescue computer code is stored in the memory of the hardware security module.
In the analogous art, Wang teaches wherein a compressed image of the rescue computer code is stored in the memory of the hardware security module (“stored compressed image or uncompressed copy of the program memory of the secondary electronic control unit 104A, which is stored in memory in the primary electronic control unit 102.” Col. 7, ll. 43-47 and “a compressed image of the at least the portion of the contents of the memory of the secondary ECU;” claim 16 and columns 5 (ll. 51-67) and 6 and Figure 2) [the contents of the memory of the secondary ECU that are a trusted reference (see column 6, lines 25-51) correspond to the rescue code; the primary ECU uses its security module response checker to store a compressed reference image of the secondary ECU’s memory contents to verify its state and maintain the system’s chain of trust].
It would have been obvious to a person having ordinary skill in the art, having the teachings of Thompson, Soenkens, Yamamoto and Wang before him before the effective filing date of the claimed invention, to have modified Thompson, Soenkens and Yamamoto to incorporate the teachings of Wang to store a compressed image in the memory of the HSM to verify a memory’s response which enabled the main processor to immediately detect unauthorized modifications and/or malware without executing insecure code. (Wang, col. 4-5)
Claim 14 corresponds to claim 3 and is rejected accordingly.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Thompson, Soenkens and Yamamoto in further view of Chopart et al. (US 2010/0098243 A1).
Regarding claim 7, Thompson, Soenkens and Yamamoto teach the electronic control unit as claimed in claim 1. However, Thompson, Soenkens and Yamamoto do not explicitly teach wherein the rescue computer code is further configured, when executed by the main processor, to implement a function of uploading the application code from the memory to a memory of a third-party device connected to the electronic control unit.
In the analogous art, Chopart teaches wherein the rescue computer code is further configured, when executed by the main processor, to implement a function of uploading the application code from the memory to a memory of a third-party device connected to the electronic control unit (“If the first configuration data, or in other words the “first configuration load” 30 are not present in storage memory 14 of on-board equipment item 10, boot sequence 20 launches execution of resident software 22” par 0020 and “Resident software 22 also comprises tools for communication with a centralized data loader (not illustrated), for example via a communication network, from which equipment item 10 is able to recover the files to be downloaded.” Par 0021 and “secure token 40, when connected to port 26 of equipment item 10, establishes secure communication with resident software 22,” par 0104 and paragraph 130 Figures 1-2) [the resident software may correspond to the rescue code that runs when the primary data is missing, and main processor communicates with external tools to recover the application code; the secure external medium 40 may correspond to a third party device, which contains memory 44, that is connected to the control unit via USB].
It would have been obvious to a person having ordinary skill in the art, having the teachings of Thompson, Soenkens, Yamamoto and Chopart before him before the effective filing date of the claimed invention, to have modified Thompson, Soenkens and Yamamoto to incorporate the teachings of Chopart to upload application code to a third party device to ensure secure processing operations and equip micro software with sensitive security data for subsequent execution of secure processing. (Chopart, paragraph 44)
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Thompson, Soenkens and Yamamoto in further view of Venkataraman et al. (US 2020/0184077 A1).
Regarding claim 11, Thompson, Soenkens and Yamamoto teach The method as claimed in claim 8. However, Thompson, Soenkens and Yamamoto do not explicitly teach wherein the step of the trust anchor verifying the integrity of the boot loader within the plurality of application cores comprises verifying the integrity of the first boot sequence of the boot loader within the plurality of application cores, and verifying the integrity of a flash boot loader module within the plurality of application cores, the verification of the integrity of the boot loader within the plurality of application cores being positive if and only if the results of said two verifications are positive.
In the analogous art, Venkataraman teaches wherein the step of the trust anchor verifying the integrity of the boot loader within the plurality of application cores comprises verifying the integrity of the first boot sequence of the boot loader within the plurality of application cores, and verifying the integrity of a flash boot loader module within the plurality of application cores, the verification of the integrity of the boot loader within the plurality of application cores being positive if and only if the results of said two verifications are positive (“The boot loader B 221, in this configuration, loads the code and data stored in the sections 220-1 to 220-N. The boot loader A 212, stored in the one-time programmable region 202, is a small footprint loader which verifies the integrity of the sections 220-0 to 220-N and loads the boot loader B 221 when the integrity is intact.” Par 0044 and “The embedded-system device loads the static code and data stored in each of the one or more additional sections when integrity of all of the one or more additional sections is intact. The embedded-system device aborts the initialization process when integrity of any of the one or more additional sections is tampered.” Par 0056 and “The boot loader A 212, prior to loading the boot loader B 221, first checks the integrity of the static code and data stored in the section 220-0 and the section 220-2 to 220-5.” Par 0045 and “When the integrity is tampered, the embedded-system device, at operation 318, the embedded-system device aborts the initialization process.” Par 0053 and paragraph 40 and Figures 2-3) [the initial boot loader (boot loader A) verifies both its subsequent sections and flash-based boot loader (boot loader B) and aborts the process is any check fails].
It would have been obvious to a person having ordinary skill in the art, having the teachings of Thompson, Soenkens, Yamamoto and Venkataraman before him before the effective filing date of the claimed invention, to have modified Thompson, Soenkens and Yamamoto to incorporate the teachings of Venkataraman to maintain integrity across all boot loader modules to establish the device firmware as trusted and secure. (Venkataraman, paragraph 6)
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
Stern et al. (US 2015/0074745 A1) teaches a processor that establishes a root of trust for a first operating system and trusted execution environment and a second operation system and trusted execution environment. The processor stores measurements defining the root of trust for both operating systems and trusted execution environments and loads them on a trusted platform module. Each execution environment has exclusive access to their respective platforms.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AYMAN FATIMA whose telephone number is (571)270-0830. The examiner can normally be reached M to Fri between 8am and 4pm EST.
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, Jaweed Abbaszadeh can be reached on (571)270-1640. 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.
/AYMAN FATIMA/Examiner, Art Unit 2176
/JAWEED A ABBASZADEH/Supervisory Patent Examiner, Art Unit 2176
Prosecution Insights