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 .
Information Disclosure Statement
The information disclosure statement(s) (IDS) submitted on 2/6/2024 and 03/12/2024 is/are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement(s) is/are being considered by the examiner. The signed documents were inadvertently left out of the previous office action and are attached to this office action.
Response to Amendment
This communication is in response to the amendment filed on 10/8/2025. The Examiner acknowledges amended claims 1-20. No claims have been cancelled or added. Claims 1-20 are pending and claims 1-20 are rejected. Claims 1 and 16 is/are independent.
The rejection(s) of claims under 35 U.S.C. § 112 are withdrawn in view of Applicant's amendments except as specifically set forth below.
The rejection(s) of claims under 35 U.S.C. § 102/103 have been updated based on new grounds of rejection as indicated below.
Response to Arguments
Applicant's arguments filed 10/8/2025 have been fully considered. Applicant argues (see Remarks, page 7 paragraph 5 - page 8 paragraph at the bottom) that the references cited in the previous rejection fail to disclose the newly amended claim features. This argument is persuasive. Therefore, the rejections are withdrawn. However, upon further consideration, a new ground of rejection is made in view of Tuttle et al. U.S. Publication 20190251266 (hereinafter “Tuttle”) in view of Lenny et al. U.S. Publication 20060236125 (hereinafter “Lenny”).
Lenny teaches reading boot error data from a register of a storage device via an interface (1:63-2:2; 4:47-51; 4:58-5:20; 12:1-8; 13:44-45; 16:53-62; 17:34-41).
Regarding applicant’s arguments for claim 5 at page 8, para 5, claim 5 has is now rejected with a new combination of references, which includes a register of a storage device that is non-volatile memory as described in Lenny as cited above. Furthermore, the limitation during the execution of the boot code, under the broadest reasonable interpretation, can include the time from the beginning of a boot process under the boot code until the next boot or shut down of the machine being booted. Until the computer is shut down or rebooted, the entire time that the computer is on may be considered to disclose during the execution of the boot code. This would cover the entire time period for verifying a machine after receiving a signal to initiate a reboot as taught in para. 29 of Tuttle, and would cover verification of its storage device during the boot process as taught in Lenny as cited above. Note also that such a boot code can be disclosed by Lenny, such as the enable/disable drive failure prediction flag (13:47), in which “the host computer 12 checks as to whether drive failure prediction has been enabled as part of the power-on-self-test (or "POST") performed during power-up.” (13:42-46).
Independent claim 16 recites limitations analogous to the limitations of claim 1 and are also rejected for similar reasons. Regarding applicant’s arguments with respect to the dependent claims 2-15, and 17-20, applicant’s amendments to the independent claims have necessitated a new ground of rejection with respect to the independent claims from which the dependent claims depend, thereby requiring new grounds of rejection for the dependent claims also.
Accordingly, Applicant's argument is persuasive, the rejection is withdrawn, and new ground(s) of rejection are presented herein. Note that this action is made FINAL. See MPEP § 706.07(a).
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
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 1-20 is/are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Claim 1 recites “memory coupled to processor” However, it is unclear whether processor is referring to the processor previously introduced or introducing another processor.
Claim 16 recites similar limitations and has a similar issue, and is rejected for the same reason.
The dependent claims inherit the limitations of their respective independent claims and are rejected for the same reasons as their respective independent claim.
Appropriate correction is required.
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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tuttle et al. U.S. Publication 20190251266 (hereinafter “Tuttle”) in view of Lenny et al. U.S. Patent No. 6467054 (hereinafter “Lenny”).
As per claim 1, Tuttle discloses
A method, comprising: [method for clearance process, para. 29]
executing, by a processor [one or more processors, para. 64] of a processing device, [bare-metal resource 110, figure 1; para. 14; one or more computing systems, para. 64 ] a boot code [boot code = particular sequence signal; signals may be sent in a particular sequence to initiate the reboot, para. 29; signal may be an interrupt, para. 29; the specification does not explicitly define boot code] to carry out a boot sequence [boot sequence, para. 35] of the processing device;
[0064] In the description above, embodiments and examples are described with reference to acts that are performed by one or more computing systems. 1 If such acts are implemented in software, one or more processors of the associated computing system that performs the act direct the operation of the computing system in response to having executed computer-executable instructions
wherein executing comprises:
performing at least one verification step [detects for progress forward progress, para. 35,; determining which operations have completed, para. 35; ]to verify a proper progress of the boot sequence during execution of the boot code; and
[0035] In yet another example of verifying completion of the clearance process, the trusted infrastructure device 150 detects forward progress in the boot sequence (or lack thereof) during the reboot from the trusted portion 120. Determining progress of the boot sequence may be performed by storing the predetermined sequence of operations for the boot sequence, and determining which operations have completed. In an example, the clearance manager 122 may write values to predetermined registers in the memory 126 that indicate performance of the operations. The trusted infrastructure device 150 may also measure the elapsed time of the clearance process since the sequence began to determine whether the process is stalled. The elapsed time may be measured by a timer or multiple timers for measuring execution of different operations of the clearance process. The trusted infrastructure device 150 may send an alert if it detects that the bare metal resource 110 is not making forward progress in its clearance process. Also, the trusted infrastructure device 150 and/or the clearance manager 122 may determine how far the clearance process completed before crashing and may invoke operations based on how far the clearance has completed. For example, steps in the clearance process that were successfully completed before the clearance process failed may be skipped when the clearance process is restarted.
when said at least one verification step identifies an error [detect lack of forward progress, para. 35; measure elapsed time to determine if process stalled, para. 35; detect crashing, detect clearance progress failed, para. 35] in proper progress of the boot sequence, storing a status value in a register [write values to predetermined registers that indicate performance, para. 35;] of the processing device and resetting [clearance process is restarted, para. 35] of the processing device;
However, Tuttle does not expressly disclose
when said at least one verification step identifies an error in proper progress of the boot sequence, storing a status value indicative of the identified error in a register of a non-volatile memory coupled to processor of the processing device and resetting of the processing device;
wherein the register of the non-volatile memory is accessible in read mode via a debugging interface of the processing device to read the stored status value.
Lenny discloses register [error register 46 and/or status register 44 in Lenny figure 2; error register 46 is a register that provides information pertaining to the current error condition of the storage device (the error information in the register disclosing indicative of the identified error) 4:58-5:20] containing boot testing error information [errors is stored in the error register 46, which is part of the I/O registers 18 4:58-5:20; monitoring power on self test (or "POST") errors 12:1-8; 13:37-48] ]and the register is part of an interface 4:58-5:20 (disclosing debugging interface) of a storage device (disclosing non-volatile memory) 4:34-38 , and the register is read by the host machine or other tester to determine errors in the boot test sequence [monitoring power on self test (or "POST") errors 12:1-8; 13:37-48 ; same interface may be used during post failure analysis where the storage device receives test commands from the tester to determine the cause of a failure 1:63-2:2; execute diagnostic self-tests and provide results back to the host 12; command block registers 26, which form a portion of the ATA interface I/O registers 18 4:58-5:20]
[there is no explicit definition of debugging interface in the specification and the claim does not require a user interface. The error register 46 and/or status register 44 in Lenny figure 2 discloses the register of the non-volatile memory; Lenny Figure 1 depicts the CPU as part of element 12 coupled to the hard drive thereby disclosing non-volatile memory coupled to processor.
]
Regarding the last limitation, Lenny discloses wherein the register [error register 46 and/or status register 44 in Lenny figure 2; 4:58-5:20] of the non-volatile memory [storage device, 4:34-38 ] is accessible in read mode [the data from the error registers can be read 4:47-51; 4:58-5:20] via a debugging interface [ATA interface 4:34-38; 4:58-5:20; 1:63-2:2] of the processing device [host computer system 12] to read the stored status value. [data from the error registers can be read 4:47-51; 4:58-5:20]
Lenny 4:34-38 (3) storage device 14 is comprised of an AT attachment (or "ATA") interface input/output (or "I/O") registers 18 through which communication to or from the storage device 14 is routed
4:47-51 (4) A controller 19 is coupled to the I/O registers 18, and the drive sectors 20, 22, 23 and 24 to control the operation of the storage device 14, service commands from the host computer 12, execute diagnostic self-tests and provide results back to the host 12.
Lenny 4:58-5:20 (5) Referring next to FIG. 2, command block registers 26, which form a portion of the ATA interface I/O registers 18, will now be described in greater detail. Data register 28, … Status register 44 is a register that displays information pertaining to the current status of the storage device 14, such as when the storage device 14 is busy ("BSY" bit) and when an error occurred during execution of the previous command error ("ERR" bit). Finally, error register 46 is a register that provides information pertaining to the current error condition of the storage device 14, such as when a requested command has been command aborted ("ABRT" bit) such as when the command code or a command parameter is invalid or some other error has occurred.
1:63-2:2 (8) test results are provided by the storage device to the tester over a proprietary serial cable. The same interface may be used during post failure analysis where the storage device receives test commands from the tester to determine the cause of a failure…
12:1-8 (40) attributes which may be selected for monitoring are… power on self test (or "POST") errors
Lenny 13:44-45 (46) the power-on-self-test (or "POST") performed during power-up.
16:53-62 64) Proceeding on to step 354, the self-test is initiated …. Anytime a failure occurs, the storage device 14 sets the ABRT bit in the error register 46 and the ERR bit in the status register 44.
17:34-41 (68) If a failure is detected, the method proceeds to step 376 to abort the self-test, set the self-test execution status flags and write a unique signature into the cylinder high 38 and cylinder low 36 registers. Preferably, the unique signature is indicated by a F4h in the cylinder high 38 register and a 2Ch in the cylinder low 36 register. Anytime a failure occurs, the storage device 14 sets the ABRT bit in the error register 46 and the ERR bit in the status register 44.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Tuttle with the technique for reading boot error data from a register of a storage device via an interface of Lenny to include
when said at least one verification step identifies an error in proper progress of the boot sequence, storing a status value indicative of the identified error in a register of a non-volatile memory coupled to processor of the processing device and resetting of the processing device;
wherein the register of the non-volatile memory is accessible in read mode via a debugging interface of the processing device to read the stored status value.
One of ordinary skill in the art would have made this modification to improve the ability of the system to test a storage device during a boot sequence, and to be able to detect and/or diagnose issues with the boot sequence that includes the storage device. The system of the primary reference can be modified to utilize an interface that includes registers of a storage device to provide error data during the boot sequence that includes the storage device. The registers of the storage device can include error data informing of errors during the boot sequence.
As per claim 16, the claim(s) is/are directed to a processing device with limitations which correspond to limitations of claim 1, and is/are rejected for the reasons detailed with respect to claim 1. Claim 16 also recites, and Tuttle discloses, A processing device, comprising:
a processor configured to perform, during execution of a boot code [particular sequence signal; signals may be sent in a particular sequence to initiate the reboot, para. 29; signal may be an interrupt, para. 29; the specification does not explicitly define boot code] to carry out a boot sequence [boot sequence, para. 35] of the processing device:
[0015] The bare metal resource 110 has a motherboard including hardware devices 111. The hardware devices 111 may include CPUs 112, storage devices 113 and other hardware not shown.
[0064] In the description above, embodiments and examples are described with reference to acts that are performed by one or more computing systems. If such acts are implemented in software, one or more processors of the associated computing system that performs the act direct the operation of the computing system in response to having executed computer-executable instructions
Claims 2 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tuttle in view of Lenny, further in view of Healy et al. U.S. Publication 20160239663 (hereinafter “Healy”).
As per claim 2, the rejection of claim 1 is incorporated herein.
However, the combination of Tuttle and Lenny does not expressly disclose wherein the status value provides an indication that an error occurred during the verification step.
Healy discloses a value stored in a register indicates that an error occurred during a verification process
[0026] Memory 104 may further include ECC check bits 107, an ECC controller 108, and an error logging unit 110. The error logging unit may comprise an error address register (EAR) bank 110A and an error count register (ECR) 110B. The EAR bank 110A may be a bank of registers, where each register stores the location of an error detected by the ECC controller 108. For example, the EAR bank 110A may store the row address, the column address, or both the row and column address of a memory cell in which the ECC controller 108 detected an error. The ECR 110B may be a register in which an error count is stored.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Tuttle and Lenny with the teaching that a value stored in a register indicates that an error occurred during a verification process of Healy to include wherein the status value provides an indication that an error occurred during the verification step.
One of ordinary skill in the art would have made this modification to improve the ability of the system to store information indicating an error has occurred during a verification process, so that other processes or equipment may access this information, to facilitate recovery from an error. The system of the primary reference can be modified so that information stored in a register can indicate an error occurred during a verification process.
As per claim 17, the claim(s) is/are directed to a processing device with limitations which correspond to limitations of claim 2, and is/are rejected for the reasons detailed with respect to claim 2.
Claims 3 and 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tuttle in view of Lenny, in view of Healy, further in view of Nutter et al. U.S. Publication 20080066074 (hereinafter “Nutter”).
As per claim 3, the rejection of claim 1 is incorporated herein.
However, the combination of Tuttle and Lenny does not expressly disclose wherein the status value is coded over a plurality of bits, and wherein each bit indicates that an error occurred during an associated verification step.
Healy discloses a value stored in a register indicates that an error occurred during a verification process
[Healy does not describe in detail the contents of the register or the size of the register (e.g., that the register has a plurality of bits)
all bits of a Healy register indicate that an error occurred when verifying the respective address location corresponding to the register, thereby disclosing wherein the status value is coded, and indicates that an error occurred during an associated verification step.
]
[0026] Memory 104 may further include ECC check bits 107, an ECC controller 108, and an error logging unit 110. The error logging unit may comprise an error address register (EAR) bank 110A and an error count register (ECR) 110B. The EAR bank 110A may be a bank of registers, where each register stores the location of an error detected by the ECC controller 108. For example, the EAR bank 110A may store the row address, the column address, or both the row and column address of a memory cell in which the ECC controller 108 detected an error. The ECR 110B may be a register in which an error count is stored.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Tuttle and Lenny with the teaching that a value stored in a register indicates that an error occurred during a verification process of Healy to include wherein the status value is coded, and indicates that an error occurred during an associated verification step.
One of ordinary skill in the art would have made this modification to improve the ability of the system to store information indicating an error has occurred during a verification process, so that other processes or equipment may access this information, to facilitate recovery from an error. The system of the primary reference can be modified so that information stored in a register can indicate an error occurred during a verification process.
However, the combination of Tuttle, Lenny, and Healy does not expressly disclose wherein the status value is coded over a plurality of bits, and wherein each bit indicates that an error occurred during an associated verification step.
Nutter discloses a register includes a plurality of bits, and the register is at least a predetermined number of bits wide
para. 47 persistent storage register is at least 128 bits wide
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Tuttle, Lenny, and Healy with the teaching that a register includes a plurality of bits, and the register is at least a predetermined number of bits wide of Nutter to include wherein the status value is coded over a plurality of bits, and wherein each bit indicates that an error occurred during an associated verification step.
One of ordinary skill in the art would have made this modification to improve the ability of the system to ensure that a number of bits in the register is sufficient to store error information for quick access. The system of the primary reference can be can be modified so each register is at least a predetermined number of bits wide. By combining the references with Nutter, this discloses all bits of a Healy register indicate that an error occurred when verifying, thereby disclosing wherein the status value is coded over a plurality of bits, and wherein each bit indicates that an error occurred during an associated verification step.
As per claim 4, the rejection of claim 3 is incorporated herein.
Tuttle discloses wherein the boot code is configured to control programming
[particular sequence signal; signals may be sent in a particular sequence to initiate the reboot, para. 29; signal may be an interrupt, para. 29; by sending a signal to control the sequence of operations that discloses control programming]
However, the combination of Tuttle and Lenny does not expressly disclose wherein the boot code is configured, after each verification step, to control programming of a bit associated with that verification step, to a first value when an error has occurred during the verification step.
Healy discloses a value stored in a register indicates that an error occurred during a verification process
[Healy does not describe in detail the contents of the register or the size of the register (e.g., that the register has a plurality of bits)
all bits of a Healy register indicate that an error occurred when verifying the respective address location corresponding to the register, thereby disclosing wherein the boot code is configured, after each verification step, to control programming of a register associated with that verification step, to a first value when an error has occurred during the verification step.
a first value can be the location of the error as disclosed at Healy para. 26
]
[0026] Memory 104 may further include ECC check bits 07, an ECC controller 108, and an error logging unit 110. The error logging unit may comprise an error address register (EAR) bank 110A and an error count register (ECR) 110B. The EAR bank 110A may be a bank of registers, where each register stores the location of an error detected by the ECC controller 108. For example, the EAR bank 110A may store the row address, the column address, or both the row and column address of a memory cell in which the ECC controller 108 detected an error. The ECR 110B may be a register in which an error count is stored.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Tuttle and Lenny with the teaching that a value stored in a register indicates that an error occurred during a verification process of Healy to include wherein the boot code is configured, after each verification step, to control programming of a register associated with that verification step, to a first value when an error has occurred during the verification step.
One of ordinary skill in the art would have made this modification to improve the ability of the system to store information indicating an error has occurred during a verification process, so that other processes or equipment may access this information, to facilitate recovery from an error. The system of the primary reference can be modified so that information stored in a register can indicate an error occurred during a verification process.
However, the combination of Tuttle, Lenny, and Healy does not expressly disclose wherein the boot code is configured, after each verification step, to control programming of a bit associated with that verification step, to a first value when an error has occurred during the verification step.
Nutter discloses a register includes a plurality of bits, and the register is at least a predetermined number of bits wide
para. 47 persistent storage register is at least 128 bits wide
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Tuttle, Lenny, and Healy with the teaching that a register includes a plurality of bits, and the register is at least a predetermined number of bits wide of Nutter to include wherein the boot code is configured, after each verification step, to control programming of a bit associated with that verification step, to a first value when an error has occurred during the verification step.
One of ordinary skill in the art would have made this modification to improve the ability of the system to ensure that a number of bits in the register is sufficient to store error information for quick access. The system of the primary reference can be can be modified so each register is at least a predetermined number of bits wide. By combining the references with Nutter, this discloses all bits of a Healy register indicate that an error occurred when verifying, thereby disclosing wherein the boot code is configured, after each verification step, to control programming of a bit associated with that verification step, to a first value when an error has occurred during the verification step.
Claims 5-8 and 18-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tuttle in view of Lenny, further in view of Guettaf et al. U.S. Publication 20080082879 (hereinafter “Guettaf”).
As per claim 5, the rejection of claim 1 is incorporated herein.
Tuttle discloses
during the execution of the boot code [signals sent in particular sequence to execute the reboot, para. 29]
However, Tuttle does not expressly disclose wherein the register is accessible in read mode via the debugging interface during the execution of the boot code without other locations in the non-volatile memory being accessible via the debugging interface.
Lenny discloses wherein the register [error register 46 and/or status register 44 in Lenny figure 2; 4:58-5:20] is accessible in read mode [the data from the error registers can be read 4:47-51; 4:58-5:20] via the debugging interface [ATA interface 4:34-38; 4:58-5:20; 1:63-2:2]
[See the rejection of claim 1]
For the reasons discussed with respect to claim 1, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Tuttle with the technique for reading boot error data from a register of a storage device via an interface of Lenny to include
wherein the register is accessible in read mode via the debugging interface during the execution of the boot code
However, the combination of Tuttle and Lenny does not expressly disclose wherein the register is accessible in read mode via the debugging interface during the execution of the boot code without other locations in the non-volatile memory being accessible via the debugging interface.
Guettaf discloses specifically disallowing access to portions of memory via a debugging interface
[0031] As a further part of the present innovation in preventing unauthorized users from accessing the internal secure data, and from assessing and learning about the state and/or functionality of the JTAG complaint device, the invention's JTAG boundary scan compliant testing architecture includes partial JTAG disable interface 260. Partial JTAG disable interface 260 can be utilized by an authorized user to prevent an unauthorized user from accessing specified areas of internal secure data, and from assessing and learning about specified areas of the state and/or functionality of the JTAG complaint device.
[ the debugging interface can be considered to be the Guettaf data interface to access the internal secure data]
[claim 5 is now rejected with a new combination of references, which includes a register of a storage device that is non-volatile memory as described in Lenny as cited above. Furthermore, the limitation during the execution of the boot code, under the broadest reasonable interpretation, can include the time from the beginning of a boot process under the boot code until the next boot or shut down of the machine being booted. Until the computer is shut down or rebooted, the entire time that the computer is on may be considered to disclose during the execution of the boot code. This would cover the entire time period for verifying a machine after receiving a signal to initiate a reboot as taught in para. 29 of Tuttle, and would cover verification of its storage device during the boot process as taught in Lenny as cited above. Note also that such a boot code can be disclosed by Lenny, such as the enable/disable drive failure prediction flag (13:47), in which “the host computer 12 checks as to whether drive failure prediction has been enabled as part of the power-on-self-test (or "POST") performed during power-up.” (13:42-46). ]
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Tuttle and Lenny with the technique for specifically disallowing access to portions of memory via a debugging interface of Guettaf to include the wherein the register is accessible in read mode via the debugging interface during the execution of the boot code without other locations in the non-volatile memory being accessible via the debugging interface.
One of ordinary skill in the art would have made this modification to improve the ability of the system to control access to locations in memory storage by preventing access to specified areas of storage. The system of the primary reference can be modified to support disallowing access to specified areas of storage.
As per claim 6, the rejection of claim 5 is incorporated herein.
However, Tuttle does not expressly disclose recovering the status value via the debugging interface; and debugging, by an external device, of the boot sequence based on the recovered status value.
Lenny discloses retrieving the content of a register [reading status register/error register 1:63-2:2 4:34-38; 4:47-51; 4:58-5:20 ] using the debugging interface [4:34-38 (3) storage device 14 is comprised of an AT attachment (or "ATA") interface input/output (or "I/O") registers 18] and performing debugging [identify the actual source of the failure 10:33-34 determine the cause of failure 2:1-2; Comprehensive Test in Off-Line Mode 9:36-38] of the boot sequence [13:44-45] using retrieved contents of the register by an external hardware [micro-controller 19 figure 1 or host computer 12 figure 1, or other tester 1:66-2:2]
1:66-2:2The same interface may be used during post failure analysis where the storage device receives test commands from the tester to determine the cause of a failure.
Lenny 13:44-45 (46) the power-on-self-test (or "POST") performed during power-up.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Tuttle with the technique for retrieving the content of a register using the debugging interface and performing debugging using retrieved contents of the register, and that an external hardware device determine the cause of boot failure using the ATA interface of Lenny to include recovering the status value via the debugging interface; and debugging, by an external device, of the boot sequence based on the recovered status value.
One of ordinary skill in the art would have made this modification to improve the ability of the system to allow for debugging of the boot sequence using an external device by allowing for retrieving the register values from the processor. The system of the primary reference can be modified to allow an external hardware device to access register values through a debugging interface to debug the boot sequence.
As per claim 7, the rejection of claim 6 is incorporated herein.
Tuttle discloses a device checks on the progress of the boot process at para. 35,
[0035] In yet another example of verifying completion of the clearance process, the trusted infrastructure device 150 detects forward progress in the boot sequence (or lack thereof) during the reboot from the trusted portion 120. Determining progress of the boot sequence may be performed by storing the predetermined sequence of operations for the boot sequence, and determining which operations have completed. In an example, the clearance manager 122 may write values to predetermined registers in the memory 126 that indicate performance of the operations.
However, Tuttle does not expressly disclose wherein recovering the status value occurs during the execution of the boot sequence.
Lenny discloses retrieving the content of a register [reading status register/error register 1:63-2:2 4:34-38; 4:47-51; 4:58-5:20] for determine cause of error during boot
Lenny 13:44-45 (46) the power-on-self-test (or "POST") performed during power-up.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Tuttle with the technique for reading a stored value from a register of a device using a debugging interface of Lenny to include wherein recovering the status value occurs during the execution of the boot sequence.
One of ordinary skill in the art would have made this modification to improve the ability of the system to read a value from a register using a debugging interface during the boot sequence, so that the current status of the boot process can be retrieved, to facilitate debugging, monitoring, recovery, or completion of the boot process. The system of the primary reference can be modified to provide a debugging interface to allow for reading a stored value from the register that stores the current boot progress information.
As per claim 8, the rejection of claim 1 is incorporated herein.
Tuttle discloses wherein the processor is in a state during the boot sequence. [signals sent in particular sequence to execute the reboot, para. 29; processors generally change from state to state as they execute instructions]
[0064] In the description above, embodiments and examples are described with reference to acts that are performed by one or more computing systems. If such acts are implemented in software, one or more processors of the associated computing system that performs the act direct the operation of the computing system in response to having executed computer-executable instructions.
However, the combination of Tuttle and Lenny does not expressly disclose wherein the processor is in a closed state during the boot sequence.
Guettaf discloses specifically disallowing access to the processor memory via a debugging interface
[0015] Exemplary semiconductor device 100 also includes a device core 112 that includes the device's internal secure data and performs the basic and essential functions of semiconductor device 100. For example, device core 112 can be a volatile or non-volatile memory array, a processor,
para. 20 Semiconductor device 200 is a "JTAG compliant device"
[0023] As part of the present innovation in preventing unauthorized users from accessing the internal secure data, and from assessing and learning about the state and/or functionality of the JTAG complaint device, the invention's JTAG boundary scan compliant testing architecture of FIG. 2 includes full JTAG disable interface 248. Full JTAG disable interface 248 can be utilized by an authorized user to completely prevent an unauthorized user from accessing the internal secure data, and from assessing and learning about the state and/or functionality of the JTAG complaint device.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Tuttle and Lenny with the technique for disallowing access to processor memory via a debugging interface of Guettaf to include wherein the processor is in a closed state during the boot sequence.
One of ordinary skill in the art would have made this modification to improve the ability of the system to control access to processor memory storage by preventing access. The system of the primary reference can be modified to support disallowing access to processor memory storage.
As per claim 18, the claim(s) is/are directed to a processing device with limitations which correspond to limitations of claim 5, and is/are rejected for the reasons detailed with respect to claim 5.
As per claim 19, the claim(s) is/are directed to a processing device with limitations which correspond to limitations of claim 5, and is/are rejected for the reasons detailed with respect to claim 5.
As per claim 20, the claim(s) is/are directed to a processing device with limitations which correspond to limitations of claim 5, and is/are rejected for the reasons detailed with respect to claim 5.
Claim 9-14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tuttle in view of Lenny, further in view of Cumming et al. U.S. Publication 20120311314 (hereinafter “Cumming”).
As per claim 9, the rejection of claim 1 is incorporated herein.
However, the combination of Tuttle and Lenny does not expressly disclose
wherein performing the at least one verification step comprises performing a verification of an authenticity of one or a plurality of application codes loaded in a first memory location.
Cumming discloses verifying authenticity of the signature, which also includes verifying authenticity of the application code and the software (para. 10). External memory 212 or secondary on-chip memory 210 stores data such as application codes or installation codes (para. 8 and 50)
[because application code is not defined in the specification, under the broadest reasonable interpretation application code can read on a number, some other values or source code; application code can be disclosed by the signature, application code, or software as described in Cumming para. 10.]
[0006] The first on-chip memory 208 is the primary boot memory, storing the primary boot code. The CPU 206 is hard-wired so as, upon start-up or reset of the processor, to automatically begin executing the primary boot code from the primary boot memory 208. When executed, the primary boot code performs the basic initialisation of the processor required to get it up and running.
[0008] Alternatively or additionally, the secondary on-chip memory 210 could be used to store secondary boot code, other applications, and/or data files. The secondary on-chip memory 210 could for example be an EEPROM such as an on-chip flash memory.
.
Cumming [0010] As shown in FIG. 2, the signing process comprises inputting both a private key and the application code into a cryptography function 202, which outputs the code with a cryptographic signature based on the private key. The cryptography function 202 is a one-way function such as a hash function, details of which will be familiar to a person skilled in the art. It is this signed version of the application that is installed on the off-chip memory 212 (or secondary on-ship memory 210). The boot code comprises or has knowledge of the corresponding public key, and is configured to use the public key to verify the authenticity of this signature before allowing the application to be loaded and run on the processor (and to only to do so on condition of the verification). Thus the processor can verify that it is executing software that has been authorised for use on that processor, i.e. originating from a party that holds the private key and is thereby authorised to supply applications for the processor in question (typically the designer or manufacturer of the chip, or an authorised partner of theirs). A similar process could also be used to authenticate data files.
Cumming [0016] According to one aspect of the present invention, there is provided a system comprising: a device comprising a processor and a memory storing boot code arranged to be automatically executed by the processor upon start-up or reset, wherein the boot code comprises a code authentication procedure operable to verify whether additional code is authenticated for execution on the processor;
Cumming [0050] FIG. 3 shows a processor 204 similar to that described in relation to FIG. 2, comprising a CPU 206, and a primary boot memory 208 storing primary boot code. The processor 204 is coupled to an external memory 212 which stores secondary boot code, and other applications and/or data.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Tuttle and Lenny with the technique for verifying authenticity of the signature, which also includes verifying authenticity of the application code and the software of Cumming to include wherein performing the at least one verification step comprises performing a verification of an authenticity of one or a plurality of application codes loaded in a first memory location.
One of ordinary skill in the art would have made this modification to improve the ability of the system to confirm the application has been authorized and not tampered with. The system of the primary reference can be modified to verify the authenticity of a signatures, an application code, or source code stored at any memory location.
As per claim 10, the rejection of claim 1 is incorporated herein.
However, the combination of Tuttle and Lenny does not expressly disclose
wherein performing the at least one verification step comprises performing a verification of an integrity of one or a plurality of application codes loaded in a first memory location.
Cumming discloses verifying authenticity of the signature, which also includes verifying integrity of the signature, application code and the software (para. 10). External memory 212 or secondary on-chip memory 210 stores data such as application codes or installation codes (para. 8 and 50)
[because application code is not defined in the specification, under the broadest reasonable interpretation application code can read on a number, some other values or source code; application code can be disclosed by the signature, application code, or software as described in Cumming para. 10.]
[see rejection of claim 9 for citations]
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Tuttle and Lenny with the technique for verifying authenticity of the signature, which also includes verifying integrity of the signature, application code and the software of Cumming to include wherein performing the at least one verification step comprises performing a verification of an integrity of one or a plurality of application codes loaded in a first memory location.
One of ordinary skill in the art would have made this modification to improve the ability of the system to confirm the application has been authorized and not tampered with. The system of the primary reference can be modified to verify the authenticity/integrity of a signatures, an application code, or source code stored at any memory location.
As per claim 11, the rejection of claim 1 is incorporated herein.
However, the combination of Tuttle and Lenny does not expressly disclose
wherein performing the at least one verification step comprises performing a verification of a format of one or a plurality of application codes loaded in a first memory location.
Cumming discloses verifying authenticity of the signature, which also includes verifying integrity of the signature, application code and the software (para. 10). External memory 212 or secondary on-chip memory 210 stores data such as application codes or installation codes (para. 8 and 50)
[because application code is not defined in the specification, under the broadest reasonable interpretation application code can read on a number, some other values or source code; application code can be disclosed by the signature, application code, or software as described in Cumming para. 10; the format is simply the corresponding format of the signature, application code, or software. this verification confirms that the data, each of which has its own corresponding format, has not been tampered and therefore discloses performing a verification of a format.]
[see rejection of claim 9 for citations]
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Tuttle and Lenny with the technique for verifying authenticity of the signature, which also includes verifying integrity of the signature, application code and the software of Cumming to include wherein performing the at least one verification step comprises performing a verification of a format of one or a plurality of application codes loaded in a first memory location.
One of ordinary skill in the art would have made this modification to improve the ability of the system to confirm the application has been authorized and not tampered with. The system of the primary reference can be modified to verify the authenticity/integrity of a signatures, an application code, or source code stored at any memory location, which would include confirming that the format of the respective data has not been tampered with.
As per claim 12, the rejection of claim 1 is incorporated herein.
However, the combination of Tuttle and Lenny does not expressly disclose
wherein performing the at least one verification step comprises performing a verification of an authenticity of a format of one or a plurality of installation codes or of updates loaded into a second memory location.
Cumming discloses verifying authenticity of the signature, which also includes verifying integrity of the signature, application code and the software (para. 10). External memory 212 or secondary on-chip memory 210 stores data such as application codes or installation codes (para. 8 and 50)
[because installation codes is not defined in the specification, under the broadest reasonable interpretation installation codes can read on numbers, some other values or source code; one or a plurality of installation codes can be disclosed by the signature, application code, or software as described in Cumming para. 10; a second memory location can be disclosed by secondary