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 Election
Applicant’s election without traverse of Group I, claims 1-7 and 8-14 directed to a method and a device to generate a software image including safety features (e.g., checksum/SWIV; ISO 26262/ASIL-QM) in the reply filed on 12/05/2025 is acknowledged.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 12/21/2023 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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 and 8-11 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).
Regarding Claim 1, Wurster teaches:
generating a safety feature from a first data (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);
and generating a second data including the safety feature (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’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.
Regarding Claim 2, Wurster/Gifre 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’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.
Regarding Claim 3, Wurster/Gifre 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’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’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 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 8, Wurster teaches:
generating a safety feature from a first data (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);
and generating a second data including the safety feature (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’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.
Regarding Claim 9, Wurster/Gifre 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’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.
Regarding Claim 10, Wurster/Gifre 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’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’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 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’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.
Claim(s) 5-7 and 12-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 5, Wurster/Gifre teaches the method of claim 1,
wherein: generating the safety feature from the first data comprises generating the safety feature 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 the second data including the safety feature comprises generating the 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)).
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 6, Wurster/Gifre/Eduardo teaches the method of claim 5,
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 5,
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 12, Wurster/Gifre teaches the computing device of claim 8,
generate the safety feature from the 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 the second data including the safety feature comprises generating the 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)).
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 13, Wurster/Gifre/Eduardo teaches the computing device of claim 12,
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 12,
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
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
/SYED A ZAIDI/Primary Examiner, Art Unit 2432
Prosecution Insights