DETAILED ACTION
Response to Amendment
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 .
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 to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 3, 4, 6-9, 12, 13, 15, 16, 18, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Wang et al. (U.S. Patent Application Publication Number 2007/0162964), Moore et al. (U.S. Patent Application Publication Number 2015/0236856), and Cromer et al. (U.S. Patent Application Publication Number 2005/0144443).
Regarding Claims 1, 12, and 13, Wang discloses a booting device (Figure 2, item 210) for a computer element (Figure 2, item 200), for booting the computer element (paragraph 0032), wherein the booting device comprises:
a memory unit (Figure 2, items 160, 190, and 220) comprising an eFuse (Figure 2, item 190), the memory unit being configured to store a protection code outside of the eFuse (Figure 2, item 160, paragraph 0033; i.e., the on-chip ROM 160 contains the protection code that the HMAC module 250 uses to check the integrity of the boot code 230 in flash ROM 130); and
a protection unit (Figure 2, item 250, paragraph 0032; i.e., the HMAC module) configured to check integrity of a software component (Figure 2, item 230) of the computer element by reference to the protection code, the protection code being a program configured to be run by the protection unit (paragraph 0033), wherein the booting device is configured for executing the software component to boot the computer element (paragraph 0033; i.e., the protection unit 250 checks the integrity of the software component 230 using firmware stored in on-chip ROM 160 with key data retrieved from the eFuse 190),
wherein the protection code is at least partially changeable from outside the booting device (paragraphs 0030 and 0033; i.e., the protection code stored in on-chip ROM 160 is at least partially changeable [by the chip vendor] and the protection value stored in eFuse 190 is also at least partially changeable), on a one-time basis, via burn-in of a protection value (i.e., the key ID stored inside eFuse 190) of the protection code in the eFuse, outside of the eFuse (paragraphs 0030 and 0033; i.e., the protection value [a key ID] is stored in the eFuse 190), such that the protection code, after burn-in in the eFuse, includes a first portion stored in the memory unit outside of the eFuse and a second portion stored in the eFuse (paragraph 0033; i.e., the “first portion” of the protection code is stored inside on-chip ROM 160, which is stored in “the memory unit outside of the eFuse” [memory 160], while the “second portion” of the protection code is the protection value portion of the protection code [the key ID], which is stored in the eFuse 190),
wherein the protection unit being configured to check the integrity of the software component of the computer element by reference to the protection code comprises the protection unit being configured, after the burn-in in the eFuse (paragraph 0033; i.e., the protection code inside on-chip ROM 160 must be run after burn-in of the eFuse 190 because the key data in the eFuse 190 is retrieved before running the protection code), to run the protection code including the first portion stored in the memory unit outside of the eFuse and the second portion stored in the eFuse (Figure 2, item 160, paragraph 0033 and claim 4; i.e., the on-chip ROM 160 contains the protection code that the HMAC module 250 uses to check the integrity of the boot code 230 in flash ROM 130; the key data stored in eFuse 190 is considered to be a portion of the protection code because it is necessary to properly run the protection code), and
wherein the protection value comprises a comparative hash value, a cryptographic key (paragraph 0033; i.e., a key ID), or the comparative hash value and the cryptographic key (paragraph 0033; i.e., the protection code can include key data that is used for the Hash-based Message Authentication Code [HMAC] module 250; this would indicate that the key data includes a comparative hash value since the HMAC module 250 can use that information to check the integrity of the boot code 230).
Wang does not expressly disclose wherein the burn-in of the protection value of the protection code in the eFuse is after the protection code is stored in the memory unit;
wherein the booting device is configured to permit an alteration of the protection code from outside the booting device only in the event that:
the booting device detects that the alteration of the protection code is executed via an interface of the protection unit that is provided by a manufacturer of the booting device for this purpose;
the booting device detects that the alteration of the protection code is executed in accordance with a predefined standard, by reference to a predefined amendment file that is stipulated by the manufacturer of the booting device, or a combination thereof;
the booting device detects that the alteration of the protection code is executed using a predefined configuration device of the manufacturer;
the booting device only permits a one-time alteration of a respective region of the protection code, and the booting device detects that the alteration is a first alteration of the protection code in the respective region thereof; or
any combination thereof.
In the same field of endeavor (e.g., booting techniques), Moore teaches wherein the burn-in of the protection value of the protection code in the eFuse (Figure 3, item 306, paragraph 0041) is after the protection code is stored in the memory unit (Figure 3, items 302 and 304, paragraphs 0038-0040; i.e., the protection value [a “value” burned into the e-fuse to prevent data in the non-volatile memory from being rewritten] is burned in after the protection code [hash values/public keys and program values/session keys] are stored in the non-volatile memory [the “memory unit”]).
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined Moore’s teachings of booting techniques with the teachings of Wang, for the purpose of preventing a malicious entity from rewriting important data in the memory unit. This could prevent hacking attempts of the booting device.
Also in the same field of endeavor (e.g., booting techniques), Cromer teaches wherein the booting device (Figure 1, item 40, paragraph 0039; i.e., considering the TBB 40 is the “center of the trusted platform”, it is presumed that it is the one that controls access to the trusted platform) is configured to permit an alteration of the protection code (Figure 1, item 50, paragraph 0039; i.e., the protection code 50 is located within the trusted platform) from outside the booting device only in the event that:
the booting device detects that the alteration of the protection code is executed via an interface of the protection unit that is provided by a manufacturer of the booting device for this purpose;
the booting device detects that the alteration of the protection code is executed in accordance with a predefined standard, by reference to a predefined amendment file that is stipulated by the manufacturer of the booting device, or a combination thereof;
the booting device detects that the alteration of the protection code is executed using a predefined configuration device of the manufacturer (paragraph 0042; i.e., only the manufacturer can alter the protection code 50, which would indicate that it is being done using a configuration device that is predefined by the manufacturer; the booting device 40 makes the determination of whether an entity is allowed to alter the protection code 50);
the booting device only permits a one-time alteration of a respective region of the protection code, and the booting device detects that the alteration is a first alteration of the protection code in the respective region thereof; or
any combination thereof.
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined Cromer’s teachings of booting techniques with the teachings of Wang, for the purpose of preventing unauthorized users from being able to modify the protection code, thereby preventing hacking or other failures in the booting device.
Regarding Claim 3, Wang discloses and wherein the protection unit is configured, in conjunction with the integrity check of the software component for: a comparison of a component hash value of the software component with the comparative hash value (paragraph 0033; i.e., the HMAC module 250 compares the hash values of the boot code 230 and the key data from protection code 190 to check the integrity of the boot code 230); decryption, checking, or decryption and checking of cryptographically protected information assigned to the software component, by reference to the cryptographic key; or a combination thereof.
Regarding Claim 4, Wang discloses wherein the protection code comprises an editable cryptographic code (paragraph 0039; i.e., the protection code may include AES data for encryption and decryption; the reference does not state that the AES data is permanent, which would indicate that it is editable), and wherein the protection unit is operable, in conjunction with the integrity check of the software component (Figure 5, item 240; i.e., in the example of Figure 5, the AES unit 520 checks the integrity of a software component 240), to: run the editable cryptographic code in order to execute a hash value comparison; run the editable cryptographic code in order to execute a cryptographic encryption, decryption, check, or any combination thereof (paragraph 0039; i.e., the AES module 520 can use key data from the eFuse 190 to encrypt and/or decrypt data); or a combination thereof.
Regarding Claim 6, Wang discloses wherein the booting device is configured in the form of a computer chip (paragraph 0027; i.e., an application-specific integrated circuit [ASIC]).
Regarding Claim 7, Wang discloses wherein the computer element comprises a computer, an I/O module (Figure 1, see connection between items 110 and 130/140), a CPU module (Figure 1, item 150), or a FPGA system that, upon booting, is configurable in the form of a software component by reference to a bitstream (paragraph 0033; i.e., the embedded system 200 is configured based on the information [a “bitstream”] obtained from boot code 230 as well as firmware 240).
Regarding Claim 8, Wang discloses wherein the software component comprises hardware, software, or hardware and software (paragraph 0033; i.e., boot code 230 is software that is stored on a hardware flash ROM 130).
Regarding Claim 9, Wang discloses a booting unit (Figure 2, item 150) configured to execute the software component in the event that the protection unit determines, by an integrity check, that the software component fulfils all requirements for integrity (abstract and paragraph 0028; i.e., the system boots after the software is checked for integrity; the microcontroller unit 150 performs all of the central functions of the embedded system 200 and therefore presumable also performs booting of the system).
Regarding Claim 15, Wang discloses wherein the editable cryptographic code is an editable hash code (paragraph 0039; i.e., the key data stored in the eFuse 190 can be altered one time [paragraph 0030]; that key data is used as an input to the HMAC module 250; therefore, it is an editable hash code).
Regarding Claim 16, Wang discloses wherein the software component is a first bootloader stage (paragraph 0034; i.e., only a first portion of the boot code 230 needs to initially be checked for integrity to boot the embedded system 200 [other portions can be checked later on]; this first portion is equivalent to the claimed “first bootloader stage”).
Regarding Claim 18, Cromer teaches wherein the booting device is configured to permit the alteration of the protection code from outside the booting device only in the event that: the booting device detects that the alteration of the protection code is executed via an interface of the protection unit that is provided by a manufacturer of the booting device for this purpose; the booting device detects that the alteration of the protection code is executed in accordance with a predefined standard, by reference to a predefined amendment file that is stipulated by the manufacturer of the booting device, or a combination thereof; the booting device detects that the alteration of the protection code is executed using a predefined configuration device of the manufacturer (paragraph 0042; i.e., only the manufacturer can alter the protection code 50, which would indicate that it is being done using a configuration device that is predefined by the manufacturer); or any combination thereof.
Regarding Claim 19, Cromer teaches wherein the booting device is configured to permit the alteration of the protection code from outside the booting device only in the event that: the booting device detects that the alteration of the protection code is executed via an interface of the protection unit that is provided by a manufacturer of the booting device for this purpose; or the booting device detects that the alteration of the protection code is executed using a predefined configuration device of the manufacturer (paragraph 0042; i.e., only the manufacturer can alter the protection code 50, which would indicate that it is being done using a configuration device that is predefined by the manufacturer).
Allowable Subject Matter
Claims 10 and 11 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Claim 17 is allowed.
The following is a statement of reasons for the indication of allowable subject matter:
Regarding Claims 10 and 17, the prior art of record does not teach “wherein the protection unit being configured to check the integrity of the software component comprises the protection unit being configured to: hash a signature verification code with a hash code of the booting device, such that a first hash result is obtained; compare the first hash result with a signature verification code hash value of the memory unit; in the event that the comparison of the first hash result with the signature verification code hash value confirms that the first hash result and the signature verification code hash value are identical; acquire the software component, including a signature of the software component and a public key for the software component; hash the public key of the software component with the hash code of the booting device, such that a second hash result is obtained; compare the second hash result with a public key hash value of the memory unit; in the event that the comparison of the second hash result with the public key hash value confirms that the second hash result and the public key hash value are identical, check the signature of the software component by reference to the signature verification code; and in the event that the check of the signature of the software component confirms that the signature is correct, execute the software component.”
Claim 11 is allowable due to its dependency on Claim 10.
Response to Arguments
Applicant's arguments filed 1/13/26 have been fully considered but they are not persuasive.
Regarding Claim 1, Applicant argues “Cromer et al. merely disclose a restriction of authority (e.g., ‘only the manufacturer can modify or update boot block code 50’), not a ‘configuration.’ See, Cromer et al., paragraph [0042]. The fact that ‘only a manufacturer’ can perform an action does not teach a booting device that detects alterations of the protection code.” Response, page 15. The examiner disagrees. Contrary to Applicant’s argument, Cromer does in fact teach the argued feature. Cromer states that the TBB 40 is the “center of the trusted platform” (paragraph 0040) and therefore it is presumed that it is the one that controls access to the trusted platform. The protection code 50 is located within the trusted platform (Figure 1). As previously stated, Cromer states that “only the manufacturer can modify or update boot block code 50.” Cromer, paragraph 0042. To “configure” a device involves modifying or updating it (e.g., modifying or updating its content or settings). Therefore, Cromer teaches a “predefined configuration device”. Further, by only allowing the manufacturer to modify the protection code 50, the booting device 40 necessarily has the ability to permit alteration of the protection code only in that instance. For example, if a non-manufacturer entity were to attempt to modify the protection code 50, the booting device 40 would prevent it. Therefore, “the booting device is configured to permit an alteration of the protection code from outside the booting device only in the event that … the booting device detects that the alteration of the protection code is executed using a predefined configuration device of the manufacturer”, as claimed.
Regarding Claim 1, Applicant argues “merely modifying or updating code does not explicitly require a booting device to detect ‘a predefined amendment file’ or ‘a predefined standard’ as a condition precedent to permitting the alteration (e.g., only in the event that). In fact, Cromer et al. are completely silent regarding ‘a predefined amendment file’ or ‘a predefined standard.’” Response, pages 15-16. However, the prior art reference is not required to contain these features in order for it to teach the claim as a whole. This is because the phrase “any combination thereof” is used at the end of the claim. By using this phrase, it makes the four options preceding it be in the alternative. Therefore, the prior art reference only needs to contain one of the four options in order for the claim to read on it. As stated above, Cromer teaches the third option. Accordingly, Applicant’s argument is not persuasive.
Therefore, the claims stand as previously rejected.
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 FAISAL M ZAMAN, ESQ. whose telephone number is (571)272-6495. The examiner can normally be reached Monday - Friday, 8 am - 5 pm, alternate Fridays.
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 on 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.
/FAISAL M ZAMAN/ Primary Examiner, Art Unit 2175