DETAILED ACTION
Response to Amendment
Applicant’s amendment, filed 01/05/26, for application number 18/350,387 has been received and entered into record. Claims 1, 6, and 8 have been amended, and Claims 4 and 10 were previously cancelled. Therefore, Claims 1-3 and 5-9 are presented for examination.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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 and 6-9 are rejected under 35 U.S.C. 103 as being unpatentable over Grimes et al., US 2016/0350536 A1, in view of Tiwari et al., US 2021/0056207 A1, and further in view of Molinos et al., US 2021/0374292 A1.
Regarding Claim 1, Grimes discloses a method for booting an electronic control unit (ECU), the ECU including a host interacting with a Hardware Security Module (HSM) [boot control method of Fig. 4, to perform the method on engine control module (ECM) 106, which includes HSM 232, Fig. 2; par 36, 47], the method comprising:
checking, by the host operating in a boot mode, whether a flag was set [system is in boot mode at start of Fig. 4, as Fig. 4 depicts a method for executing boot code; at step 408, the HSM determines whether the allow boot indicator 220 is in the first state (the allow boot indicator being a flag), par 60];
verifying, by the HSM, during the current boot cycle, at least one software component in response to the flag being set [at step 424, HSM determines whether the hash value is equal to the predetermined value];
transitioning, by the host, from the boot mode of the current boot cycle to an application mode associated with the current boot cycle [if the change requested indicator is in the second state (i.e. application mode), and indicates the reliability of the boot code 208 has been verified, so the boot code can be executed; (change requested indicator being in second state is application mode, since can execute future boot requests in that mode), par 62]; and
deciding by the host whether an intervention is necessary [If 424 is false, the hash value is different than the predetermined value, so the HSM 232 sets the allow boot indicator 220 to the second state at 432. Execution of the boot code 208 is disabled when the allow boot indicator 220 is in the second state. At 436, the HSM 232 may set the boot fault indicator 244 to the first state. The monitoring module 248 may take one or more remedial actions when the boot fault indicator 244 is in the first state, such as illuminating the MIL 252; that is, if the hash value is different, then manipulation has taken place, and the monitoring module (i.e. host) may take remedial action, par 63].
However, Grimes does not explicitly teach checking whether a flag was set while the host operated in an application mode associated with a previous boot cycle; verifying at least one software component in response to the flag being set during the application mode associated with the previous boot cycle; determining, by the host operating in the boot mode of the current boot cycle in response to the verifying indicating a first manipulation of the at least one software component, a mitigation strategy for the first manipulation of the at least one software component; and based on a second manipulation being detected by the host operating in the application mode associated with the current boot cycle, sending, by the host, a request to confirm whether the second manipulation has occurred, wherein, when the second manipulation is confirmed to have occurred, the host sets the flag used by the host operating in the boot mode in a subsequent boot cycle.
In the analogous art of secure booting, Tiwari teaches checking whether a flag was set in a previous boot cycle; verifying at least one software component in response to the flag being set during the previous boot cycle; and determining, by the host operating in the boot mode of the current boot cycle in response to the verifying indicating a first manipulation of the at least one software component, a mitigation strategy for the first manipulation of the at least one software component [select systems and/or subsystems (e.g., modem processor subsystem, etc.) in the mobile device may monitor the tampered flag/bit in the secure area of the mobile device, and automatically perform responsive actuation operations (e.g., operations to revert the device to a previous version of software/firmware, restore a subsidy lock on the device, disable the mobile device, etc.) in response to determining that the tampered flag/bit has been set; the process occurs during the boot sequence; that is, checking for a flag that was set previously and in response to verifying the flag/manipulation, performing actuation operations, par 3, 25].
It would have been obvious to one of ordinary skill in the art, having the teachings of Grimes and Tiwari before him before the effective filing date of the claimed invention, to incorporate the verification of the flag and implementing a mitigation strategy, as taught by Tiwari, into the method as disclosed by Grimes, to detect and correct unauthorized control or access over mobile devices [Tiwari, par 1].
However, the combination of Grimes and Tiwari does not explicitly teach checking whether a flag was set while the host operated in an application mode associated with a previous boot cycle; and based on a second manipulation being detected by the host operating in the application mode associated with the current boot cycle, sending, by the host, a request to confirm whether the second manipulation has occurred, wherein, when the second manipulation is confirmed to have occurred, the host sets the flag used by the host operating in the boot mode in a subsequent boot cycle.
In the analogous art of unwanted manipulation detection, Molinos teaches checking whether a flag was set while the host operated in an application mode associated with a previous boot cycle; and based on a second manipulation being detected by the host operating in the application mode associated with the current boot cycle, sending, by the host, a request to confirm whether the second manipulation has occurred, wherein, when the second manipulation is confirmed to have occurred, the host sets the flag used by the host operating in the boot mode in a subsequent boot cycle [there also exists the method to activate the software following the start of the device initially without a check and to perform a check of the software only afterwards, in parallel with the run time. If a manipulation of the software is detected, a new activation of the software may be prevented in the next start of the device, based on this information; i.e. manipulation is detected in the application mode and a flag is set, and in order to prevent activation of the software in the next start of the device, there is necessarily some type of checking to determine the information indicating manipulation in the current application mode, par 4].
It would have been obvious to one of ordinary skill in the art, having the teachings of Grimes, Tiwari, and Molinos before him before the effective filing date of the claimed invention, to incorporate the detection and indication of manipulation during a previous application mode, as taught by Molinos, into the method as disclosed by Grimes and Tiwari, to provide for a means of signaling deactivation of a component at a subsequent start [Molinos, par 6].
Regarding Claim 6, Grimes, Tiwari, and Molinos disclose the method according to Claim 1. However, while Yamazaki teaches wherein the host requests verification results from the HSM [main controller requests secure controller (i.e. HSM) make code verification, par 46, ll. 1-3], the combination of references does not explicitly teach the request being a Run Time Manipulation Detection (RTMD) verification result.
Examiner notes, however, devices which operate “on basically the same principle and in the same manner” where the differences, in addition to being well-known, “solve no stated problem and would be an obvious matter of design choice within the skill of the art” are obvious variations of one another and thus not patentably distinct. See In re Kuhle, 188 USPQ 7 (CCPA 1975). As such, the verification request being a Run Time Manipulation Detection (RTMD) verification appears to simply be a design choice, and would perform the same verification function regardless.
Regarding Claim 7, Grimes, Tiwari, and Molinos disclose the method according to Claim 1. Grimes further discloses wherein the intervention causes a failure strategy to be performed [at 436, the HSM 232 may set the boot fault indicator 244 to the first state. The monitoring module 248 may take one or more remedial actions when the boot fault indicator 244 is in the first state, such as illuminating the MIL 252; the remedial action being the failure strategy, par 63].
Regarding Claim 8, Grimes, Tiwari, and Molinos disclose the method according to Claim 7. While Grimes discloses a failure strategy, the combination of references does not explicitly teach wherein the failure strategy is a strategy selected from a group consisting of: raising a Diagnostic Trouble Code (DTC), sending an error message on a CAN bus, locking security critical information including cryptographic keys, notifying a producer by sending a log data to a Telematic Control Unit (TCU) which is connected to a producer backend, informing a driver by an infotainment system, and having a truck run for only a certain limited period of time.
Examiner notes, however, devices which operate “on basically the same principle and in the same manner” where the differences, in addition to being well-known, “solve no stated problem and would be an obvious matter of design choice within the skill of the art” are obvious variations of one another and thus not patentably distinct. See In re Kuhle, 188 USPQ 7 (CCPA 1975). As such, the particular types of failure strategies of Claim 8 appear to simply be design choices, and would serve to perform a failure strategy regardless.
Regarding Claim 9, Grimes, Tiwari, and Molinos disclose the method according to Claim 1. Grimes further discloses verifying the integrity and authenticity of the at least one software component [at 420, the HSM 232 executes the hash function on the boot code 208 to determine the hash value for the boot code 208. At 424, the HSM 232 determines whether the hash value is equal to the predetermined value, par 62, ll. 1-4]. However, the combination of references does not explicitly teach the HSM using a cryptographic algorithm in its verification.
Examiner notes, however, devices which operate “on basically the same principle and in the same manner” where the differences, in addition to being well-known, “solve no stated problem and would be an obvious matter of design choice within the skill of the art” are obvious variations of one another and thus not patentably distinct. See In re Kuhle, 188 USPQ 7 (CCPA 1975). As such, verification through use of a cryptographic algorithm appears to simply be design choices, and would perform the verification function regardless.
Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Grimes, Tiwari, and Molinos, and further in view of Smirnov et al., US 2017/0364418 A1.
Regarding Claim 2, Grimes, Tiwari, and Molinos disclose the method according to Claim 1. However, the combination of references does not explicitly teach wherein the manipulation is detected by checking a bit change in memory address range of the at least one software component or by checking a checksum on an address of the at least one software component.
In the analogous art of data integrity, Smirnov teaches wherein the manipulation is detected by checking a bit change in memory address range of the at least one software component or by checking a checksum on an address of the at least one software component [to exclude the possibility of corrupt data, the data from the beginning of the transactional memory to the address indicated by the checksum data pointer needs to be verified against the checksum value. If the two checksums match, then the transactional memory region has retained its integrity. Therefore, it may be assumed that there has been no tampering, par 49, ll. 6-12].
It would have been obvious to one of ordinary skill in the art, having the teachings of Grimes, Tiwari, Molinos, and Smirnov before him before the effective filing date of the claimed invention, to incorporate the memory checking as taught by Smirnov, into the method as disclosed by Grimes, Tiwari, and Molinos to provide memory region verification as a method to confirm and protect data [Smirnov, par 2].
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Tiwari, and Molinos, and further in view of Yamazaki et al., US 20220171855 A1 (as listed in the IDS).
Regarding Claim 3, Tiwari, and Molinos disclose the method according to Claim 1. Grimes further discloses wherein the host queries the HSM to recompute integrity checks of the software component [at 404, the HSM 232 determines whether the change requested indicator 240 is in the first state. If 404 is true, control transfers to 420 as the boot code 208 may have been changed; at 420, the HSM 232 executes the hash function on the boot code 208 to determine the hash value for the boot code 208. At 424, the HSM 232 determines whether the hash value is equal to the predetermined value; that is, determining the boot code may have changed, and thus checking the integrity of the hash value against the predetermined value, par 59, ll. 4-7; par 62, ll. 1-4].
In the analogous art of security verification, Yamazaki further teaches the host querying the HSM [main controller requests secure controller (i.e. HSM) make code verification, par 46, ll. 1-3].
It would have been obvious to one of ordinary skill in the art, having the teachings of Grimes, Tiwari, Molinos, and Yamazaki before him before the effective filing date of the claimed invention, to incorporate the verification request from the host, as taught by Yamazaki, into the method as disclosed by Grimes, Tiwari, and Molinos, as an ECU having a main controller and separate secure controller allows for secure booting during a fast boot-up [Yamazaki, par 6].
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Grimes, Tiwari, and Molinos, and further in view of Durham, US 2021/0117342 A1.
Regarding Claim 5, Grimes, Tiwari, and Molinos disclose the method according to Claim 1. However, the combination of references does not explicitly teach wherein the flag is an array value.
In the analogous art of data security, Durham teaches wherein the flag is an array value [the plaintext integrity bits 508 are all set to zero and thus when the ciphertext 504 is decrypted if one or more of the integrity bits 508 are set to one, then a determination that the ciphertext 504 has been manipulated is detected (the integrity bits being an array), par 91, ll. 20-24].
It would have been obvious to one of ordinary skill in the art, having the teachings of Grimes, Tiwari, Molinos, and Durham before him before the effective filing date of the claimed invention, to incorporate indicating manipulation as an array value as taught by Durham, into the method as disclosed by Grimes, Tiwari, and Molinos, to provide memory safety [Durham, par 2].
Response to Arguments
Applicant’s arguments filed 01/05/26 have been considered but are moot due to the new rejection based on the references cited above, as well as the newly cited portions of the references previously presented.
Conclusion
Applicant is reminded that in amending a response to a rejection of claims, the patentable novelty must be clearly shown in view of the state of the art disclosed by the references cited and the objections made. Applicant must also show how the amendments avoid such references and objections. See 37 CFR §1.111(c).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PAUL J YEN whose telephone number is (571)270-5047. The examiner can normally be reached M-F 8-5 PT.
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 J Jung can be reached at (571) 270-3779. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Paul Yen/Primary Examiner, Art Unit 2175