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 .
This application has been examined. Claims 1-10 are pending.
The Group and/or Art Unit location of your application in the PTO has changed. To aid in correlating any papers for this application, all further correspondence regarding this application should be directed to Group Art Unit 2175.
Specification
The title of the invention is not descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed.
Claim Rejections - 35 USC § 112
The following is a quotation of the second paragraph of 35 U.S.C. 112:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 5, 6, 9, and 10 are rejected under 35 U.S.C. § 112(b) as failing to particularly point out and distinctly claim the subject matter which the inventor regards as the invention.
The term "priority level" in claims 5 and 6, and the terms "second priority level" and "third priority level" in claim 9, are not defined in the specification, and the specification provides no standard by which a skilled artisan could determine the priority level of a given signature or signature verification method.
The specification describes two distinct and independent ordering concepts. It describes the "generation" of a signature method, explaining that lattice cryptography is of a newer generation than RSA or elliptic curve cryptography, and that a method of an older generation is more likely to be compromised (¶0049]-[0050]). Separately, it describes the "version" of a stored program, and the comparison of the version in one bank against the version in the other (¶0060]-[0061]). Nowhere does the specification use the term "priority level," nor does it state whether "priority level" is synonymous with generation, synonymous with version, a composite of the two, or something else.
This matters to claim scope rather than merely to nomenclature. Claim 5 requires deletion of the program whose signature has the lower priority level. Where a program carries a newer software version but an older cryptographic generation, the two candidate readings of "priority level" dictate opposite outcomes that under one reading the program is retained, under the other it is deleted. A skilled artisan cannot ascertain the scope of the claim with reasonable certainty. Nautilus, Inc. v. Biosig Instruments, Inc., 572 U.S. 898, 901 (2014).
Claim 6 recites the same term and is rejected on the same basis. Claims 9 and 10 depend from claim 5 and are rejected as incorporating the same indefinite limitation; claim 9 additionally recites priority levels in its own right.
Applicant may overcome this rejection by amending the claims to recite "generation" or "version" consistent with ¶0049]-[0050] and ¶0060]-[0061] respectively, or by pointing to a definition in the specification as filed. Applicant is reminded that no new matter may be introduced. 35 U.S.C. § 132(a).
Claims 5 and 6 are rejected under § 112(b) only. Because the metes and bounds of "priority level" cannot be determined, no prior-art rejection of claims 5 and 6 is made at this time; a determination under §§ 102 and 103 is deferred pending clarification of the term. See MPEP § 2143.03.
Claim Rejections - 35 USC § 103
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 t which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-4, 7-8, 9-10 are rejected under AIA 35 U.S.C. § 103 as being unpatentable over Venkataraman et al. (“Venkataraman”) (US No. 10,902,127) in view of Batke et al. (“Batke”) (US Pub No. 2012/0005480).
In order to expedite and avoid piecemeal prosecution, the following rejection is made to the extent that the claims are understood, by considering those elements which are understood and interpreting their function in a manner which is consistent with the recited goals of the claims, and then applying the best available art.
The examiner relies on the entire teachings of Venkataraman and Batke references; the applicant should carefully consider the entire teachings of the above-mentioned references to better understand the examiner’s position.
In regard to claim 1, Venkataraman teaches an information processing apparatus comprising: a computation unit that performs a computation process for a program (as shown in Fig. 1, which is reproduced below for ease of reference and convenience, Venkataraman discloses the embedded-system device comprising processor 102 and storage device 200. Col. 3:20-63, FIG. 1. Processing unit 112 loads and executes boot loader A 212 and subsequent code; col. 5:46-6:63),
PNG
media_image1.png
1056
768
media_image1.png
Greyscale
and a storage unit that stores a first control program (in Venkataraman, Storage device 117; multiple-time programmable region 204 stores sections 220 containing code and data for respective functionalities (root file system, kernel, web service); col. 5:46-6:63, FIG. 2.)
and a first startup program that executes signature verification for the first control program (in Venkataraman, Boot loader A 212 in one-time programmable region 202 calculates hash codes via signing code 216, decrypts encrypted signatures 224 with public key 214, and compares; col. 6:55-7:54);
obtaining a result of executing signature verification by the signature verification method (in Venkataraman, Boot loader A 212 determines integrity intact on match and proceeds; determines tampering on mismatch and aborts col. 6:55-7:54; col. 8:21-36; FIG. 3, 312–318).
But Venkataraman does not expressly teach wherein the first startup program can execute a plurality of signature verification methods, and executes a process for determining, among the plurality of signature verification methods, a signature verification method that corresponds to a signature type for the first control program. In the same field of endeavor, Batke expressly teaches the first startup program can execute a plurality of signature verification methods (as shown in Fig. 3, which is reproduced below for ease of reference and convenience, Batke supplies a certificate-borne signature algorithm identifier 320 whose value names the signing algorithm (e.g., (SHA1WithRSAEncryption"), ¶0034], [0038]; and teaches modules handling both signature-aware and signature-unaware code, ¶0004], [0020], and distinct keys for development versus release builds, ¶[0021]. A boot loader so configured supports more than one verification method);
PNG
media_image2.png
830
530
media_image2.png
Greyscale
and executes a process for determining, among the plurality of signature verification methods, a signature verification method that corresponds to a signature type for the first control program (in Batke, certificate accompanies the firmware binary as a separate associated instance (¶ [0017]) and carries the signature algorithm identifier 320 (¶ [0034]). The module reads the certificate and processes the signature accordingly (¶ [0032]-[0033]; FIG. 4, 410–490). Reading the identifier to determine which verification routine to apply meets the recited determining step. 5); and obtaining a result of executing signature verification by the signature verification method (in Batke, FIG. 4: firmware declared valid at 494 on match, update aborted at 430 on mismatch; ¶ [0040]). It would have been obvious to one of ordinary skill in the art at the time of the claimed invention to modify the embedded secure-boot apparatus of Venkataraman with the signature-awareness and multi-method firmware verification teachings of Batke. Both references address the identical technical problem: verifying the integrity and authenticity of firmware/control code in an embedded processor-based device before allowing execution, in an environment where devices may differ in their cryptographic capabilities. Both references are directed to the same field (embedded-system secure boot/firmware integrity) and share the same goal (preventing execution of unauthorized or compromised firmware). A skilled artisan reading Venkataraman would immediately recognize that different firmware components may be signed under different schemes (e.g., development vs. production keys, legacy vs. updated algorithms), and would look to Batke’s explicit teaching of a boot-code layer that handles both signed and unsigned application code and selects the appropriate verification path based on the signature type present as a natural extension of Venkataraman’s architecture. The combination also involves the routine integration of a known technique (signature-type-aware boot-code selection of verification path, Batke) into a known device (embedded secure-boot apparatus with OTP boot loader, Venkataraman) to yield predictable results (a boot loader that can handle programs signed under any of a plurality of supported algorithms). KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 416 (2007).
` In regard to claim 2, Batke teaches wherein the storage unit has a first storage region for storing the first control program and the first startup program (in Batke, teaches multiple firmware binary instances 120, each with its own associated certificate 130, where "one certificate for boot code, one certificate for runtime code, one certificate for file system" (¶[0020]), and each binary/certificate pair is independently verifiable (¶[0046]). Organizing Venkataraman's two boot loaders and their associated code into two separately verifiable regions is an obvious arrangement). and a second storage region for storing a second control program that has a signature type different to that of the first control program (in Batke, explicitly teaches that firmware may be signature-aware or signature-unaware (¶0004], [0020]) and that "one key can be employed for development builds and another for when the firmware is publicly released" (¶[0021]); the signature algorithm identifier 320 is a per-certificate field (¶[0034]), so two concurrently stored binaries may carry different algorithm values.) and a second startup program that can execute a plurality of signature verification methods and executes signature verification by a signature verification method that is among the plurality of signature verification methods and corresponds to the signature type of the second control program (in Batke, A second startup program built on the same certificate-reading architecture Batke describes (¶0032]-[0034]) inherits the same multi-method capability, for the same compatibility reasons Batke gives at ¶[0004]).
In regard to claim 3, Venkataraman teaches wherein the signature verification is executed by the first startup program (in Venktaraman, Boot loader A 212 itself calculates the hash codes using signing code 216, itself decrypts the encrypted signatures using public key 214, and itself performs the comparison, without recourse to any separate hardware security module (col. 6:55-7:54)).
In regard to claim 4, Batke teaches wherein, after the second control program is stored in the second storage region, a storage region to be executed from is switched from the first storage region to the second storage region (in Batke, teaches a update procedure writes a verified firmware image to flash and thereafter runs it (¶0060]-[0062]; FIG. 8, 810-850), and supports both upgrade and downgrade paths between firmware versions (¶0006], [0020]), and the first storage region stores a third control program that is a same control program as the second control program and has a signature of a type different to that of the signature of the second control program (in Batke, teaches "creating a certificate for unmodified firmware" (¶ [0023]) and building "additional certificates for additional firmware instances" (FIG. 7, 720; ¶ [0047]), i.e., associating the same binary content with a further certificate bearing a different signature algorithm identifier. Storing that re-signed copy in the vacated first region follows for redundancy and rollback).
In regard to claim 7, Batke teaches wherein, in a case where the second control program is received, first software version information of the first control program is compared with second software version information of the second control program, and the second control program is stored in the second storage region only when the first software version information is older than the second software version information (in Batke, certificate carries firmware and hardware revision information as mandatory custom extensions, i.e. the plain-text structure at ¶[0038] enumerates "Firmware Major Rev," "Firmware Minor Rev," and "Hardware Rev String," and ¶ [0006] states that certificates "include a list of hardware revisions for which the firmware is valid." Batke performs preliminary checks on the certificate before accepting the firmware binary, aborting the update if the certificate is not appropriate for the module (¶[0040]; FIG. 4, 420-430). Extending that gating from hardware revision to firmware revision that both of which Batke already carries in the certificate so that an incoming image is accepted only when its version is newer, is a routine application of Batke's own version-checking mechanism to a field Batke already provides.
In regard to claim 8, Venkataraman teaches wherein the first startup program and the second startup program cannot be rewritten, the first control program can be rewritten only when the second startup program or the second control program is executed, and the second control program can be rewritten only when the first startup program or the first control program is executed (in Venkataraman, boot loader A 212 resides in the one-time programmable region 202, which "can be only programmed once," so that once written the boot loader A 212, the public key 214, and the signing code 216 "cannot be changed" (col. 6:55-7:54). Venkataraman does not, however, teach the reciprocal cross-region rewrite constraints of the second and third limitations. In the same field of endeavor,
Batke teaches conditioning firmware modification on an external gating requirement - feedback mechanisms ensuring that a user has physical access to the module before signature-unaware firmware may be updated (¶ [0018], [0023]) and a proxy module that intercepts update requests directed at a target module, verifies the certificate, and passes the firmware to the target only if valid (¶ [0023]). Batke thus establishes that write authority over a module's firmware is properly vested in an agent other than the code being overwritten. Applying that principle to the two-region arrangement of the combination so that each region's control program is writable only while the other region's code is executing which is the obvious means of preventing a running program from overwriting its own execution context.
In regard to claim 9, this claim is rejected for the reasons given for claims 4 and 5, and is additionally subject to the § 112(b) rejection below. Neither Venkataraman nor Batke teaches ranking two signature verification methods against one another and conditioning storage on the outcome of that ranking. Batke does teach comparing certificate-borne attributes against module attributes and rejecting the update when the certificate is not appropriate (¶ [0040]), and carries the signature algorithm identifier as one such attribute (¶ [0034]) but Batke does not order algorithms by relative strength. Examiner's note: the priority-ranking limitation of claims 5, 6, 9, and 10 is not squarely met by the applied art. See the § 112(b) rejection and the Allowable Subject Matter section below.
In regard to claim 10, Venkataraman teaches wherein, in the deletion of the control program, the first startup program deletes the second control program, and the second startup program deletes the first control program (Venkataraman teaches a boot loader exercising authority over code stored in the other region which boot loader A 212 verifies and conditionally loads or refuses the sections holding boot loader B 221 and the remaining code (col. 6:55-7:54) and Batke teaches an agent other than the target controlling what is written to the target (¶ [0023]). Assigning deletion authority across regions on the same principle, so that the currently executing and verified startup program governs removal of the other region's program, is an obvious implementation). Claim 10 is additionally subject to the § 112(b) rejection below by virtue of its dependency from claim 5.
Examiner's note:
Examiner has cited particular columns and line numbers in the references applied to the claims above for the convenience of the Applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the Applicant in preparing responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passages as taught by the prior art or disclosed by the Examiner.
Allowable Subject Matter
Claims 5-6, 9-10 would be allowable if rewritten or amended to overcome the rejection(s) under 35 U.S.C. 112, 2nd paragraph, set forth in this Office action.
16. The following is an Examiner's statement of reasons for the indication of allowable subject matter: Claims 5-6, 9-10 are allowable over the prior art of record because the prior arts, cited in its entirety, or in combination, do not teach
(1) Ranking of signature verification methods by relative cryptographic strength, with conditional deletion or storage based on that ranking. Neither Venkataraman nor Batke discloses ordering two signature algorithms against one another and acting on the comparison. Batke identifies which algorithm signed a given binary (¶ [0034]) but does not rank algorithms; Venkataraman uses one algorithm throughout. This is the subject matter of claims 5, 6, 9, and 10, presently indefinite. A claim reciting comparison of the cryptographic generation of two concurrently stored programs, with automatic deletion of the older-generation program, would appear to distinguish over the applied art, subject to further search once the term is clarified.
(2) Deletion performed as a discrete step within the boot sequence itself, rather than as a precondition to accepting an update. The applied references act on firmware at update time. A claim requiring the startup program, during the boot sequence, to evaluate the other region's program and delete it before proceeding would narrow the claims meaningfully; see spec. ¶0048], [0050] (steps S901, S902).
(3) Hardware-enforced non-rewritability of both startup programs. Venkataraman teaches one-time programmable storage for the first boot loader only (col. 6:55-7:54); its boot loader B 221 resides in the multiple-time programmable region and is rewritable. A claim requiring both the first and second startup programs to reside in physically write-protected memory is not met by the applied art.
Conclusion
All claims are rejected.
The prior arts made of record and not relied upon are considered pertinent to applicant's disclosure.
Yajima et al., US 9,530,004, teach secure boot method for automotive/embedded semiconductor device; multi-stage hash/signature verification. Relevant to Claims 1, 9.
Shah et al., US 11,062,032, teach firmware verified boot using multiple public keys and multiple hash algorithms for different firmware partitions. Each partition verified with a different key/algorithm pair. Highly relevant to plurality-of-methods element, Claims 1, 6, 9.
Lee et al., US 11,899,795, teach secure boot with primary public key from programmable region and fallback to embedded key in boot loader. Dual-key fallback is analogous to dual-bank signature-method fallback. Relevant to Claims 2, 4.
Gunti et al., US 10,242,196, teach secure booting using UEFI certificates; boot firmware selects among multiple certificates/public keys based on signing entity of boot loader. Relevant to signature-type-selection element, Claims 1, 6.
Ghosh et al., US 12,137,169, teach post-quantum signature verification for secure boot (XMSS/LMS); transitioning from RSA/ECDSA to post-quantum algorithms in embedded SoC. Directly relevant to quantum-resistance motivation and plurality-of-methods scope, Claims 1, 5, 6, 9.
Baltes et al., US 9,021,246, teach method to replace bootloader public key in automotive ECU; cryptographic key update as part of secure OTA flashing. Relevant to public-key update / algorithm transition concept, Claims 2–4.
Brotherson et al., US 11,818,278, teach dynamic cryptographic algorithm selection based on data/request metadata in agility framework; dynamically selecting algorithm based on type/attributes of the artifact being processed. Relevant to dynamic signature-type-based method selection, Claims 1, 5, 6.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to examiner Raymond Phan, whose telephone number is (571) 272-3630. The examiner can normally be reached on Monday-Friday from 6:30AM- 3:00PM. The Group Fax No. (571) 273-8300.
Communications via Internet e-mail regarding this application, other than those under 35 U.S.C. 132 or which otherwise require a signature, may be used by the applicant and should be addressed to [raymond.phan@uspto.gov].
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 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.
All Internet e-mail communications will be made of record in the application file. PTO employees do not engage in Internet communications where there exists a possibility that sensitive information could be identified or exchanged unless the record includes a properly signed express waiver of the confidentiality requirements of 35 U.S.C. 122. This is more clearly set forth in the Interim Internet Usage Policy published in the Official Gazette of the Patent and Trademark on February 25, 1997 at 1195 OG 89.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see hop://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
Any inquiry of a general nature or relating to the status of this application should be directed to the TC 2100 central telephone number is (571) 272-2100.
/RAYMOND N PHAN/
Primary Examiner, Art Unit 2175
Prosecution Insights