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 .
Foreign Priority
Acknowledgment is made of applicant's claim for foreign priority based on an application filed in China on 05/29/2024. It is noted, however, that applicant has not filed a certified copy of the CN2024106834072 application as required by 37 CFR 1.55.
Claim Objections
Claim 5 and 6 are objected to because of the following informalities:
Regarding Claim 5, the claim recites that a header containing “a state, signature, version, payload length, and cyclic redundancy check and a state of a respective record” (emphasis added). The claim recites the limitation of the header containing “a state” twice.
Regarding Claim 6, lines 1-2 recite “wherein the state comprises the status of a corresponding record.” However, this limitation is already recited in claim 5 lines 3-4, on which claim 6 depends. Therefore, this limitation is redundant.
Appropriate correction is required.
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.
Claim 9, 15, and 18 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 Claim 9, lines 1-2 recite “wherein the state transitions between bit states 0 and 1 upon logging a repetitive abnormal operation.” However, claims 5 and 6, on which claim 9 depends, recite that the state is stored a record header for each record stored in the non-volatile memory. As established in instant app. par. 61, “any change of a bit from 1 to 0 does not require a need to erase the sector, however a change from 0 back to 1 does require the entire sector to be erased” (also supported by Stack Overflow pg. 2, “you can always turn a 1 into a 0, but not a 0 to a 1 without erasing”). Applicant appears to be referencing a state machine, which is separate from the records stored in flash, according to instant application par. 42, “before logging failures, the system checks the last record state using finite state machine” (emphasis added). It’s unclear whether the claim refers to the state field of the previous claim or the state machine.
For the purpose of compact prosecution, the claim will utilize the definition of “state” set forth in claims 5 and 6, in which the state refers to a state field.
Regarding Claims 15 and 18, the claims recite similar limitations to claim 9 regarding wording for transitioning a state in the case of duplicate records. These claims are equally ambiguous to the formatting and utilization of the “state”, as it could refer to a field in the header or a separate status in a state machine stored elsewhere due to the reasons cited above. For the purpose of compact prosecution, the claim will utilize the definition of “state” set forth in claim 14, in which the state refers to a state field.
Appropriate clarification or correction is required.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (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 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 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.
Claims 1-4 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Byom et. al. (US 2012/0054541 A1) in view of Chandrasekaran (US 2022/0261306 A1).
Regarding Claim 1, Byom discloses a method for logging boot and abnormal operations in an embedded system having […] memory partitioned into a startup log partition and an abnormal operation log partition (Byom par. 13, electronic device 100 can include system-on-a-chip (“SoC”) 110, non-volatile memory (“NVM”) 120, and volatile memory 114; also see par. 14, NVM 120 can be organized into “blocks”, which is the smallest erasable unit, and further organized into “pages”, which can be the smallest unit that can be programmed or read and par. 38, NVM interface can store the one or more error notifications in an error log 234, which can be implemented as a scratch memory buffer and/or a reserved random-access memory area in memory 214 [i.e., abnormal operation log partition]; and FIG. 2, bootloader 230 [i.e., startup log partition, see instant app. par. 48, startup log includes the core bus of the boot loader] and error log 234 [i.e., abnormal operation log partition]), comprising:
executing a boot loader process to execute boot code to start up the embedded system (Byom par. 25, a bootloader may be loaded from NVM 120 to memory 114; also see Byom par. 37, bootloader 230 may be configured to load the operating system and associated data into memory 214 [note: par. 34, memory 214 may be the same as or similar to memory 114 (FIG. 1). NVM 220 may be the same as or similar to NVM 120 (FIG. 1)]);
[…];
storing abnormal event records in the abnormal operation log partition for any abnormal events encountered during the start up (Byom par. 36, in order to prevent firmware failure and avoid data loss, NVM interface 116 can be configured to detect errors and maintain an error log during device bootup; and Byom par. 38, the NVM interface may detect one or more errors 250 in NVM 220 (e.g., one or more errors in the firmware that is being read from NVM 220)… upon detecting such an error, the NVM interface can store one or more error notifications (e.g., refresh notifications or uECC notifications) in a portion of memory 214.).
Byom does not explicitly teach:
a non-volatile memory partitioned into a startup log partition and an abnormal operation log partition;
storing boot event records of the boot loader process in the startup log partition;
In the analogous art of securely booting operating systems, Chandrasekaran teaches:
a non-volatile memory partitioned into a startup log partition and an abnormal operation log partition (Chandrasekaran par. 43, memory 104 may be non-volatile memory (e.g., flash memory, hard disk drives, solid state drives, compact discs (CDs), digital video discs (DVDs), and/or tape storage); and Chandrasekaran FIG. 7, applications 702 [stored in memory 104, see FIG. 1] contain log files 704 [i.e., startup log partition, see par 119 "log files 704 may be a boot log"] and database entries 710 [i.e., abnormal operation log partition, see par. 122, database entries 710 may explicitly indicate errors]);
storing boot event records of the boot loader process in the startup log partition (Chandrasekaran par. 119, log files 704 may be, for example, one or more system level log files, such as a syslog, event log, authentication log, kernel log, boot log, scheduled job (e.g., cron) log… each of log files 704 consists of a time-ordered series of entries (e.g., text strings) written in accordance to a pre-established format [i.e., a boot log is a format for storing boot records]);
Therefore, it would have been obvious of one of ordinary skill in the art, having the teachings of Byom and Chandrasekaran before him, before the effective filing date of the claimed invention, to combine Byom’s method of logging boot errors with Chandrasekaran’s storing of boot logs and boot error logs in a non-volatile memory, the motivation being to use persistent storage for the purpose of identifying and correcting errors applications run on the system (Chandrasekaran par. 117).
Regarding Claim 2, Byom in view of Chandrasekaran discloses the method of claim 1 wherein the boot loader initializes system hardware and loads an operating system into memory (Byom par. 37, bootloader 230 may be configured to load the operating system and associated data into memory 214).
Regarding Claim 3, Byom in view of Chandrasekaran discloses the method of claim 2 wherein the system hardware includes one or more peripheral devices used by the embedded system, and coupled to the embedded system through respective logical and physical interfaces (Chandrasekaran par. 41, computing device 100 may include other components and/or peripheral devices (e.g., detachable storage, printers, and so on); and par. 47, input/output unit 108 may facilitate user and peripheral device interaction with computing device 100; also see Byom par. 37, bootloader is loaded by NVM interface to read the operating system, the kernel, and the firmware [i.e., firmware is device software that provides low-level control for a device specific hardware i.e., peripherals]).
Regarding Claim 4, Byom in view of Chandrasekaran discloses the method of claim 3 wherein the abnormal events comprise at least one of a failure of a peripheral device, a failure of a logical or physical interface, or a failure of hardware or software performing the start up (Byom par. 26, some errors may be non-fatal errors (e.g., indicated by the issuance one or more refresh notifications), while other may be fatal errors (e.g., indicated by the issuance of one or more uncorrectable error correction coding (“uECC”) notifications; and Byom par. 30, device 100 may continue to operate until the firmware fails to load (e.g., due to one or more fatal errors) [i.e., failure of hardware or software performing the start up]; also see Chandrasekaran par. 111, errors include instability (e.g., crashes, freezes) [i.e., failure of software]).
Regarding Claim 12, Byom discloses a system for storing boot logs in […] memory of an embedded system (Byom par. 4, systems and methods are provided for handling errors during device bootup from a non-volatile memory), comprising:
a boot loader component executing boot code using a processor of the embedded system to initialize system hardware and load an operating system into memory (Byom par. 25, a bootloader may be loaded from NVM 120 to memory 114; also see Byom par. 37, bootloader 230 may be configured to load the operating system and associated data into memory 214 [note: par. 34, memory 214 may be the same as or similar to memory 114 (FIG. 1). NVM 220 may be the same as or similar to NVM 120 (FIG. 1)]);
a non-volatile memory storing the boot code (Byom par. 25, a bootloader may be loaded from NVM 120 [i.e., bootloader with boot code stored in non-volatile memory NVM 120]), […], and a second region storing blocks for operation failure records (Byom par. 38, NVM interface can store the one or more error notifications in an error log 234, which can be implemented as a scratch memory buffer and/or a reserved random-access memory area in memory 214 [i.e., abnormal operation log partition]); and
an interface to transmit the boot event records and operation failure records to a user for system review purposes (Byom par. 54, a determination can be made if one or more fatal errors were detected during the device bootup… NVM driver can determine if the error log includes one or more uECC notifications [note: uECC errors i.e., uncorrectable ECC errors see par. 23, cannot be fixed automatically, i.e., require a user to review]; and par. 55, the NVM driver can retire one or more blocks associated with the fatal errors [i.e., records are provided to NVM driver for improvement]; also see par. 33, in order to prevent firmware failure and avoid data loss [due to losing records, see par. 31], NVM interface 116 can be configured to detect errors and maintain an error log during device bootup).
Byom does not explicitly disclose:
a system for storing boot logs in non-volatile memory of an embedded system;
a non-volatile memory storing the boot code, and comprising a first region storing blocks for boot event records;
In the analogous art of securely booting operating systems, Chandrasekaran teaches:
a system for storing boot logs in non-volatile memory of an embedded system (Chandrasekaran par. 43, memory 104 may be non-volatile memory (e.g., flash memory, hard disk drives, solid state drives, compact discs (CDs), digital video discs (DVDs), and/or tape storage); and Chandrasekaran FIG. 7, applications 702 [stored in memory 104, see FIG. 1] contain log files 704 [i.e., startup log partition, see par 119 "log files 704 may be a boot log"] and database entries 710 [i.e., abnormal operation log partition, see par. 122, database entries 710 may explicitly indicate errors]);
a non-volatile memory storing the boot code comprising a first region storing blocks for boot event records (Chandrasekaran par. 119, log files 704 may be, for example, one or more system level log files, such as a syslog, event log, authentication log, kernel log, boot log, scheduled job (e.g., cron) log… each of log files 704 consists of a time-ordered series of entries (e.g., text strings) written in accordance to a pre-established format [i.e., a boot log is a format for storing boot records]);
Therefore, it would have been obvious of one of ordinary skill in the art, having the teachings of Byom and Chandrasekaran before him, before the effective filing date of the claimed invention, to combine Byom’s method of logging boot errors with Chandrasekaran’s storing of boot logs and boot error logs in a non-volatile memory, the motivation being to use persistent storage for the purpose of identifying and correcting errors applications run on the system (Chandrasekaran par. 117).
Claims 5, 7, 10, 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Byom in view of Chandrasekaran, further in view of Chishtie et. al. (US 2012/0254505 A1).
Regarding Claim 5, Byom in view of Chandrasekaran discloses the method of claim 1.
Byom in view of Chandrasekaran does not explicitly teach the method further comprising defining a record header for each record stored in the non-volatile memory, the header containing a state, signature, version, payload length, and cyclic redundancy check and a state of a respective record, and wherein the state comprises the status of a corresponding record.
In the analogous art of storing records in flash memory, Chishtie teaches:
defining a record header for each record stored in the non-volatile memory, the header containing a state (Chishtie par. 43, flags or data may be maintained in the record header; also see par. 51, array record 200 may also include flags or other status values 240 to indicate a status of the data record), signature, version, payload length, and cyclic redundancy check and a state of a respective record (Chishtie par. 40-41 [Table 1], record data includes endsignature 124 [i.e., signature], recordVersion 104 [i.e., version], totalLength 116 [i.e., payload length], and dataChecksum 106 [i.e., cyclic redundancy check, see par. 41, dataChecksum 106 is a checksum or other verification code value computed from the payload such as a CRC32]), and wherein the state comprises the status of a corresponding record (Chishtie par. 51, array record 200 may also include flags or other status values 240 to indicate a status of the data record).
Therefore, it would have been obvious of one of ordinary skill in the art, having the teachings of Byom, Chandrasekaran, and Chishtie before him, before the effective filing date of the claimed invention, to combine Byom and Chandrasekaran’s method of logging boot errors in non-volatile memory with Chishtie’s format for storing records in flash memory, the motivation being to organize records to reduce wear and tear on the flash memory (Chishtie par. 18-19).
Regarding Claim 7, Byom in view of Chandrasekaran and Chishtie discloses the method of claim 5 further comprising identifying a next available block to store a new record within the startup log partition or abnormal operation log partition (Chishtie par. 54, a write command is invoked at 400, requesting that an unsecure record be written to the flash memory… at 410, the next available “best fit” block is located for the record; also see Byom par. 38, during time period T3, the NVM interface can store the one or more error notifications in an error log 234).
Regarding Claim 10, Byom in view of Chandrasekaran and Chishtie discloses the method of claim 7 further comprising:
checking, by the application, whether or not a partition is full (Chishtie par. 70, it is determined that there is insufficient space in the flash memory to write a new or updated data record to the memory); and
erasing, for a full partition, in a cleanup operation the entire partition by sectors for a next reboot operation to store logs (Chishtie par. 64, once the other data records have been moved, the blocks storing the previous versions of those moved records and the sub-records may be erased at 830; Chishtie par. 70 ; and Chishtie par. 65, garbage collection routine [i.e., cleanup operation] can be executed at predefined intervals or upon certain triggering events—for example upon bootup or restart of the computing or communication device, or upon shutdown [i.e., reboot operation]).
Regarding Claim 17, Byom discloses a method for boot logging in embedded devices (Byom par. 4, systems and methods are provided for handling errors during device bootup from a non-volatile memory by using an error log to keep track of error notifications during device bootup [keeping logs during boot, i.e., boot logging]), the method comprising:
executing a boot loader sequence on a processor (Byom par. 37, bootloader 230 may be configured to load the operating system and associated data into memory 214); and par. 16, SoC control circuitry 112 can include one or more processors that operate under the control of software/firmware stored in NVM 120;
appending boot event records to a first region in […] memory (Byom par. 38, NVM interface can store the one or more error notifications [i.e., boot events, as errors are events during boot] in an error log 234, which can be implemented as a scratch memory buffer and/or a reserved random-access memory area in memory 214 [i.e., abnormal operation log partition]);
[…];
extracting boot records after successful system startup (Byom par. 54, a determination can be made if one or more fatal errors were detected during the device bootup… NVM driver can determine if the error log includes one or more uECC notifications; and par. 55, the NVM driver can retire one or more blocks associated with the fatal errors [i.e., records are provided to NVM driver for improvement]; also see par. 32, electronic device 100 can re-verify the firmware stored in memory 114 after the bootup process has completed, also par. 33, “to prevent firmware failure and avoid data loss, NVM interface 116 can be configured to detect errors and maintain an error log during device bootup... once device 100 has entered a writeable context (e.g., device bootup has completed), NVM driver 117 can be configured to correct the detected errors using the error log”).
Byom does not explicitly disclose:
appending boot event records to a first region in non-volatile memory;
locating available blocks in the first region for new records without erase operations.
In the analogous art of securely booting operating systems, Chandrasekaran teaches:
appending boot event records to a first region in non-volatile memory (Chandrasekaran par. 43, memory 104 may be non-volatile memory (e.g., flash memory, hard disk drives, solid state drives, compact discs (CDs), digital video discs (DVDs), and/or tape storage); and Chandrasekaran FIG. 7, applications 702 [stored in memory 104, see FIG. 1] contain log files 704 [i.e., startup log partition, see par 119 "log files 704 may be a boot log"]).
Therefore, it would have been obvious of one of ordinary skill in the art, having the teachings of Byom and Chandrasekaran before him, before the effective filing date of the claimed invention, to combine Byom’s method of logging boot errors with Chandrasekaran’s storing of boot logs and boot error logs in a non-volatile memory, the motivation being to use persistent storage for the purpose of identifying and correcting errors applications run on the system (Chandrasekaran par. 117).
Byom and Chandrasekaran do not explicitly disclose:
locating available blocks in the first region for new records without erase operations.
In the analogous art of storing records in flash memory, Chishtie teaches:
locating available blocks in the first region for new records without erase operations (Chishtie par. 54, a write command is invoked at 400, requesting that an unsecure record be written to the flash memory… at 410, the next available “best fit” block is located for the record).
Therefore, it would have been obvious of one of ordinary skill in the art, having the teachings of Byom, Chandrasekaran, and Chishtie before him, before the effective filing date of the claimed invention, to combine Byom and Chandrasekaran’s method of logging boot errors in non-volatile memory with Chishtie’s format for storing records in flash memory, the motivation being to organize records to reduce wear and tear on the flash memory (Chishtie par. 18-19).
Regarding Claim 18, Byom in view of Chandrasekaran and Chishtie disclose the method of claim 17 further comprising transitioning the state in a record header if logging a duplicate failure event (Chishtie par. 71, any records with duplicate record version numbers or any duplicate secure data records may be identified and removed; and Chishtie par. 59, the dataLength 118 of the data record is set to zero, indicating that the data record is flagged for deletion).
Regarding Claim 19, Byom in view of Chandrasekaran and Chishtie disclose the method of claim 18 wherein appending records further comprises writing record headers containing CRC values and sequence numbers (Chishtie par. 40-41 [Table 1], record data includes dataChecksum 106 [i.e., cyclic redundancy check values, see par. 41, dataChecksum 106 is a checksum or other verification code value computed from the payload such as a CRC32] and recordNumber 102 [i.e., sequence numbers]).
Regarding Claim 20, the claim is similar in scope to claims 3 and 4 as addressed above and is thus rejected under the same rationale.
Claims 6, 8, 9, 11, 13, and 14-16 are rejected under 35 U.S.C. 103 as being unpatentable over Byom in view of Chandrasekaran and Chishtie, further in view of Stack Overflow (“Data handling for a flash chip”) [NPL].
Regarding Claim 6, Byom in view of Chandrasekaran and Chishtie discloses the method of claim 5, wherein the state comprises the status of a corresponding record (Chishtie par. 51, array record 200 may also include flags or other status values 240 to indicate a status of the data record).
Byom in view of Chandrasekaran and Chishtie does not explicitly disclose:
maintaining, in the boot record, a one-bit field indicating whether record has been dumped by an application.
In the analogous art of storing records in flash memory. Stack Overflow teaches:
maintaining, in the [system] record, a one-bit field indicating whether record has been dumped by an application (Stack Overflow pg. 2, “once the whole sector has been erased (typically all cells are set to 1)” [i.e., all bits in empty flash are set to 1]; and pg. 2, “you can always turn a 1 into a 0, but not a 0 to a 1 without erasing”; and pg. 2, “[the] flash programming driver will write a copy of the new variable in the next available flash location” [i.e., key field [i.e., state field “give each variable an unique search key (which cannot be the value of an erased flash cell)”] is updated from default to 1 once the record is written [i.e., the application updates a bit-field to 0 to indicate the log has been dumped, see instant app. par. 61, and thus a bit-field of 1 indicates the application has not been dumped] by an application).
Therefore, it would have been obvious of one of ordinary skill in the art, having the teachings of Byom, Chandrasekaran, Chishtie, and Stack Overflow before him, before the effective filing date of the claimed invention, to combine Byom, Chandrasekaran, and Chishtie’s method of logging boot errors in non-volatile memory with Stack Overflow’s format for storing records in flash memory, the motivation being to operate within the limitations of flash memory (Stack Overflow pg. 2, “you can always turn a 1 into a 0, but not a 0 to a 1 without erasing”).
Regarding Claim 8, Byom in view of Chandrasekaran and Chishtie discloses the method of claim 7. Byom in view of Chandrasekaran and Chishtie does not explicitly disclose:
wherein the identifying step comprises using a binary search operation.
In the analogous art of storing records in flash memory. Stack Overflow teaches:
wherein the identifying step comprises using a binary search operation (Stack Overflow pg. 4, “you could do binary search to find where the valid data ends”, and pg. 4 “you only need to find the end, so it is as binary searchable as it is any other kind of searchable”).
Therefore, it would have been obvious of one of ordinary skill in the art, having the teachings of Byom, Chandrasekaran, Chishtie, and Stack Overflow before him, before the effective filing date of the claimed invention, to combine Byom, Chandrasekaran, and Chishtie’s method of logging boot errors in non-volatile memory with Stack Overflow’s format for storing records in flash memory, the motivation being to operate within the limitations of flash memory (Stack Overflow pg. 4, utilize binary search to find the end of the data because data is logged from start to end).
Regarding Claim 9, Byom in view of Chandrasekaran and Chishtie, further in view of Stack Overflow disclose the method of claim 6 wherein the state transitions between bit states 0 and 1 upon logging a repetitive abnormal operation to prevent storage of duplicative abnormal operation logs in the abnormal operation log partition (Chishtie par. 71, any records with duplicate record version numbers or any duplicate secure data records may be identified and removed; and Chishtie par. 59, the dataLength 118 of the data record is set to zero, indicating that the data record is flagged for deletion).
Regarding Claim 11, Byom in view of Chandrasekaran and Chishtie discloses the method of claim 10 wherein the cleanup operation erases the sectors […] (Chishtie par. 64, once the other data records have been moved, the blocks storing the previous versions of those moved records and the sub-records may be erased at 830),
the method further comprising providing the boot event records to a user or set of debugging tools for product improvement (Byom par. 54, a determination can be made if one or more fatal errors were detected during the device bootup… NVM driver can determine if the error log includes one or more uECC notifications; and par. 55, the NVM driver can retire one or more blocks associated with the fatal errors [i.e., records are provided to NVM driver for improvement]).
Byom in view of Chandrasekaran and Chishtie does not explicitly disclose:
wherein the cleanup operation erases the sectors in reverse order;
In the analogous art of storing records in flash memory. Stack Overflow teaches:
wherein the cleanup operation erases the sectors in reverse order (Stack Overflow pg. 4, “you could do binary search to find where the valid data ends”, and pg. 4 “you only need to find the end, so it is as binary searchable as it is any other kind of searchable”; and pg. 3, “when the flash sector gets full, you have to erase it no matter what”; [i.e., a binary search is implemented to find the end of the data; an operation to erase therefore must be in reverse order to maintain that data structure (or else binary search is useless)]);
Therefore, it would have been obvious of one of ordinary skill in the art, having the teachings of Byom, Chandrasekaran, Chishtie, and Stack Overflow before him, before the effective filing date of the claimed invention, to combine Byom, Chandrasekaran, and Chishtie’s method of logging boot errors in non-volatile memory with Stack Overflow’s methodology to locate records, the motivation being to operate within the limitations of flash memory (Stack Overflow pg. 4, utilize binary search to find the end of the data because data is logged from start to end; Stack Overflow pg. 3, must erase entire sectors and cannot edit sectors directly).
Regarding Claim 13, Byom in view of Chandrasekaran and Chishtie, further in view of Stack Overflow disclose the system of claim 12 further comprising processing logic configured to locate a next available block for writing a new record into the non-volatile memory through a binary search operation within the first region or second region (Stack Overflow pg. 4, “you could do binary search to find where the valid data ends”, and pg. 4 “you only need to find the end, so it is as binary searchable as it is any other kind of searchable”).
Therefore, it would have been obvious of one of ordinary skill in the art, having the teachings of Byom, Chandrasekaran, Chishtie, and Stack Overflow before him, before the effective filing date of the claimed invention, to combine Byom, Chandrasekaran, and Chishtie’s method of logging boot errors in non-volatile memory with Stack Overflow’s format for storing records in flash memory, the motivation being to operate within the limitations of flash memory (Stack Overflow pg. 4, utilize binary search to find the end of the data because data is logged from start to end).
Regarding Claim 14, Byom in view of Chandrasekaran and Chishtie, further in view of Stack Overflow disclose the system of claim 13 further comprise a record header containing a cyclic redundancy check (Chishtie par. 40-41 [Table 1], record data includes dataChecksum 106 [i.e., cyclic redundancy check, see par. 41, dataChecksum 106 is a checksum or other verification code value computed from the payload such as a CRC32]) and a state (Chishtie par. 51, array record 200 may also include flags or other status values 240 to indicate a status of the data record).
Regarding Claim 15, Byom in view of Chandrasekaran and Chishtie, further in view of Stack Overflow disclose the system of claim 14 wherein the state transitions upon logging a repetitive failure to avoid duplicate records (Chishtie par. 71, any records with duplicate record version numbers or any duplicate secure data records may be identified and removed; and Chishtie par. 59, the dataLength 118 of the data record is set to zero, indicating that the data record is flagged for deletion).
Regarding Claim 16, the claim is similar in scope to claims 3 and 4 as addressed above and is thus rejected under the same rationale.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to COLE JIAWEI WENTZEL whose telephone number is (703) 756-4762. The examiner can normally be reached 9:30am-5:30pm ET (Mon-Fri).
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, Andrew Jung can be reached on (571) 270-3779. 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.
/C.J.W./Examiner, Art Unit 2175
/ANDREW J JUNG/Supervisory Patent Examiner, Art Unit 2175
Prosecution Insights