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 .
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Claim Rejections - 35 USC § 102
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.
Claims 1-6 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by US 20110035808 to Butler et al. (hereinafter Butler).
Regarding claim 1, Butler teaches,
A computer system comprising
a processor in communication with a memory structure; ([0068] teaches the processor in communication with disk and memory. Abstract, teaches Rootkit-resistant disks (RRD) label all immutable system binaries and configuration files at installation time. To upgrade, the host is booted into a safe state and system blocks can only be modified if a security token is attached to the disk controller. Thus, immutability (read-only) is enforced on all configurations / boot code, unless a token is provided to allow for updating / modification.)
the processor retrieving and executing executable code stored in the memory structure thereby to process data stored in and retrieved from the memory structure; ([0023] teaches the RRD protect all portions of the boot process that use immutable code or data, including the master boot record (MBR). See also, Abstract.)
the memory structure including at least an area designated as an executable application code storage area and a separate area designated as a data storage area; ([0040] teaches only using tokens to allow for installations / modifications to boot / configuration files, while not enforcing / forcing the use of tokens for changes to files such as documents in the user's home directory. Similarly, [0015] teaches RRD intermixes mutable and immutable data on same drive, and allows upgrading and patching. See also [0059-60] teaching immutable and mutable blocks of data.)
structuring computer hardware and firmware on a computing platform of the computer system (fig. 2 teaches structure of disk RRD. [0023] teaches BIOS / “firmware”, and [0043] teaches protecting BIOS. [0057] teaches BIOS loading at boot time.) so as to test certain aspects of a block of code and the environment in which it is located prior to a binary loader of the computing platform loading and executing the block of code. (Abstract, teaches enforcing immutability at the disk controller, which is before boot loading. [0057-58] teach RRD being loaded at boot time. [0059-60] teach how the MBR, boot loader, kernel and any kernel modules must be immutable to prevent overwriting by kernel level rootkits, and that booting is performed. Abstract, teaches that system blocks may only be modified if the security token is attached)
Regarding claim 2, Butler teaches,
The computer system of claim 1
wherein in instances where the block of code fails one or more of the tests then the block of code is not loaded and/or is not executed by the binary loader. ([0082-83] teaches the failure of the rootkit to update the disk due to the RRD. Abstract, teaches the RRD enforces immutability at the disk, and prevents infection / compromise of operating system. [0015] teaches the RRD enforcing the immutability of some, but not all data.)
Regarding claim 3, Butler teaches,
A method of operating a computer system; the computer system comprising
a processor in communication with a memory structure;
the processor retrieving and executing executable code stored in the memory structure thereby to process data stored in and retrieved from the memory structure;
the memory structure including at least an area designated as an executable application code storage area and a separate area designated as a data storage area;
the method comprising structuring computer hardware and firmware on a computing platform of the computer system so as to test certain aspects of a block of code and the environment in which it is located prior to a binary loader of the computing platform loading and executing the block of code.
Claim 3 is rejected using the same basis of arguments used to reject claim 1 above.
Regarding claim 4, Butler teaches,
The method of claim 3 wherein in instances where the block of code fails one or more of the tests then the block of code is not loaded and/or is not executed by the binary loader.
Claim 4 is rejected using the same basis of arguments used to reject claim 2 above.
Regarding claim 5, Butler teaches,
A computer system comprising
a processor in communication with a memory structure;
the processor retrieving and executing executable code stored in the memory structure thereby to process data stored in and retrieved from the memory structure;
the memory structure including at least an area designated as an executable application code storage area and a separate area designated as a data storage area.
Claim 5 is rejected using the same basis of arguments used to reject claim 1 above.
Regarding claim 6, Butler teaches,
The system of claim 5 wherein the executable application code storage area is switchable by a memory state switch structure between at least a first state and a second state; (fig. 2, teaches physical token. Abstract, teaches that system blocks may only be modified if the security token is attached.)
whereby in the first state the memory in the executable application code storage area is read enabled and write enabled; ([0015] teaches intermixing immutable (read only) with mutable (read/write) data. See also, [0058-61] for additional teaching regarding boot code being immutable while user documents are mutable.)
whereby in the second state the memory in the executable application code storage area is read enabled and write disabled. ([0015] teaches intermixing immutable (read only) with mutable (read/write) data. See also, [0058-61] for additional teaching regarding boot code being immutable while user documents are mutable.)
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRIAN WILLIAM AVERY whose telephone number is (571) 272-3942. The examiner can normally be reached on 9AM-5PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Farid Homayounmehr can be reached on (571) 272-3739.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/B.W.A./
/FARID HOMAYOUNMEHR/Supervisory Patent Examiner, Art Unit 2495