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 .
Herein after “it would have been obvious” should be read as “it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention”.
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.
Claim(s) 1 is/are rejected under 35 U.S.C. 103 as being unpatentable over Wang et al PN 2006/0064752 in view of Rajan et al PN 8,353,031.
In regards to claims 1, 13, 16: Wang teaches: a method for securing (Abstract, “A computer security system”) an electronic device, (Fig.1, [0006] “A computer security system”) comprising: a firmware (FW) agent (Fig.1, BIOS. [0012] “BIOS 14 comprises a TPM boot module 30 and a memory 32. TPM boot module 30 may comprise software, hardware, a combination of software and hardware” Firmware is a specific class of software that provides low-level control for a device's hardware, acting as a bridge between the physical hardware and higher-level software. It is distinct from application software because it is permanently stored in non-volatile memory—such as ROM, EPROM, or flash memory) in the electronic device [Fig.1] generating, during a boot process of the electronic device, (Abstract: “The BIOS is also adapted to receive TPM authentication data from the user for initiating a boot process and interface with the TPM to request validation of the TPM authentication data by the TPM for initiating the boot process using the user key”) a challenge (step 104,108) for an operating system (OS) agent ([0013] “Registration module 40 may be implemented as part of an operating system”) in the electronic device; ([0019] “At block 108, registration module 40 requests TPM authentication data 62 from the user”). the OS agent writing a response to the challenge in a mailbox in the electronic device; ([0019] “At block 110, registration module 40 receives TPM authentication data 62 from the user”. [0020] “At block 114, TPM 16 generates TPM user key 50 based on the TPM authentication data 62. At block 116, registration module 40 sends to BIOS 14 or otherwise causes to be stored in BIOS 14 TPM user key 50 and user identification data 60”) the FW agent checking the response during a subsequent boot process of the electronic device; ([0022] “At block 214, TPM boot module 30 requests verification of TPM authentication data 62 by TPM 16 using TPM user key 50. At decisional block 216, a determination is made whether TPM authentication data 62 verification by TPM 16 is successful” and the FW agent permitting or preventing completion of the subsequent boot process depending respectively on whether the response is correct or incorrect; [[0022] “if TPM authentication data 62 does not correspond to TPM user key 50, the method proceeds to block 202, where TPM boot module 30 may be configured to repeat the boot authentication process. If TPM authentication data 62 corresponds to TPM user key 50 or is otherwise verified by TPM 16, the method proceeds to block 218, where BIOS 14 continues or otherwise initiates the boot process”. [0015] “In some embodiments of the present invention, the registration operation is performed to enable a subsequent secure booting operation”) wherein the electronic device receives one or more inputs from a user between an end of the boot process and a beginning of the subsequent boot process. ([0017] “during a subsequent boot process in response to activation or enablement of TPM boot module 30 and acquisition and/or creation of TPM user key 50, TPM boot module 30 requests and/or otherwise receives user identification data 60”). Wang teaches registration module sends to BIOS or otherwise causes to be stored in BIOS TPM user key and user identification data, wherein storing TPM key corresponds to writing the response to the challenge in a mailbox. Wang does not teach “FW agent checking, during the boot process, that a prior response in a mailbox in the electronic device is correct, the prior response having been written to the mailbox prior to a start of the boot process”. Rajan et al teaches (Column 2 line 44 et seq. “For example, using data that is accessible before boot, but cannot be overwritten afterward, hashes of the boot sector and boot loader associated with the virtual security appliance can be stored (optionally with a public key)” Column 6 line 11 et. seq. “For example, using data storage that is accessible before boot, but that cannot be overwritten afterward (e.g., an optional pre-boot-only accessible memory (PBOAM) 270), hashes of the boot sector and boot loader and a digital key can be stored. The hashes can then be verified and a digital signature on the corresponding operating system image can then be checked to make sure it is authorized, with the computer system booting only if the checks succeed”). It would have been obvious to access security data before boot that cannot be overwritten after boot because this would have protected the security data.
In regards to claim 2: both Wang et al and Rajan et al booting only if the check succeeded (“the computer system booting only if the checks succeed”).
In regards to claim 3: Wang et al teaches the FW agent determining that there is no response in the mailbox during another boot process of the electronic device; and the FW agent preventing completion of the other boot process. (Fig.5, 216, [0022] “If TPM authentication data 62 does not correspond to TPM user key 50, the method proceeds to block 202, where TPM boot module 30 may be configured to repeat the boot authentication process, therefore preventing boot processor until validation of TPM key”).
In regards to claim 5: Wang et al teaches (step 216 if the passcode is correct “TPM Authentication Data Verified ?” Yes branch. The FW agent then permits completion of the boot process. (step 218).
In regards to claims 6, 15: Wang et al teaches ([0012] “Additionally, it should be understood that system 10 may be implemented in any of a variety of types of computing devices or systems including, but not limited to, a personal or desktop computer, personal digital assistant (PDA), notebook or laptop computer, tablet, workstation, and server”).
In regards to claim 12: Wang et al and Rajan et al both teach prior to the boot process setting up the electronic device so that the correct response is in the mailbox. ([0019]-[0020] “At block 110, registration module 40 receives TPM authentication data 62 from the user. At block 114, TPM 16 generates TPM user key 50 based on the TPM authentication data 62. At block 116, registration module 40 sends to BIOS 14 or otherwise causes to be stored in BIOS 14 TPM user key 50 and user identification data 60”).
In regards to claim 14: Wang et al teaches a TPM.
Claim(s) 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Wang et al PN 2006/0064752 in view of Rajan et al PN 8,353,031 as applied to claim 1 above, and further in view of Linnen et al PN 2019/0188403.
In regards to claim 4: Wang et al teaches a FW agent (BIOS) that during boot process challenges an OS agent and uses the challenge results to permit or prevent/deny a boot process if the challenge is incorrect. Wang et al does not teach checking a number of consecutive times the device has started to boot with no response (or correct response) in to the challenge. Linnen et al teaches ([0058] “If a retry is not allowed in block 520, the process proceeds to block 524 to log the failed boot, and to prevent access to the memory or to the DSDs in block 526. The number of retries may be a predetermined number of allowed retries or boot attempts stored in a memory of the DSD or the server. The attempt count may be compared to the predetermined number of allowed retries in block 520 to determine whether an authentication retry is allowed. In implementations where authentication must be successful on the first attempt, blocks 520 and 522 may be omitted so that the failed boot attempt is logged in block 524 if the time when the access code was generated does not correspond to the current time in block 516, and access is prevented in block 526 without allowing another attempt to authenticate”). It would have been obvious to count the number of successive failed boot processes because this would have prevented trial and error attempts to bypass security.
Claim(s) 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Wang et al PN 2006/0064752 in view of Rajan et al PN 8,353,031 as applied to claim 1 above, and further in view of Rogala PN 2021/0390185.
In regards to claim 7: Wang et al teaches writing the response prior to a subsequent boot. Rajan et al teaches the authentication data is accessible “before booting” (Column 2 line 44 et seq. “For example, using data that is accessible before boot, but cannot be overwritten afterward, hashes of the boot sector and boot loader associated with the virtual security appliance can be stored (optionally with a public key)” but does not state it is provided “during a shut-down procedure” Rogala teaches (Abstract: “A secure boot system and method to reduce a total time to boot by performing secure boot validation at shutdown and storing an authentication code in a secure manner, in effect, pre-authenticating an application so that, at the next boot, authentication may be bypassed”). It would have been obvious to store the authentication cade at shutdown because this would “reduce a total time to boot”. The examiner notes that storing the authentication code in a shutdown would be “before booting” in the next boot cycle which makes Rajan et al superfluous Rajan et al however expressly uses the words “before boot”.
Allowable Subject Matter
Claims 8-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.
The following is a statement of reasons for the indication of allowable subject matter: while public key and private key challenges are common for server communication, however the details of the combination of a boot authorization between a FW agent and an OS agent using the public key and private key were not found in the art.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Many claim limitations were presented in the alternative. Multiple references are cited for teaching the various alternative limitations such as Sheng et al PN 2024/0346187 that teaches the authentication code is stores in a UEFI variable. Shimada PN 2008/0040785 that teaches a response as soon as the OS starts ([0043] "For example, the quarantine system 1 starts when the agent software stored in the client terminal 10 starts to operate as the OS is started, and the agent software notifies to the authentication apparatus 100 that or the authentication apparatus 100 recognizes that the OS and the communication means 25 (such as NIC) of the client terminal 10 have been started").
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PAUL R MYERS whose telephone number is (571)272-3639. The examiner can normally be reached telework M-F start 7-8 leave 4-5.
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, Jaweed Abbaszadeh can be reached at 571-270-1640. 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.
/Paul R. MYERS/Primary Examiner, Art Unit 2176