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 .
Response to Amendment
The amendment filed on 03/27/2026 has been accepted and considered in this office action. Claims 1, 6-8, and 13-14 have been amended. Claims 5 and 12 have been canceled. No new claims have been newly added.
Response to Arguments
Applicant’s arguments, filed on 03/27/2026, with respect to the amended limitations of the independent claims have been fully considered and are not persuasive.
Applicant argues that the combination of Wruster, Gifre, and Eduardo fails to teach or suggest the limitation of amended claim 1: specifically, generating a safety feature from a first software image via a functional safety standard compliant module, and generating a second software image including the safety feature via the functional safety standard compliant module. Applicant asserts that Eduardo discloses that the control unit complies with the safety-critical requirement of ISO26262 or IEC61508, but is silent as to the software update monitor itself being a functional safety standard compliant module.
Applicant’s contention that the software update monitor is completely decoupled from the functional safety standard compliance is contradicted by Eduardo. Eduardo states that the integration of the software update monitor is what allows the system to meet and maintain its safety critical standard without redesign (Eduardo, page 7). Eduardo discloses (page 7, para 3-4) the software update monitor can be integrated into an existing system which is used for updating software of an automotive ECU, with the added advantage of providing a mechanism that helps the automotive ECU to continue being compliant with its safety critical standards. Using a software update monitor removes the need to invest in costly, challenging and troublesome modifications to systems targeting up to ASIL D ISO 26262 system requirements.
Under the Broadest Reasonable interpretation (BRI), a module integrated into an automotive Electronic Control Unit (ECU) system that enables the system to maintain compliance with ISO26262 upto ASIL D system requirement is, structurally and functionally, a “functional safety standard compliant module”. If the monitor were not compliant, its insertion into the control unit would instantly invalidate the ECU’s compliance with ISO26262 or IEC61508.
Applicant argues that Eduardo does not suggest that a compliant module calculates or verifies the integrity features. However, Eduardo (page 14, para 2) explicitly discloses that the software update monitor calculates verification code for integrity check for software images (page 10, para 2).
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Wurster/Gifre’s system by incorporating Eduardo’s teaching of implementing integrity verification check for software image complying with safety standards including ISO 26262. It would allow the module used to generate and integrate the checksum-based safety feature in Wurster to be implemented in a manner compliant with safety standard such as ISO 26262, when applied to software images as taught by Gifre. One would be motivated to perform such modification on Wurster/Gifre’s system in order to ensure integrity and authenticity of the software image during delivery and deployment by applying checksum-based safety features while maintaining compliance with established safety standards such as ISO 26262.
Therefore, the applicant’s argument is ultimately unpersuasive.
Specification
Applicant is reminded of the proper language and format for an abstract of the disclosure.
The abstract should be in narrative form and generally limited to a single paragraph on a separate sheet within the range of 50 to 150 words in length. The abstract should describe the disclosure sufficiently to assist readers in deciding whether there is a need for consulting the full patent text for details.
The language should be clear and concise and should not repeat information given in the title. It should avoid using phrases which can be implied, such as, “The disclosure concerns,” “The disclosure defined by this invention,” “The disclosure describes,” etc. In addition, the form and legal phraseology often used in patent claims, such as “means” and “said,” should be avoided.
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.
Claim(s) 1-4, 6-11 and 13-14 are rejected under 35 U.S.C. 103 as being unpatentable over Wurster (G. Wurster, P. C. van Oorschot and A. Somayaji, "A generic attack on checksumming-based software tamper resistance," 2005 IEEE Symposium on Security and Privacy (S&P'05), Oakland, CA, USA, 2005, pp. 127-138, doi: 10.1109/SP.2005.2) in view of Gifre (EP 4113340 B1) in view of Eduardo (WO 2018078406 A1).
Regarding Claim 1, Wurster teaches:
generating a safety feature from a first data via a module (Wurster, page 2, Section 2, para 4, discloses that the tester reads the code and data and builds up a checksum result based on the data read via an appropriate transformation engine (page 1, Section 1, para 2));
and generating a second data including the safety feature via the module (Wurster, page 3, Section 2, para 1, discloses the check summing code is inserted at compile time and integrated with regular execution code via an appropriate transformation engine (page 1, Section 1, para 2));
Wurster does not explicitly teach; However, Gifre teaches:
Wherein the data comprise software image (Gifre, Fig 2, para 14 discloses generating an installation package, comprising a header part and a payload part, for providing a software image to a secure element. The payload part contains a manifest, a manifest signature and a software image).
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Wurster’s system by incorporating Gifre’s teaching of providing executable data in the form of a software image package with associated metadata. It would allow the checksum-based integrity and safety feature generated from program code in Wurster to be applied to a software image suitable for distribution, installation, and execution. One would be motivated to perform such modification on Wurster’s system in order to ensure integrity and authenticity of the software image during delivery and deployment by applying checksum-based safety features.
Wurster/Gifre does not explicitly teach; However, Eduardo teaches:
Wherein the module comprises functional safety standard compliant module (Eduardo, page 14, para 2, discloses software update monitor generates verification code for integrity check for software image (page 10, para 2) where software update monitor used in control units complying with safety standards including ISO 26262 (page 6, para 5); Eduardo states that the integration of the software update monitor is what allows the system to meet and maintain its safety critical standard without redesign (Eduardo, page 7). Eduardo discloses (page 7, para 3-4) the software update monitor can be integrated into an existing system which is used for updating software of an automotive ECU, with the added advantage of providing a mechanism that helps the automotive ECU to continue being compliant with its safety critical standards. Using a software update monitor removes the need to invest in costly, challenging and troublesome modifications to systems targeting up to ASIL D ISO 26262 system requirements.).
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Wurster/Gifre’s system by incorporating Eduardo’s teaching of implementing integrity verification check for software image complying with safety standards including ISO 26262. It would allow the module used to generate and integrate the checksum-based safety feature in Wurster to be implemented in a manner compliant with safety standard such as ISO 26262, when applied to software images as taught by Gifre. One would be motivated to perform such modification on Wurster/Gifre’s system in order to ensure integrity and authenticity of the software image during delivery and deployment by applying checksum-based safety features while maintaining compliance with established safety standards such as ISO 26262.
Regarding Claim 2, Wurster/Gifre/Eduardo teaches the method of claim 1,
Wurster teaches:
wherein generating the second data including the safety feature comprises: embedding the safety feature in the first data. (Wurster, page 3, Section 2, para 1, discloses the check summing code is inserted at compile time and integrated with regular execution code);
Wurster does not explicitly teach; However, Gifre teaches:
Wherein the data comprise software image (Gifre, Fig 2, para 14 discloses generating an installation package, comprising a header part and a payload part, for providing a software image to a secure element. The payload part contains a manifest, a manifest signature and a software image).
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Wurster/Eduardo’s system by incorporating Gifre’s teaching of providing executable data in the form of a software image package with associated metadata. It would allow the checksum-based integrity and safety feature generated from program code in Wurster to be applied to a software image suitable for distribution, installation, and execution. One would be motivated to perform such modification on Wurster/Eduardo’s system in order to ensure integrity and authenticity of the software image during delivery and deployment by applying checksum-based safety features.
Regarding Claim 3, Wurster/Gifre/Eduardo teaches the method of claim 1,
Wurster teaches:
wherein: generating the safety feature from the first data comprises: (Wurster, page 2, Section 2, para 4, discloses that the tester reads the code and data and builds up a checksum result based on the data read);
retrieving information relating to segments of the first data (Wurster, page 2, Section 2, para 4, discloses reading from specific section of the code to compute checksum);
calculating an error detection code based on the information relating to the segments of the first data producing a checksum value (Wurster, page 2, Section 2, para 4, discloses reading from specific section of the code to compute checksum which is a type of error detection code);
and generating the second data including the safety feature comprises generating the second data including the checksum value (Wurster, page 3, Section 2, para 1, discloses the check summing code is inserted at compile time and integrated with regular execution code.);
Wurster does not explicitly teach; However, Gifre teaches:
Wherein the data comprise software image (Gifre, Fig 2, para 14 discloses generating an installation package, comprising a header part and a payload part, for providing a software image to a secure element. The payload part contains a manifest, a manifest signature and a software image).
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Wurster/Eduardo’s system by incorporating Gifre’s teaching of providing executable data in the form of a software image package with associated metadata. It would allow the checksum-based error detection code generated from specific code segments in Wurster to be applied to a software image. One would be motivated to perform such modification on Wurster/Eduardo’s system in order to enable segment-based checksum generation and verification from software images distributed and installed on target devices.
Regarding Claim 4, Wurster/Gifre/Eduardo teaches the method of claim 1, wherein generating the second software image including the safety feature:
Wurster does not explicitly teach; However, Gifre teaches:
generating a software image verifier (SWIV) header; generating a SWIV segment including the safety feature; and generating the second software image including the SWIV header and the SWIV segment (Gifre, Fig 2, para 14 discloses generating an installation package, comprising a header part and a payload part, for providing a software image to a secure element. The payload part contains a manifest, a manifest signature and a software image).
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Wurster’s system by incorporating Gifre’s teaching of generating a software image package comprising a header portion and a payload portion. It would allow the checksum-safety feature generated from code segments in Wurster to be organized into a verifier header and a verifier segment associated with the software image. One would be motivated to perform such modification on Wurster’s system in order to structure integrity and verification information separately from executable content within a software image, thereby enabling systematic verification of software image during installation and deployment on target devices.
Regarding Claim 6, Wurster/Gifre/Eduardo teaches the method of claim 1,
Wurster/Gifre does not explicitly teach; However, Eduardo teaches:
wherein the functional safety standard compliant module is an ISO 26262 functional safety standard compliant module (Eduardo, page 14, para 2, discloses software update monitor
generates verification code for integrity check for software image (page 10, para 2) where software update monitor used in control units complying with safety standards including ISO 26262 (page 6, para 5)).
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Wurster/Gifre’s system by incorporating Eduardo’s teaching of implementing integrity verification check for software image complying with safety standards including ISO 26262. It would allow the module used to generate and integrate the checksum-based safety feature in Wurster to be implemented in a manner compliant with safety standard such as ISO 26262, when applied to software images as taught by Gifre. One would be motivated to perform such modification on Wurster/Gifre’s system in order to ensure integrity and authenticity of the software image during delivery and deployment by applying checksum-based safety features while maintaining compliance with established safety standards such as ISO 26262.
Regarding Claim 7, Wurster/Gifre/Eduardo teaches the method of claim 1,
Wurster/Gifre does not explicitly teach; However, Eduardo teaches:
wherein the functional safety standard compliant module is an Automotive Safety Integrity Level (ASIL)-QM functional safety standard compliant module. (Eduardo, page 14, para 2, discloses software update monitor generates verification code for integrity check for software image (page 10, para 2) where software update monitor used in control units complying with safety standards including ISO 26262 (page 6, para 5) and Automotive safety integrity level ASIL-A up to ASIL-D (page 7, para 1). Under the Broadest reasonable interpretation (BRI), since ASIL-QM is expressly part of the ISO 26262 functional safety framework, the disclosure of higher level ASIL level inherently includes lower ASIL-QM level.).
Under the Broadest reasonable interpretation (BRI), since ASIL-QM is expressly part of the ISO 26262 functional safety framework, the disclosure of higher level ASIL level inherently includes lower ASIL-QM level.). It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Wurster/Gifre’s system by incorporating Eduardo’s teaching of implementing integrity verification check for software image complying with safety standards including ISO 26262 and Automotive safety integrity level ASIL-QM. It would allow the module used to generate and integrate the checksum-based safety feature in Wurster to be implemented in a manner compliant with safety standard such as ISO 26262 framework, when applied to software images as taught by Gifre. One would be motivated to perform such modification on Wurster/Gifre’s system in order to apply integrity verification using safety compliant module at an appropriate ASIL level, as selecting an ASIL level, including ASIL-QM.
Regarding Claim 8, Wurster teaches:
generate a safety feature from a first data via a module (Wurster, page 2, Section 2, para 4, discloses that the tester reads the code and data and builds up a checksum result based on the data read via an appropriate transformation engine (page 1, Section 1, para 2));
and generate a second data including the safety feature via the module (Wurster, page 3, Section 2, para 1, discloses the check summing code is inserted at compile time and integrated with regular execution code via an appropriate transformation engine (page 1, Section 1, para 2));
Wurster does not explicitly teach; However, Gifre teaches:
Wherein the data comprise software image (Gifre, Fig 2, para 14 discloses generating an installation package, comprising a header part and a payload part, for providing a software image to a secure element. The payload part contains a manifest, a manifest signature and a software image).
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Wurster’s system by incorporating Gifre’s teaching of providing executable data in the form of a software image package with associated metadata. It would allow the checksum-based integrity and safety feature generated from program code in Wurster to be applied to a software image suitable for distribution, installation, and execution. One would be motivated to perform such modification on Wurster’s system in order to ensure integrity and authenticity of the software image during delivery and deployment by applying checksum-based safety features.
Wurster/Gifre does not explicitly teach; However, Eduardo teaches:
Wherein the module comprises functional safety standard compliant module (Eduardo, page 14, para 2, discloses software update monitor generates verification code for integrity check for software image (page 10, para 2) where software update monitor used in control units complying with safety standards including ISO 26262 (page 6, para 5); Eduardo states that the integration of the software update monitor is what allows the system to meet and maintain its safety critical standard without redesign (Eduardo, page 7). Eduardo discloses (page 7, para 3-4) the software update monitor can be integrated into an existing system which is used for updating software of an automotive ECU, with the added advantage of providing a mechanism that helps the automotive ECU to continue being compliant with its safety critical standards. Using a software update monitor removes the need to invest in costly, challenging and troublesome modifications to systems targeting up to ASIL D ISO 26262 system requirements.).
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Wurster/Gifre’s system by incorporating Eduardo’s teaching of implementing integrity verification check for software image complying with safety standards including ISO 26262. It would allow the module used to generate and integrate the checksum-based safety feature in Wurster to be implemented in a manner compliant with safety standard such as ISO 26262, when applied to software images as taught by Gifre. One would be motivated to perform such modification on Wurster/Gifre’s system in order to ensure integrity and authenticity of the software image during delivery and deployment by applying checksum-based safety features while maintaining compliance with established safety standards such as ISO 26262.
Regarding Claim 9, Wurster/Gifre/Eduardo teaches the computing device of claim 8,
Wurster teaches:
wherein the processing device is further configured with processing device-executable instructions to embed the safety feature in the first data (Wurster, page 3, Section 2, para 1, discloses the check summing code is inserted at compile time and integrated with regular execution code);
Wurster does not explicitly teach; However, Gifre teaches:
Wherein the data comprise software image (Gifre, Fig 2, para 14 discloses generating an installation package, comprising a header part and a payload part, for providing a software image to a secure element. The payload part contains a manifest, a manifest signature and a software image).
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Wurster/Eduardo’s system by incorporating Gifre’s teaching of providing executable data in the form of a software image package with associated metadata. It would allow the checksum-based integrity and safety feature generated from program code in Wurster to be applied to a software image suitable for distribution, installation, and execution. One would be motivated to perform such modification on Wurster/Eduardo’s system in order to ensure integrity and authenticity of the software image during delivery and deployment by applying checksum-based safety features.
Regarding Claim 10, Wurster/Gifre/Eduardo teaches the computing device of claim 8,
Wurster teaches:
wherein the processing device is further configured with processing device-executable instructions to generate the safety feature from the first data by (Wurster, page 2, Section 2, para 4, discloses that the tester reads the code and data and builds up a checksum result based on the data read);
retrieving information relating to segments of the first data (Wurster, page 2, Section 2, para 4, discloses reading from specific section of the code to compute checksum);
calculating an error detection code based on the information relating to the segments of the first data producing a checksum value (Wurster, page 2, Section 2, para 4, discloses reading from specific section of the code to compute checksum which is a type of error detection code);
and generating the second data including the safety feature comprises generating the second data including the checksum value (Wurster, page 3, Section 2, para 1, discloses the check summing code is inserted at compile time and integrated with regular execution code.);
Wurster does not explicitly teach; However, Gifre teaches:
Wherein the data comprise software image (Gifre, Fig 2, para 14 discloses generating an installation package, comprising a header part and a payload part, for providing a software image to a secure element. The payload part contains a manifest, a manifest signature and a software image).
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Wurster/Eduardo’s system by incorporating Gifre’s teaching of providing executable data in the form of a software image package with associated metadata. It would allow the checksum-based error detection code generated from specific code segments in Wurster to be applied to a software image. One would be motivated to perform such modification on Wurster/Eduardo’s system in order to enable segment-based checksum generation and verification from software images distributed and installed on target devices.
Regarding Claim 11, Wurster/Gifre/Eduardo teaches the computing device of claim 8, wherein the processing device is further configured with processing device-executable instructions to generate the second software image including the safety feature:
Wurster does not explicitly teach; However, Gifre teaches:
generating a software image verifier (SWIV) header; generating a SWIV segment including the safety feature; and generating the second software image including the SWIV header and the SWIV segment (Gifre, Fig 2, para 14 discloses generating an installation package, comprising a header part and a payload part, for providing a software image to a secure element. The payload part contains a manifest, a manifest signature and a software image).
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Wurster/Eduardo’s system by incorporating Gifre’s teaching of generating a software image package comprising a header portion and a payload portion. It would allow the checksum-safety feature generated from code segments in Wurster to be organized into a verifier header and a verifier segment associated with the software image. One would be motivated to perform such modification on Wurster/Eduardo’s system in order to structure integrity and verification information separately from executable content within a software image, thereby enabling systematic verification of software image during installation and deployment on target devices.
Regarding Claim 13, Wurster/Gifre/Eduardo teaches the computing device of claim 8,
Wurster/Gifre does not explicitly teach; However, Eduardo teaches:
wherein the functional safety standard compliant module is an ISO 26262 functional safety standard compliant module (Eduardo, page 14, para 2, discloses software update monitor
generates verification code for integrity check for software image (page 10, para 2) where software update monitor used in control units complying with safety standards including ISO 26262 (page 6, para 5)).
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Wurster/Gifre’s system by incorporating Eduardo’s teaching of implementing integrity verification check for software image complying with safety standards including ISO 26262. It would allow the module used to generate and integrate the checksum-based safety feature in Wurster to be implemented in a manner compliant with safety standard such as ISO 26262, when applied to software images as taught by Gifre. One would be motivated to perform such modification on Wurster/Gifre’s system in order to ensure integrity and authenticity of the software image during delivery and deployment by applying checksum-based safety features while maintaining compliance with established safety standards such as ISO 26262.
Regarding Claim 14, Wurster/Gifre/Eduardo teaches the computing device of claim 8,
Wurster/Gifre does not explicitly teach; However, Eduardo teaches:
wherein the functional safety standard compliant module is an Automotive Safety Integrity Level (ASIL)-QM functional safety standard compliant module. (Eduardo, page 14, para 2, discloses software update monitor generates verification code for integrity check for software image (page 10, para 2) where software update monitor used in control units complying with safety standards including ISO 26262 (page 6, para 5) and Automotive safety integrity level ASIL-A up to ASIL-D (page 7, para 1). Under the Broadest reasonable interpretation (BRI), since ASIL-QM is expressly part of the ISO 26262 functional safety framework, the disclosure of higher level ASIL level inherently includes lower ASIL-QM level.).
Under the Broadest reasonable interpretation (BRI), since ASIL-QM is expressly part of the ISO 26262 functional safety framework, the disclosure of higher level ASIL level inherently includes lower ASIL-QM level.). It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Wurster/Gifre’s system by incorporating Eduardo’s teaching of implementing integrity verification check for software image complying with safety standards including ISO 26262 and Automotive safety integrity level ASIL-QM. It would allow the module used to generate and integrate the checksum-based safety feature in Wurster to be implemented in a manner compliant with safety standard such as ISO 26262 framework, when applied to software images as taught by Gifre. One would be motivated to perform such modification on Wurster/Gifre’s system in order to apply integrity verification using safety compliant module at an appropriate ASIL level, as selecting an ASIL level, including ASIL-QM.
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 AMIT KHADKA whose telephone number is (703)756-1440. The examiner can normally be reached Monday - Friday, 8:00 am - 5:00 pm.
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, Jeffrey L. Nickerson can be reached at (469) 295-9235. 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.
/AMIT KHADKA/Examiner, Art Unit 2432
/Jeffrey Nickerson/Supervisory Patent Examiner, Art Unit 2432
Prosecution Insights