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 communications filed on 4/15/2025.
Claims 1-21 are pending.
DETAILED ACTION
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 3-4, 9-11, and 14-15 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 applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claims 3-4, 9-11, and 14-15, the limitations recite the term “secure”. The term “secure” in claims 3-4, 9-11, and 14-15 is a relative term which renders the claim indefinite. The term “secure” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention.
For examination purposes, the “secure boot” ROM of claim 3 (and consequently on claims 4 and 9-10) and claim 14 (and consequently, claim 15) is interpreted as a boot ROM, and the “secure boot loader” of claims 4 and 15 is interpreted as a boot loader.
Claim Rejections - 35 USC § 102
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 (i.e., changing from AIA to pre-AIA ) 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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-7, 9, 11, 16-17, 19, and 21 is/are rejected under 35 U.S.C. 102(A)(1) as being anticipated by Mahatme et al. (US 10529400 B1, hereinafter Mahatme).
Regarding claim 1, Mahatme discloses a system on chip (col. 6, lines 1-2, "FIG. 5 illustrates a data processing system 200 (also referred to as a system on a chip (SoC))"), comprising:
a non-volatile memory storing operating system related static content for the system on chip (col. 6, lines 46-48, "MRAM 100 is within an SoC (such as system 200) and used as non-volatile static random access memory (SRAM)"; col. 8, lines 3-16, when MRAM is cleared, the system is defaulted to a ROM bootloader indicating MRAM stores operating system related information);
a corruption detection module determining whether the non-volatile memory has been corrupted (col. 8, lines 3-16, "BIST resumes checking MRAM 100, in which the contents of MRAM are checked by MBIST and control logic 212. For example, this may be done with a checksum, as known in the art. If the MRAM data is corrupted and cannot be corrected with error correction code (ECC), the contents of MRAM 100 are cleared"); and
a hard coded memory including a recovery routine operable to retrieve a recovery image stored on an alternate storage system and load the recovery image to the non-volatile memory (col. 8, lines 3-16, "Upon doing so, system 200 is defaulted to a ROM bootloader (stored, e.g., in ROM 208) since the contents of MRAM 100 are cleared. Method 230 proceeds to decision diamond 262 where it is determined if system 200 is connected to a cloud. If so, at block 266, the contents of MRAM 100 are reloaded from the cloud and new code execution from MRAM 100 may be resumed, now with the correct contents of MRAM 100" ).
Regarding claim 2, Mahatme discloses the system of claim 1, wherein the non-volatile memory is magneto-resistive random access memory (col. 1, line 15, "Magnetic Random Access Memories (MRAMs)" - which is another name for magneto-resistive random access memory).
Regarding claim 3, Mahatme discloses the system of claim 1, further comprising a controller coupled to the non-volatile memory, and wherein the recovery routine is a part of a secure boot read only memory (ROM) operable to boot the controller (Fig. 5, and col. 8, lines 3-16, "Upon doing so, system 200 is defaulted to a ROM bootloader (stored, e.g., in ROM 208) since the contents of MRAM 100 are cleared. Method 230 proceeds to decision diamond 262 where it is determined if system 200 is connected to a cloud. If so, at block 266, the contents of MRAM 100 are reloaded from the cloud and new code execution from MRAM 100 may be resumed, now with the correct contents of MRAM 100" ).
Regarding claim 4, Mahatme discloses the system of claim 3, wherein the recovery routine includes a first stage executed during execution of the secure boot ROM and a second stage executed during execution of a secure boot loader operable to load an operating system for the controller (col. 8, lines 3-16, "Upon doing so, system 200 is defaulted to a ROM bootloader (stored, e.g., in ROM 208)" (first stage); col. 8, lines 3-16, "Method 230 proceeds to decision diamond 262 where it is determined if system 200 is connected to a cloud. If so, at block 266, the contents of MRAM 100 are reloaded from the cloud" (second stage); col. 8, lines 16-20, "new code execution from MRAM 100 may be resumed, now with the correct contents of MRAM 100. Method 230 then returns to block 252 in which system 200 operates in normal mode. If not connected to a cloud, then, at block 264, operation of system 200 proceeds but with reduced functionality due to the lack of data in MRAM 100" (i.e., the code is an operating system)).
Regarding claim 5, Mahatme discloses the system of claim 1, further comprising a processing routine operable to determine whether a source of corruption is present, and wherein the recovery routine is executed when the source of corruption is no longer present (col. 6, lines 18-19, "a magnetic field becomes problematic and threatens the data stored in the main arrays of MRAM 100"; col. 7, lines 55-65, "When a polling of the canary bits indicates a canary error (in which one or more canary bits does not match the expected state), a magnetic field is indicated at block 254. Upon a magnetic field being present, in block 256, a magnetic field present flag, MagFieldPresent (MFP), is set to a logic level 1. With the magnetic field present, code execution from MRAM 100 is halted while polling of the canary bits continue. The polling is continued until the BIST indicates there is no longer a canary error. At this point, at block 258 a magnetic field is no longer present"; col. 8, lines 1-2, "With the magnetic field no longer present, in block 260, recovery operations are performed").
Regarding claim 6, Mahatme discloses the system of claim 1, further comprising an external device interface, and wherein the alternate storage system includes a flash memory or an embedded multimedia card in communication with the external device interface (col. 7, lines 27-28, "For example, the contents of MRAM 100 are reloaded from an external flash" (external device interface inherent)).
Regarding claim 7, Mahatme discloses the system of claim 1, further comprising an interface in communication with an external host processor, wherein the external host processor accesses the alternate storage system through a wireless interface or a wired interface (col. 8, lines 3-16, "Upon doing so, system 200 is defaulted to a ROM bootloader (stored, e.g., in ROM 208) since the contents of MRAM 100 are cleared. Method 230 proceeds to decision diamond 262 where it is determined if system 200 is connected to a cloud. If so, at block 266, the contents of MRAM 100 are reloaded from the cloud and new code execution from MRAM 100 may be resumed, now with the correct contents of MRAM 100" - all elements implied, as a cloud needs a processor to function, an storage accessible by the cloud to store the contents, where the access must be either wired or wireless as no other alternatives exist, and an interface to communicate to the cloud is necessary).
Regarding claim 9, Mahatme discloses the system of claim 3, wherein the recovery image is executed by the controller to retrieve the static contents on a back up storage device for restoration of the non-volatile memory (col. 8, lines 3-16, "Upon doing so, system 200 is defaulted to a ROM bootloader (stored, e.g., in ROM 208) since the contents of MRAM 100 are cleared. Method 230 proceeds to decision diamond 262 where it is determined if system 200 is connected to a cloud. If so, at block 266, the contents of MRAM 100 are reloaded from the cloud and new code execution from MRAM 100 may be resumed, now with the correct contents of MRAM 100" ).
Regarding claim 11, Mahatme discloses the system of claim 9, further comprising a one time programmable device storing configuration data for the recovery routine (col. 8, lines 3-16, "ROM").
Regarding claim 16, Mahatme discloses the system of claim 1, wherein the corruption detection module includes a routine to authenticate the non-volatile memory, and wherein corruption is detected on failure of the authentication (col. 8, lines 1-8, "With the magnetic field no longer present, in block 260, recovery operations are performed. The MFP flag is reset or cleared to a logic level 0. BIST resumes checking MRAM 100, in which the contents of MRAM are checked by MBIST and control logic 212. For example, this may be done with a checksum, as known in the art. If the MRAM data is corrupted and cannot be corrected with error correction code (ECC), the contents of MRAM 100 are cleared" - checksum is akin to authentication of the memory contents).
Regarding claim 17, Mahatme discloses the system of claim 1, wherein the corruption detection module includes a periodic routine to perform an integrity check on the static contents of the non-volatile memory, and wherein corruption is detected on failure of the integrity check (col. 6, lines 50-54, "the contents of the canary bits of MRAM 100 and the BIST status (provided by, e.g., MBIST and control logic 212), with periodic polling. For example, core 202 or MBIST and control logic 212 itself can periodically poll for this information"; col. 6, line 66 to col. 7, line 10, "Periodically, these canary bit are polled (e.g. read) and compared with the predetermined values. Upon any read, if any one of the canary bits does not match the expected predetermined value, it is assumed that the canary bits are being affected by a magnetic field. However, since the canary bitcells are smaller than the regular MRAM array bitcells, the regular MRAM array bitcells may or may not yet affected by the magnetic field. Therefore, upon any periodic poll in which the canary bits are read, an indication that a canary bit does not match provides an indication of impending data loss of the main MRAM arrays or an actual corruption of some of the data in the MRAM array").
Regarding claim 19, Mahatme discloses the system of claim 1, wherein the corruption detection module includes a routine to detect corruption upon a hard fault or a watch dog time out (col. 8, lines 1-8, "With the magnetic field no longer present, in block 260, recovery operations are performed. The MFP flag is reset or cleared to a logic level 0. BIST resumes checking MRAM 100, in which the contents of MRAM are checked by MBIST and control logic 212. For example, this may be done with a checksum, as known in the art. If the MRAM data is corrupted and cannot be corrected with error correction code (ECC), the contents of MRAM 100 are cleared" (detect corruption); col. 7, lines 55-64, "When a polling of the canary bits indicates a canary error (in which one or more canary bits does not match the expected state), a magnetic field is indicated at block 254. Upon a magnetic field being present, in block 256, a magnetic field present flag, MagFieldPresent (MFP), is set to a logic level 1. With the magnetic field present, code execution from MRAM 100 is halted while polling of the canary bits continue. The polling is continued until the BIST indicates there is no longer a canary error" (upon a hard fault)).
Regarding claim 21, Mahatme discloses a method of recovering a non-volatile memory storing static content for operating a system on chip (col. 6, lines 46-48, "MRAM 100 is within an SoC (such as system 200) and used as non-volatile static random access memory (SRAM)"; col. 8, lines 3-16, when MRAM is cleared, the system is defaulted to a ROM bootloader indicating MRAM stores operating system related information), the method comprising:
storing a recovery image stored on an alternate storage system (col. 8, lines 3-16, "Upon doing so, system 200 is defaulted to a ROM bootloader (stored, e.g., in ROM 208) since the contents of MRAM 100 are cleared. Method 230 proceeds to decision diamond 262 where it is determined if system 200 is connected to a cloud. If so, at block 266, the contents of MRAM 100 are reloaded from the cloud and new code execution from MRAM 100 may be resumed, now with the correct contents of MRAM 100" );
determining whether the non-volatile memory has been corrupted (col. 8, lines 3-16, "BIST resumes checking MRAM 100, in which the contents of MRAM are checked by MBIST and control logic 212. For example, this may be done with a checksum, as known in the art. If the MRAM data is corrupted and cannot be corrected with error correction code (ECC), the contents of MRAM 100 are cleared"); and
on determining corruption of the non-volatile memory, executing a recovery routine to access the recovery image from the alternate storage system and load the recovery image to the non-volatile memory (col. 8, lines 3-16, "Upon doing so, system 200 is defaulted to a ROM bootloader (stored, e.g., in ROM 208) since the contents of MRAM 100 are cleared. Method 230 proceeds to decision diamond 262 where it is determined if system 200 is connected to a cloud. If so, at block 266, the contents of MRAM 100 are reloaded from the cloud and new code execution from MRAM 100 may be resumed, now with the correct contents of MRAM 100" ).
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) 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mahatme (US 10529400 B1) in view of KB et al. (US 20250200186 A1, hereinafter KB).
Regarding claim 8, Mahatme discloses the system of claim 1.
Mahatme does not disclose that the recovery routine is operable to validate the retrieved recovery image.
KB discloses the recovery routine is operable to validate the retrieved recovery image (¶[0014], "a mobile device management (MDM) system provides enhanced security functionality for bootable media images and their use during remote device installations, such as a bare-metal restore (e.g., a fresh operating system installation) of a corrupted computing device. An end user interacts with an MDM server to rebuild the corrupted device (a ‘recovery device’) using another computing device to which they have access (a ‘support device’), as well as an external memory device such as a USB disk"; ¶[0019], "the MDM system provides both an integrity check during OS install (e.g., on the recovery device) as well as a server-side integrity verification (e.g., at the MDM server) to verify that no tampering with the bootable media image has occurred"; ¶[0026], "support device 106 creates the bootable media image 110 by writing the OS data 134 and the MDM enrollment metadata 136 to the external disk 108. In some examples, the OS data 134 may be a bootable image (e.g., may include a bootloader that is written to a boot sector on the external disk 108 and that is configured to start a boot process allowing an installation of a new operating system using the OS data 134). In the example, the support device 106 writes an orchestrator program 112 to the external disk 108 and the bootloader is included with the orchestrator program 112. This orchestrator program 112 can be configured to perform additional operations during a boot from the external disk 108 as described below (e.g., local image integrity validation)").
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to combine the teachings of Mahatme and KB to arrive at a system in which the recovery routine is operable to validate the retrieved recovery image.
One of ordinary skill in the art would have been motivated because it would prevent "insertion of malicious content (e.g., malware) into the bootable media image or other modification of the operating system to expose a vulnerability" (KB, ¶[0003]).
Claim(s) 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mahatme (US 10529400 B1) in view of Kang (US 20200167096 A1).
Regarding claim 10, Mahatme discloses the system of claim 9.
Mahatme does not disclose that a boot routine on the secure boot ROM is resumed after the recovery image is executed by the controller.
However, the combination of Kang with Mahatme suggests that a boot routine on the secure boot ROM is resumed after the recovery image is executed by the controller (Kang, ¶[0046], "storage device 100 may operate as the storage medium of the electronic apparatus 10. The storage device 100 may include a non-transitory machine-readable storage medium. The storage device 100 may be configured by using any one of various types of nonvolatile memory devices such as a NAND flash memory device, a NOR flash memory device, a ferroelectric random access memory (FRAM) using a ferroelectric capacitor, a magnetic random access memory (MRAM)"; ¶[0062], "the electronic apparatus 10 reads out a bootloader from a read only memory (ROM) (not illustrated), and loads the bootloader in the memory 240. The electronic apparatus 10 may complete the boot-up process by reading out code type instructions from the storage device 100 and loading the code type instructions in the memory 240, using the bootloader" - since these steps are performed using a good image of storage 100, the combination of Mahatme and Kang suggests that the steps may only be completed after performing the recovery of Mahatme if storage 100 is corrupted).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to combine the teachings of Mahatme and Kang to arrive at a system in which a boot routine on the secure boot ROM is resumed after the recovery image is executed by the controller.
One of ordinary skill in the art would have been motivated because it would eliminate problems during a boot routine.
Claim(s) 13 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mahatme (US 10529400 B1) in view of Bangalore Lakshman et al. (US 20210090680 A1, hereinafter Bangalore).
Regarding claim 13, Mahatme discloses the system of claim 1.
Mahatme does not disclose that the recovery routine is operable to report a status of recovery to an external host processor and wherein the status of recovery is stored through a device register on a controller or communicated to an external host processor using a general purpose input/output (GPIO) pin.
Bangalore discloses that the recovery routine is operable to report a status of recovery to an external host processor and wherein the status of recovery is stored through a device register on a controller or communicated to an external host processor using a general purpose input/output (GPIO) pin (Fig. 5, a host connected to a memory device; ¶[0003], "magnetic RAM (MRAM)"; ¶[0147], "the imprint detection component 560 may signal a presence or prediction of imprint in a memory array 555 to the host device 510, which may indicate or be otherwise interpreted as a request that the host device 510 initiate a recovery operation, a request that the host device 510 approve a recovery operation (e.g., signaling approval for the imprint recovery component 565 to proceed with imprint recovery), an indication that the memory device 540 will be or is undergoing a recovery operation, an indication that the memory device 540 may or will be temporarily unavailable for access operations, or may be available for access operations at a reduced rate or performance, and other interpretations"; ¶[0174], "a full array recovery may be triggered or initiated by a boot sequence imprint monitor or other functional failure (e.g., a boot failure, a blue screen event, a high severity imprint monitor failure)" - note all known processors require registers to store a current instruction).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to combine the teachings of Mahatme and Bangalore to arrive at a system in which the recovery routine is operable to report a status of recovery to an external host processor and wherein the status of recovery is stored through a device register on a controller or communicated to an external host processor using a general purpose input/output (GPIO) pin.
One of ordinary skill in the art would have been motivated because it would enable a user to know that the memory device may not be performing as expected.
Regarding claim 20, Mahatme discloses the system of claim 1.
Mahatme does not disclose an interface coupled to an external host processor operable to provide an alert when corruption is detected.
Bangalore Lakshman discloses an interface coupled to an external host processor operable to provide an alert when corruption is detected (Fig. 5, a host connected to a memory device; ¶[0003], "magnetic RAM (MRAM)"; ¶[0147], "the imprint detection component 560 may signal a presence or prediction of imprint in a memory array 555 to the host device 510, which may indicate or be otherwise interpreted as a request that the host device 510 initiate a recovery operation, a request that the host device 510 approve a recovery operation (e.g., signaling approval for the imprint recovery component 565 to proceed with imprint recovery), an indication that the memory device 540 will be or is undergoing a recovery operation, an indication that the memory device 540 may or will be temporarily unavailable for access operations, or may be available for access operations at a reduced rate or performance, and other interpretations"; ¶[0174], "a full array recovery may be triggered or initiated by a boot sequence imprint monitor or other functional failure (e.g., a boot failure, a blue screen event, a high severity imprint monitor failure)").
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to combine the teachings of Mahatme and Bangalore Lakshman to arrive at a system in which an interface coupled to an external host processor is operable to provide an alert when corruption is detected.
One of ordinary skill in the art would have been motivated because it would enable a user to know that the memory device may not be performing as expected.
Claim(s) 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mahatme (US 10529400 B1) in view of Bailey et al. (US 20080235501 A1, hereinafter Bailey).
Regarding claim 14, Mahatme discloses the system of claim 1, further comprising a controller coupled to the non-volatile memory (Fig. 5).
Mahatme does not disclose that the corruption detection module is a part of a secure boot read only memory (ROM) operable to boot the controller.
Bailey discloses that a corruption detection module may be a part of a secure boot read only memory (ROM) operable to boot the controller (Bailey, ¶[0039], "it is determined whether the signature word is in proper form, i.e., is good. For example, the signature word, e.g., the first word, from NV memory 24 may be compared to an expected value"; ¶[0040], "If at act S204 the determination is NO, i.e., the signature word is not in proper form, then the firmware in NV memory 24 is deemed to be corrupted, and the process proceeds to act S214. In other words, if the values do not match, then NV memory 24 is determined to be corrupted, and the boot loader code of boot ROM module 40 will retain control and begin execution of firmware load recovery routines beginning at act S214"; ¶[0043], "boot ROM module 40 performs a checksum computation on the firmware downloaded to volatile memory 26, e.g., DRAM, to compute a checksum. In other words, the checksum is calculated by hardware unit 18 (e.g., the ASIC), and more particularly by boot ROM module 40 in the present embodiment, during the download of the firmware from NV memory 24 to volatile memory 26"; ¶[0044], "it is determined whether the checksum is good, i.e., has not failed the checksum test. In other words, the checksum is compared to an expected value").
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to combine the teachings of Mahatme and Bailey to arrive at a system in which the corruption detection module is a part of a secure boot read only memory (ROM) operable to boot the controller.
One of ordinary skill in the art would have been motivated because it would prevent operational errors by catching the errors before corrupted code is executed.
Claim(s) 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mahatme (US 10529400 B1) in view of Bailey (US 20080235501 A1), and further in view of Le et al. (US 20140281464 A1, hereinafter Le).
Regarding claim 15, the combined teachings of Mahatme and Bailey disclose the invention substantially as applied to claim 14, above, wherein determining the non-volatile memory has been corrupted includes the secure boot ROM determining a failure to authenticate a program (Bailey, ¶[0039], "it is determined whether the signature word is in proper form, i.e., is good. For example, the signature word, e.g., the first word, from NV memory 24 may be compared to an expected value"; ¶[0040], "If at act S204 the determination is NO, i.e., the signature word is not in proper form, then the firmware in NV memory 24 is deemed to be corrupted, and the process proceeds to act S214. In other words, if the values do not match, then NV memory 24 is determined to be corrupted, and the boot loader code of boot ROM module 40 will retain control and begin execution of firmware load recovery routines beginning at act S214"; ¶[0043], "boot ROM module 40 performs a checksum computation on the firmware downloaded to volatile memory 26, e.g., DRAM, to compute a checksum. In other words, the checksum is calculated by hardware unit 18 (e.g., the ASIC), and more particularly by boot ROM module 40 in the present embodiment, during the download of the firmware from NV memory 24 to volatile memory 26"; ¶[0044], "it is determined whether the checksum is good, i.e., has not failed the checksum test. In other words, the checksum is compared to an expected value").
The combined teachings of Mahatme and Bailey do not explicitly disclose that the program is a secure boot loader.
Le discloses a secure boot loader (claim 1, "A method of booting a system on chip (SoC) comprising: using an on-chip MRAM located in the SoC, storing a boot software including start-up software, boot loaders, and kernel and user-personalized information in an on-chip magnetic random access memory (MRAM) located in and residing on the same semiconductor as the SoC").
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to combine the teachings of Mahatme and Bailey to arrive at a system in which a secure boot loader is stored in the MRAM.
One of ordinary skill in the art would have been motivated because it would improve the speed at which software is loaded (Le, suggested, ¶¶[0014]-[0016]).
Allowable Subject Matter
Claims 12 and 18 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.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
US 20190087273 A1, which discloses "facilitate recovery from a condition caused by a corrupted memory location" (¶[0047]); and "LD 310 may be hard coded to write to the memory area using a loop when it receives the indication to perform the recovery operation" (¶[0054]).
US 8006125 B1, which discloses "block 618 may build a new boot code using data in the active partition for example by copying a hard coded version of the boot code from the storage media containing the recovery tool 300, at block 620. By way of example not limitation, the hard coded version of the boot code may be stored on an insertable or networked media, a secondary hard drive on the computer system 110, or in the cases where valid partitions are found on the hard disk 141, on a separate partition. The boot code may also be stored on certain reserved, hidden, or any available sectors on the disk" (col. 11, lines 54-63).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BORIS D GRIJALVA LOBOS whose telephone number is (571)272-0767. The examiner can normally be reached M-F 10:30AM to 6:30PM EST.
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, Jorge L Ortiz-Criado can be reached at 571-272-7624. 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.
/BORIS D GRIJALVA LOBOS/ Primary Patent Examiner, Art Unit 2496
Prosecution Insights