DETAILED ACTION
Response to Amendment
Applicant’s amendment, filed 06/17/26, for application number 18/350,387 has been received and entered into record. Claims 1-3 have been amended, Claims 4 and 10 were previously cancelled, and Claim 5 is newly cancelled. Therefore, Claims 1-3 and 6-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, Molinos et al., US 2021/0374292 A1, and Jiang et al., US 2022/0092199 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 at least one flag in an array is set, the at least one flag having been set while the host operated in an application mode associated with a previous boot cycle, wherein each index of the array is associated with a corresponding software component from among a plurality of software components of the ECU, and wherein each flag stored at a respective index of the array indicates whether a manipulation of the corresponding software component has been detected; verifying at least one software component of the plurality of software components in response to the at least one 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 at least one 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 at least one flag in an array is set, the at least one flag having been set while the host operated in an application mode associated with a previous boot cycle, wherein each index of the array is associated with a corresponding software component from among a plurality of software components of the ECU, and wherein each flag stored at a respective index of the array indicates whether a manipulation of the corresponding software component has been detected; 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 at least one 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].
However, the combination of references does not explicitly teach wherein at least one flag in array is set, wherein each index of the array is associated with a corresponding software component from among a plurality of software components of the ECU, and wherein each flag stored at a respective index of the array indicates whether a manipulation of the corresponding software component has been detected; and a plurality of software components.
Jiang teaches wherein at least one flag in array is set, wherein each index of the array is associated with a corresponding software component from among a plurality of software components of the ECU, and wherein each flag stored at a respective index of the array indicates whether a manipulation of the corresponding software component has been detected; and a plurality of software components [when rewrite of first software being one of the pieces of software is detected, extract first file information being the file information corresponding to the first software, and change a first flag corresponding to the first file information in the flag table to a first value indicating that verification of integrity of the first software for which rewrite is detected is required; a flag table containing flag values; that is, each flag in the flag table (array) acts as an index for the respective software (plurality of software components), abstract; claim 1; par 18].
It would have been obvious to one of ordinary skill in the art, having the teachings of Grimes, Tiwari, Molinos, and Jiang before him before the effective filing date of the claimed invention, to incorporate the array containing flags of the corresponding software components as taught by Jiang, into the method as disclosed by Grimes, Tiwari, and Molinos, as ensuring the integrity of software allows for whitelisting execution control and permitting execution when software has an intended status [Jiang, par 5].
Regarding Claim 6, Grimes, Tiwari, Molinos, and Jiang disclose the method according to Claim 1. However, while Grimes discloses an 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] and Molinos teaches wherein the host requests verification results [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], 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, Molinos, and Jiang 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, Molinos, and Jiang 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, Molinos and Jiang 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, Molinos, and Jiang, and further in view of Smirnov et al., US 2017/0364418 A1.
Regarding Claim 2, Grimes, Tiwari, Molinos, and Jiang disclose the method according to Claim 1. However, the combination of references does not explicitly teach wherein the first 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, Jiang, 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, Molinos, and Jiang 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 Grimes, Tiwari, Molinos, and Jiang, and further in view of Yamazaki et al., US 20220171855 A1 (as listed in the IDS).
Regarding Claim 3, Grimes, Tiwari, Molinos, and Jiang disclose the method according to Claim 1. Grimes further discloses wherein the host queries the HSM to recompute integrity checks of the at least one 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, Jiang, 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, Molinos, and Jiang, as an ECU having a main controller and separate secure controller allows for secure booting during a fast boot-up [Yamazaki, par 6].
Response to Arguments
Applicant’s arguments filed 06/17/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's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 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
Prosecution Insights