DETAILED ACTION
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 office action is in response to amendments filed on June 16, 2025.
Claims 1, 3, 9, 11, 17 have been amended.
Claims 1-20 are pending.
Response to Arguments
The objections have been withdrawn as the claims have been amended. Applicant's arguments filed June 16, 2025 have been fully considered but they are not persuasive.
The Applicant argues that prior art reference Crowder specifically does not teach the claimed limitations occurring “during a boot cycle of the computer system” as currently amended (Remarks, Pages 10-11), and primarily relies upon the previous Office Action’s statement of obvious regarding combining prior art references Ndu and Crowder in which it was written that Crowder "teaches verifying software on a device after a device boot-up” (Remarks, Page 10, Par. 2). Examiner respectfully disagrees. While it is true that reference Crowder teaches software verification after a device boot-up as previously asserted in the Office Action, this was merely one embodiment of Crowder. In fact, Crowder teaches similar embodiments in which integrity verification occurs as part of the boot process analogous to the verification performed after the boot process (Par. [0078]-[0085]). For these reasons, the rejections under 35 U.S.C. 103 are maintained.
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 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.
Claims 1-2, 4-10, 12-20 are rejected under 35 U.S.C. 103 as being unpatentable over Ndu et al. (U.S. Pub. No. 2019/0384918 A1) hereinafter referred to as “Ndu”, in view of Crowder et al. (U.S. Pub. No. 2010/0062844 A1) hereinafter referred to as “Crowder”.
Regarding Claim 1:
Ndu teaches the following limitations:
An apparatus, comprising: a processor; and a memory having instructions stored thereon that, when executed by the processor, cause the apparatus to: cause firmware executed by a processor to verify a bootloader during a boot cycle of a computer system (Par. [0013], Par. [0018], Par. [0030], Par. [0043]). Ndu teaches firmware verifying a bootloader as part of a secure boot chain.
in response to verifying the bootloader, cause the bootloader to be executed to verify a kernel during the boot cycle of a computer system (Par. [0018], Par. [0043]). Ndu further teaches the bootloader verifying a kernel.
in response to verifying the kernel, cause the kernel to be executed to verify a trust agent during the boot cycle of the computer system (Par. [0016], Par. [0018], Par. [0043]). Ndu further teaches the kernel verifying kernel module code, i.e. a trust agent under the broadest reasonable interpretation as the module is trusted code after verification.
(taught by Crowder below)
(taught by Crowder below)
(taught by Crowder below)
(taught by Crowder below)
(taught by Crowder below)
Crowder teaches the following limitations:
in response to verifying the trust agent, cause the trust agent to process an application list to identify one or more files that are part of an application included in an application package and to generate a hash for the one or more files included in the application package during the boot cycle of the computer system (Fig. 4, Par. [0021], Par. [0022], Par. [0052], Par. [0078], Par. [0082], Par. [0085], Par. [0092]). Crowder teaches a manifest of a software package and verifying the hashes of files within this manifest by calculating the hash. This can be done using a file verification module as part of the boot-up of the device. Crowder further teaches this file verification being done as part of a boot-up process.
compare the hash for the one or more files included in the application package with a hash for the application package included in an application manifest file in a secure storage during the boot cycle of the computer system (Par. [0021], Par. [0022], Par. [0078], Par. [0087]). Crowder teaches comparing the calculated hash with the hash included in the manifest.
wherein the hash for the application package included in the application manifest file is calculated by a hash calculator during a packaging process in which the application package is formed, the hash calculator adds the hash for the application package calculated during the packaging process to the application manifest file (Fig. 4, Par. [0020], Par. [0067], Par. [0069], Par. [0092], Par. [0093], Par. [0094]). Crowder teaches that software packages contain the manifest files which list the precalculated file hashes. This suggests calculating hashes as part of the packaging process.
the application manifest file is signed by a signing module, and the application manifest file including the hash for the application package is added to the application package (Fig. 4, Par. [0020], Par. [0067], Par. [0092], Par. [0094]). This manifest file has a digital signature and is itself part of the package.
and in response to confirming a hash match between the hash for the one or more files included in the application package and the hash for the application package included in the application manifest file during the boot cycle of the computer system, cause the one or more files that are part of the application to be executed (Par. [0021], Par. [0082], Par. [0083], Par. [0085], Par. [0087]). Crowder teaches verifying the files as part of proceeding with loading/opening the files, i.e. execution, and this can be done at boot time.
Ndu teaches a secure boot process, but does not teach file validation for an application package. Crowder however teaches verifying software on a device during a device boot-up, and that this provides additional security through periodic validation and authenticity checking of executed code (Par. [0009], Par. [0014]). Therefore, it would have been obvious to one of ordinary skill in the art to combine the secure boot of Ndu with the software package checking of Crowder in order to gain the benefit of additional security in device execution. One of ordinary skill in the art would have recognized that the software checking of Crowder is compatible with the secure boot of Ndu because both relate to device boot-up processes, and that the additional software validation of Crowder would increase security by verifying that code is authentic and has not been tampered with through hash validation.
Regarding Claims 2, 10:
Ndu teaches the following limitation:
wherein the trust agent is a kernel module (Par. [0016], Par. [0018], Par. [0043]). Ndu was shown to teach a kernel module being verified.
Regarding Claims 4, 12, 18:
Crowder teaches the following limitation:
wherein the trust agent is caused to calculate the hash for all of the one or more files combined, and the hash for the application package is applicable for all of the one or more files (Par. [0021], Par. [0078], Par. [0092], Par. [0093], Par. [0094]). Crowder further teaches the manifest containing a digital signature corresponding to a hash for all files under the broadest reasonable interpretation. Alternatively, Crowder also teaches the manifest corresponding to a single file and therefore a single hash, which also teaches the claimed limitation.
The reasons for motivation/combination of references remain the same as recited in the respective independent claims.
Regarding Claims 5, 13, 19:
Crowder teaches the following limitation:
wherein the trust agent is caused to calculate the hash for each of the one or more files individually, and the hash for the application package is applicable for all of the one or more files (Fig. 4, Par. [0021], Par. [0022], Par. [0052], Par. [0078], Par. [0082], Par. [0092], Par. [0093]). Crowder was previously shown to teach the manifest containing a hash for each file specified in the package. Furthermore, Crowder was shown to teach a manifest corresponding to a single file, which would also teach the claimed limitation.
The reasons for motivation/combination of references remain the same as recited in the respective independent claims.
Regarding Claims 6, 14:
Crowder teaches the following limitation:
wherein the hash calculator is caused to calculate the hash for each of the one or more files included in the application package individually for inclusion in the application manifest file as the hash for the application package (Fig. 4, Par. [0020], Par. [0067], Par. [0069], Par. [0092], Par. [0093], Par. [0094]). As previously taught above, the creation of the manifest file involved individually hashing the files.
the trust agent is caused to calculate the hash for each of the one or more files individually (Fig. 4, Par. [0020], Par. [0067], Par. [0069], Par. [0092], Par. [0093], Par. [0094]). Likewise, the files to be verified have their hashes individually calculated.
and the hash match is determined based on a one-to-one matching of between the hash for each corresponding file of the one or more files included in the application package calculated by the hash calculator included in the application manifest file and the hash for each corresponding file of the one or more files included in the application package calculated by the trust agent (Fig. 4, Par. [0020], Par. [0067], Par. [0069], Par. [0092], Par. [0093], Par. [0094]). These hashes are SHA-1 hashes which must match exactly for verification.
The reasons for motivation/combination of references remain the same as recited in the respective independent claims.
Regarding Claims 7, 15, 20:
Crowder teaches the following limitation:
wherein the application manifest file added to the application package is signed by the signing module such that the application manifest file is secured with the application package and the application manifest file is capable of being confirmed as being associated with a trusted source (Fig. 4, Par. [0020], Par. [0078], Par. [0091], Par. [0097]). As taught above, the manifest file is part of the package and includes a digital signature. This digital signature teaches the capability of being verified of being associated with a trusted source under the broadest reasonable interpretation, since a digital signature is used for non-repudiation.
The reasons for motivation/combination of references remain the same as recited in the respective independent claims.
Regarding Claims 8, 16:
Crowder teaches the following limitation:
wherein the apparatus is further caused to: in response to confirming the application manifest file is associated with the trusted source, cause the application manifest file to be stored in the secure storage (Par. [0061], Par. [0063], Par. [0078], Par. [0166], Par. [0167]). Crowder further teaches storing the manifests in a manifests partition and authenticating the manifests’ digital signatures, this suggests storage, as Crowder further teaches that triggering a validation error causing intervention involving deleting/replacing the manifest.
Regarding Claim 9:
Ndu teaches the following limitations:
(taught by Crowder below)
(taught by Crowder below)
(taught by Crowder below)
(taught by Crowder below)
causing firmware executed by a processor to verify a bootloader during a boot cycle of a computer system (Par. [0013], Par. [0018], Par. [0030], Par. [0043]).
in response to verifying the bootloader, causing the bootloader to be executed to verify a kernel during the boot cycle of the computer system (Par. [0018], Par. [0043]).
in response to verifying the kernel, causing the kernel to be executed to verify a trust agent during the boot cycle of the computer system (Par. [0016], Par. [0018], Par. [0043]).
(taught by Crowder below)
(taught by Crowder below)
(taught by Crowder below)
Crowder teaches the following limitations:
A method, comprising: causing one or more files that are part of an application to be packaged to form an application package (Fig. 4, Par. [0020], Par. [0067], Par. [0069], Par. [0092], Par. [0093], Par. [0094]). Crowder taught software packages containing files.
during a packaging process wherein the application package is formed, causing a hash calculator to calculate a hash for the application package (Fig. 4, Par. [0020], Par. [0067], Par. [0069], Par. [0092], Par. [0093], Par. [0094]). These files have hashes which are stored in a manifest which is a part of the package.
and a signing module to generate an application manifest file comprising the hash for the application package (Fig. 4, Par. [0020], Par. [0067], Par. [0069], Par. [0092], Par. [0093], Par. [0094]). This manifest is signed.
causing the application manifest file to be added to the application package (Fig. 4, Par. [0020], Par. [0067], Par. [0069], Par. [0092], Par. [0093], Par. [0094]).
in response to verifying the trust agent, causing the trust agent to process an application list to identify the one or more files that are part of the application included in the application package and to generate a hash for the one or more files included in the application package during the boot cycle of the computer system (Fig. 4, Par. [0021], Par. [0022], Par. [0052], Par. [0078], Par. [0082], Par. [0085], Par. [0092]).
comparing the hash for the one or more files included in the application package with the hash for the application package included in the application manifest file during the boot cycle of the computer system (Par. [0021], Par. [0022], Par. [0078], Par. [0087]).
and in response to confirming a hash match between the hash for the one or more files included in the application package and the hash included in the manifest file during the boot cycle of the computer system, causing the one or more files that are part of the application to be executed (Par. [0021], Par. [0082], Par. [0083], Par. [0085], Par. [0087]).
Ndu teaches a secure boot process, but does not teach file validation for an application package. Crowder however teaches verifying software on a device during a device boot-up, and that this provides additional security through periodic validation and authenticity checking of executed code (Par. [0009], Par. [0014]). Therefore, it would have been obvious to one of ordinary skill in the art to combine the secure boot of Ndu with the software package checking of Crowder in order to gain the benefit of additional security in device execution. One of ordinary skill in the art would have recognized that the software checking of Crowder is compatible with the secure boot of Ndu because both relate to device boot-up processes, and that the additional software validation of Crowder would increase security by verifying that code is authentic and has not been tampered with through hash validation.
Regarding Claim 17:
Ndu teaches the following limitations:
A non-transitory computer readable medium having instructions stored thereon that, when executed by a processor, cause an apparatus to (Par. [0031], Par. [0054]).
cause firmware executed by a processor to verify a bootloader during a boot cycle of the computer system (Par. [0013], Par. [0018], Par. [0030], Par. [0043]).
in response to verifying the bootloader, cause the bootloader to be executed to verify a kernel during the boot cycle of the computer system (Par. [0018], Par. [0043]).
in response to verifying the kernel, cause the kernel to be executed to verify a trust agent during the boot cycle of the computer system (Par. [0016], Par. [0018], Par. [0043]).
(taught by Crowder below)
(taught by Crowder below)
(taught by Crowder below)
(taught by Crowder below)
(taught by Crowder below)
Crowder teaches the following limitations:
in response to verifying the trust agent, cause the trust agent to process an application list to identify one or more files that are part of an application included in an application package and to generate a hash for the one or more files included in the application package during the boot cycle of the computer system (Fig. 4, Par. [0021], Par. [0022], Par. [0052], Par. [0078], Par. [0082], Par. [0085], Par. [0092]).
compare the hash for the one or more files included in the application package with a hash for the application package included in an application manifest file in a secure storage during the boot cycle of the computer system (Par. [0021], Par. [0022], Par. [0078], Par. [0087]).
wherein the hash for the application package included in the application manifest file is calculated by a hash calculator during a packaging process in which the application package is formed, the hash calculator adds the hash for the application package calculated during the packaging process to the application manifest file (Fig. 4, Par. [0020], Par. [0067], Par. [0069], Par. [0092], Par. [0093], Par. [0094]).
the application manifest file is signed by a signing module, and the application manifest file including the hash for the application package is added to the application package (Fig. 4, Par. [0020], Par. [0067], Par. [0092], Par. [0094]).
and in response to confirming a hash match between the hash for the one or more files included in the application package and the hash for the application package included in the application manifest file during the boot cycle of the computer system, cause the one or more files that are part of the application to be executed (Par. [0021], Par. [0082], Par. [0083], Par. [0085], Par. [0087]).
Ndu teaches a secure boot process, but does not teach file validation for an application package. Crowder however teaches verifying software on a device during a device boot-up, and that this provides additional security through periodic validation and authenticity checking of executed code (Par. [0009], Par. [0014]). Therefore, it would have been obvious to one of ordinary skill in the art to combine the secure boot of Ndu with the software package checking of Crowder in order to gain the benefit of additional security in device execution. One of ordinary skill in the art would have recognized that the software checking of Crowder is compatible with the secure boot of Ndu because both relate to device boot-up processes, and that the additional software validation of Crowder would increase security by verifying that code is authentic and has not been tampered with through hash validation.
Claims 3, 11 are rejected under 35 U.S.C. 103 as being unpatentable over Ndu/Crowder, and further in view of Jones et al. (U.S. Pub. No. 2016/0087801 A1) hereinafter referred to as “Jones”.
Regarding Claims 3, 11:
Jones teaches the following limitations:
wherein the bootloader comprises a shim and a grand unified bootloader (GRUB) (Par. [0023], Par. [0056]). Jones teaches that a bootloader can alternative comprise a first-stage bootloader and a second-stage bootloader, i.e. a shim and GRUB (Grand Unified Bootloader).
the firmware verifies the shim to verify the bootloader and causes the shim to be executed to verify the GRUB (Par. [0056], Par. [0058], Par. [0059]). The first-stage bootloader is verified by the firmware, which causes the second-stage bootloader to be verified by the first stage bootloader as part of the secure boot chain.
and in response to verifying the GRUB, the GRUB verifies the kernel such that the bootloader verifies the kernel (Par. [0056], Par. [0062], Par. [0063]). The second stage bootloader then verifies the kernel.
Ndu/Crowder do not teach a shim and GRUB. Jones however teaches that a bootloader may comprise a first-stage bootloader, i.e. shim, and a second-stage bootloader, i.e. GRUB, and this implementation results in additional user convenience and security (Par. [0056]). Therefore, it would have been obvious to one of ordinary skill in the art to combine the secure software execution system of Ndu/Crowder with the bootloader implementation of Jones in order to gain the benefit of additional security/user convenience through improved key management. One of ordinary skill in the art would have recognized that the bootloader implementation of Jones is compatible with the secure boot of Ndu/Crowder as both systems relate to secure boot chains, and that the first/second-stage bootloader implementation of Jones would provide additional security/user convenience by not having to update a verification key as often when updating a bootloader or kernel (Jones, Par. [0056]).
Related Art
The following prior art made of record and cited on PTO-892, but not relied upon, is considered pertinent to applicant’s disclosure:
Bobzin (U.S. Pub. No. 2013/0124843 A1) – Includes methods regarding secure boot
Singhal et al. (U.S. Pub. No. 2018/0091315 A1) – Includes methods regarding secure boot
Moon et al. (U.S. Patent No. 10,180,842 B2) – Includes methods regarding secure boot
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ETHAN V VO whose telephone number is (571)272-2505. The examiner can normally be reached M-F 8am-5pm.
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, Lynn Feild can be reached on (571)272-2092. 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.
/E.V.V./Examiner, Art Unit 2431
/LYNN D FEILD/Supervisory Patent Examiner, Art Unit 2431