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 .
Specification
The title of the invention is not descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed.
The abstract of the disclosure is objected to because it recites verbatim as claim language. A corrected abstract of the disclosure is required and must be presented on a separate sheet, apart from any other text. See MPEP § 608.01(b).
Applicant is reminded of the proper content of an abstract of the disclosure.
A patent abstract is a concise statement of the technical disclosure of the patent and should include that which is new in the art to which the invention pertains. The abstract should not refer to purported merits or speculative applications of the invention and should not compare the invention with the prior art.
If the patent is of a basic nature, the entire technical disclosure may be new in the art, and the abstract should be directed to the entire disclosure. If the patent is in the nature of an improvement in an old apparatus, process, product, or composition, the abstract should include the technical disclosure of the improvement. The abstract should also mention by way of example any preferred modifications or alternatives.
Where applicable, the abstract should include the following: (1) if a machine or apparatus, its organization and operation; (2) if an article, its method of making; (3) if a chemical compound, its identity and use; (4) if a mixture, its ingredients; (5) if a process, the steps.
Extensive mechanical and design details of an apparatus should not be included in the abstract. The abstract should be in narrative form and generally limited to a single paragraph within the range of 50 to 150 words in length.
See MPEP § 608.01(b) for guidelines for the preparation of patent abstracts.
Claim Rejections - 35 USC § 112
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. - An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
Use of the word “means” (or “step for”) in a claim with functional language creates a rebuttable presumption that the claim element is to be treated in accordance with 35 U.S.C.112(f) (pre-AIA 35 U.S.C. 112, sixth paragraph). The presumption that 35 U.S.C. 112(f) (pre-AIA 35 U.S.C. 112, sixth paragraph) is invoked is rebutted when the function is recited with sufficient structure, material, or acts within the claim itself to entirely perform the recited function.
Absence of the word “means” (or “step for”) in a claim creates a rebuttable presumption that the claim element is not to be treated in accordance with 35 U.S.C. 112(f) (pre-AIA 35 U.S.C. 112, sixth paragraph). The presumption that 35 U.S.C. 112(f) (pre-AIA 35 U.S.C. 112, sixth paragraph) is not invoked is rebutted when the claim element recites function but fails to recite sufficiently definite structure, material or acts to perform that function.
Claim elements in this application that use the word “means” (or “step for”) are presumed to invoke 35 U.S.C. 112(f) except as otherwise indicated in an Office action. Similarly, claim elements that do not use the word “means” (or “step for”) are presumed not to invoke 35 U.S.C. 112(f) except as otherwise indicated in an Office action.
Claim limitation “configured to” has/have been interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because it uses/they use a generic placeholder “configured to” coupled with functional language “control” and "store” without reciting sufficient structure to achieve the function. Furthermore, the generic placeholder is not preceded by a structural modifier. [0021 the memory controller 106 is coupled to the memory device 104 and the host 108, and is configured to control the memory device 104. The memory controller 106 may manage data stored in the memory device 104, and communicate with the host 108 and 0023 controller 106 may be configured to control operations of the memory device 104, such as read, erase, and program operations. The memory controller 106 may further be configured to manage various functions with respect to data stored or to be stored in the memory device 104, including, but not limited to, bad-block management, garbage collection, logical-to-physical address translation, wear leveling, etc. In some implementations, the memory controller 106 is further configured to process error correction codes…]
Since the claim limitation(s) invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, claim(s) 1-20 has/have been interpreted to cover the corresponding structure described in the specification that achieves the claimed function, and equivalents thereof.
A review of the specification shows that the following appears to be the corresponding structure described in the specification for the 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph limitation: paragraphs [0007 and 0008]. However, these section does not provide any structure thereof and only summarize the functionality.
If applicant wishes to provide further explanation or dispute the examiner’s interpretation of the corresponding structure, applicant must identify the corresponding structure with reference to the specification by page and line number, and to the drawing, if any, by reference characters in response to this Office action.
If applicant does not intend to have the claim limitation(s) treated under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112 , sixth paragraph, applicant may amend the claim(s) so that it/they will clearly not invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, or present a sufficient showing that the claim recites/recite sufficient structure, material, or acts for performing the claimed function to preclude application of 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
For more information, see MPEP § 2173 el seq. and Supplementary Examination Guidelines for Determining Compliance With 35 U.S.C. 112 and for Treatment of Related Issues in Patent Applications, 76 FR 7162, 7167 (Feb. 9, 2011).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Konan et al US 2019/0129774 in view of Bagchi et al US 2016/0314055.
Regarding claims 1 and 11
Konan et al teaches
a memory configured to store a first instruction set for performing an operation for tracing an event during firmware running [see figs 1-2] and [0011] in one aspect, a non-transitory computer-readable storage medium stores a set of instructions for directing a device to perform operations for tracking events with respect to firmware. The set of instructions comprises instructions for creating a tracker event log including multiple event-items pertaining to events occurring during execution of the firmware, each of the event-items including a timestamp, a unique identifier and at least one parameter describing the corresponding event storing the event-items in volatile memory in accordance with an array-based list structure; establishing a flush strategy for flushing event-items from the volatile memory to non-volatile memory; establishing a flush access path for each of the event-items for flushing the corresponding event-item from the volatile memory to the non-volatile memory; and selectively flushing event-items from the volatile memory to the non-volatile memory in accordance with the established flush strategy and using established flush access path for the event-item to be flushed] and [0080] an SSD device typically uses non-straightforward methods to store data in non-volatile memory, i.e., NAND, compared to a hard disk drive (HDD). The complexity comes from NAND specific operations, such as page-based programming and block-based erasing. An SSD saves meta information (system data) to maintain its operation. A portion of the system data is also stored in NAND. Typically, a unified approach is used to store system data in order to save code and NAND space. However, storing a tracker event log together with other system data has certain shortcomings. In the event that system storage breaks or becomes disabled (as bugs can occur anywhere in code), an appended tracker event log is not likely recoverable. Also, before using a tracker event log stored with other system data, initialization of storage is needed; thus such initialization process cannot be profiled with the tracker. Further, storing a tracker event log with other system data affects the general system area state, which should be minimized];
one or more processors coupled with the memory and configured to perform the first instruction set, wherein the first instruction set includes instructions that are able to cause the memory system to perform at least the following operations [0012] in another aspect, a non-transitory computer-readable storage medium stores a set of instructions for using a firmware event tracker stored in a NAND device and that includes multiple event-items pertaining to events that occurred during execution of firmware in a storage device. Each of the event-items includes a timestamp, a unique identifier and at least one parameter describing the corresponding event. The event-items are arranged in groups, each having its own group identifier. The set of instructions comprises instructions for parsing source and header files in the tracker event log to detect and define all unique identifiers, detect and define all group identifiers, and build and define mapping between unique identifiers and group identifiers; generating a file with description of all parsed event-items entered in the tracker event log; and generating index files with all source definitions];
recording, as the binary log, at least a compilation address of a local static variable corresponding to the format string describing an event and the timestamp of each event item 0066] debugging with internal logging entails storing device events inside the device itself with the ability to extract them over a host interface. A log type can be classified as either statistical or flow. The former captures statistics of the occurrences of internal events, while the latter captures events with timestamps and parameters. Statistical logs are useful for a generic overview during device FA, and can narrow down a problematic scenario very quickly. For example, incremented statistics for a device being over temperature gives a clue on a possible root cause of failure, but it does not give an exact timestamp, i.e., when the event happened and under what circumstances. Flow logs, on the other hand, provide an entire history of events that happened on the device. A shortcoming of flow logs, though, is memory usage and performance. Statistical logs are usually implemented with simple increments of global variables and can be compactly stored. Flow logs require more space, since they utilize timestamps and custom parameters. Flow logs usually support a log overwrite mechanism, as memory resources are limited, and when there is no more space for new logs, the oldest are deleted to free-up memory]. Konan et al teaches event and memory configuration but doesn’t teach explicitly in response to triggering of a binary log including a plurality of event items, determining a timestamp and a format string describing an event, which are included in each of the plurality of event items, wherein the event items belong to events that occur during running of firmware in the memory system, however, Bagchi et al teaches [0169] at runtime, the record code in binary firmware 1320 logs events, e.g., values read from NDRs such as peripheral registers, polling loops, or interrupts. At replay time, the emulator uses the instrumentation map 1322 to decide which instructions access peripheral registers and thus need to be fed from the log, and to determine how to decode the items in that log]. Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate binary log. The modification would have been obvious because one of ordinary skill in the art would have been motivated to combine teaching into compilation and during event by reducing disk space usage and improving write speeds and each entry is stored as a single binary block, which speeds up both writing and reading compared to line-by-line text parsing.
Regarding claims 2 and 14
Konan et al teaches
each of the plurality of event items further includes at least one parameter describing an event and the binary log further includes the at least one parameter describing an event [0012] in another aspect, a non-transitory computer-readable storage medium stores a set of instructions for using a firmware event tracker stored in a NAND device and that includes multiple event-items pertaining to events that occurred during execution of firmware in a storage device. Each of the event-items includes a timestamp, a unique identifier and at least one parameter describing the corresponding event. The event-items are arranged in groups, each having its own group identifier. The set of instructions comprises instructions for parsing source and header files in the tracker event log to detect and define all unique identifiers, detect and define all group identifiers, and build and define mapping between unique identifiers and group identifiers; generating a file with description of all parsed event-items entered in the tracker event log; and generating index files with all source definitions]. The feature of providing parameter… would be obvious for the reasons set forth in the rejection of claim 1.
Regarding claims 3 and 15
Konan et al teaches
the format string describing an event is stored, in the form of the local static variable, in one section of an executable and linkable format (ELF) file in which the firmware is located [0060] the source of the SST in each cell string may be coupled to a common source line CSL, and the drain of each DST may be coupled to the corresponding bit line. Gates of the SSTs in the cell strings may be coupled to the SSL, and gates of the DSTs in the cell strings may be coupled to the DSL. Gates of the memory cells across the cell strings may be coupled to respective word lines. That is, the gates of memory cells MC0 are coupled to corresponding word line WL0, the gates of memory cells MC1 are coupled to corresponding word line WL1, etc. The group of memory cells coupled to a particular word line may be referred to as a physical page. Therefore, the number of physical pages in the memory block 211 may correspond to the number of word lines]. The feature of providing string… would be obvious for the reasons set forth in the rejection of claim 1.
Regarding claims 4 and 16
Konan et al teaches
wherein format strings describing different events correspond to compilation addresses of different local static variables [0066, a log type can be classified as either statistical or flow. The former captures statistics of the occurrences of internal events, while the latter captures events with timestamps and parameters. Statistical logs are useful for a generic overview during device FA, and can narrow down a problematic scenario very quickly. For example, incremented statistics for a device being over temperature gives a clue on a possible root cause of failure, but it does not give an exact timestamp, i.e., when the event happened and under what circumstances. Flow logs, on the other hand, provide an entire history of events that happened on the device. A shortcoming of flow logs, though, is memory usage and performance. Statistical logs are usually implemented with simple increments of global variables and can be compactly stored. Flow logs require more space, since they utilize timestamps and custom parameters. Flow logs usually support a log overwrite mechanism, as memory resources are limited, and when there is no more space for new logs, the oldest are deleted to free-up memory]. ]. The feature of providing variable… would be obvious for the reasons set forth in the rejection of claim 1.
Regarding claims 5 and 17
Konan et al teaches
the first instruction set is implemented through a plurality of macros [0013] in still another aspect, a non-transitory computer-readable storage medium stores a set of instructions for directing a host device to perform failure analysis of firmware using a firmware event tracker stored in a NAND memory device and that includes multiple event-items pertaining to events that occurred during execution of firmware in a storage device. Each of the event-items includes a timestamp, a unique identifier and at least one parameter describing the corresponding event. The event-items being arranged in groups, each having its own group identifier. The set of instructions comprising instructions for establishing communication between the host device and the NAND memory device; selecting individual event-items using their respective unique identifiers or one or more groups of event-items using their respective group identifiers; reading the selected event-items; parsing data of the selected event-items; sorting the selected event-items by timestamps; and analyzing details of the sorted event-items to perform failure analysis on the firmware]. The feature of providing macros or instructions… would be obvious for the reasons set forth in the rejection of claim 1.
Regarding claims 6 and 18
Konan et al teaches
the binary log is configured to perform failure analysis on the firmware [ see abstract and [0013] in still another aspect, a non-transitory computer-readable storage medium stores a set of instructions for directing a host device to perform failure analysis of firmware using a firmware event tracker stored in a NAND memory device and that includes multiple event-items pertaining to events that occurred during execution of firmware in a storage device. Each of the event-items includes a timestamp, a unique identifier and at least one parameter describing the corresponding event. The event-items being arranged in groups, each having its own group identifier. The set of instructions comprising instructions for establishing communication between the host device and the NAND memory device; selecting individual event-items using their respective unique identifiers or one or more groups of event-items using their respective group identifiers; reading the selected event-items; parsing data of the selected event-items; sorting the selected event-items by timestamps; and analyzing details of the sorted event-items to perform failure analysis on the firmware]. The feature of providing failure analysis… would be obvious for the reasons set forth in the rejection of claim 1.
Regarding claims 7 and 19
Konan et al teaches
the memory includes a non-volatile memory device; and the binary log is stored in the non-volatile memory device [0021] FIG. 7 is a schematic diagram showing flushing of event-items to non-volatile memory in accordance with an embodiment of the present invention]. The feature of providing non-volatile… would be obvious for the reasons set forth in the rejection of claim 1.
Regarding claims 8 and 20
Konan et al teaches
including a memory card or a solid-state disk [0019] FIG. 5 is a schematic diagram showing an exemplary multi-core solid state drive (SSD) in connection with storage of tracked event-items in accordance with an embodiment of the present invention]. The feature of providing solid state… would be obvious for the reasons set forth in the rejection of claim 1.
Regarding claim 9
Konan et al teaches
a memory configured to store a second instruction set using a firmware event tracer, wherein the firmware event tracer includes a plurality of event items, and the event items belong to events that occur during running of firmware in the memory system, and each event item includes a timestamp and a format string describing an event [0011] in one aspect, a non-transitory computer-readable storage medium stores a set of instructions for directing a device to perform operations for tracking events with respect to firmware. The set of instructions comprises instructions for creating a tracker event log including multiple event-items pertaining to events occurring during execution of the firmware, each of the event-items including a timestamp, a unique identifier and at least one parameter describing the corresponding event storing the event-items in volatile memory in accordance with an array-based list structure; establishing a flush strategy for flushing event-items from the volatile memory to non-volatile memory; establishing a flush access path for each of the event-items for flushing the corresponding event-item from the volatile memory to the non-volatile memory; and selectively flushing event-items from the volatile memory to the non-volatile memory in accordance with the established flush strategy and using established flush access path for the event-item to be flushed] and [0080] an SSD device typically uses non-straightforward methods to store data in non-volatile memory, i.e., NAND, compared to a hard disk drive (HDD). The complexity comes from NAND specific operations, such as page-based programming and block-based erasing. An SSD saves meta information (system data) to maintain its operation. A portion of the system data is also stored in NAND. Typically, a unified approach is used to store system data in order to save code and NAND space. However, storing a tracker event log together with other system data has certain shortcomings. In the event that system storage breaks or becomes disabled (as bugs can occur anywhere in code), an appended tracker event log is not likely recoverable. Also, before using a tracker event log stored with other system data, initialization of storage is needed; thus such initialization process cannot be profiled with the tracker. Further, storing a tracker event log with other system data affects the general system area state, which should be minimized];
one or more processors coupled with the memory and configured to perform the second instruction set, wherein the second instruction set includes instructions that are able to cause the memory system to perform at least the following operations [0012] in another aspect, a non-transitory computer-readable storage medium stores a set of instructions for using a firmware event tracker stored in a NAND device and that includes multiple event-items pertaining to events that occurred during execution of firmware in a storage device. Each of the event-items includes a timestamp, a unique identifier and at least one parameter describing the corresponding event. The event-items are arranged in groups, each having its own group identifier. The set of instructions comprises instructions for parsing source and header files in the tracker event log to detect and define all unique identifiers, detect and define all group identifiers, and build and define mapping between unique identifiers and group identifiers; generating a file with description of all parsed event-items entered in the tracker event log; and generating index files with all source definitions];
outputting the obtained format string and a corresponding timestamp together [0066] debugging with internal logging entails storing device events inside the device itself with the ability to extract them over a host interface. A log type can be classified as either statistical or flow. The former captures statistics of the occurrences of internal events, while the latter captures events with timestamps and parameters. Statistical logs are useful for a generic overview during device FA, and can narrow down a problematic scenario very quickly. For example, incremented statistics for a device being over temperature gives a clue on a possible root cause of failure, but it does not give an exact timestamp, i.e., when the event happened and under what circumstances. Flow logs, on the other hand, provide an entire history of events that happened on the device. A shortcoming of flow logs, though, is memory usage and performance. Statistical logs are usually implemented with simple increments of global variables and can be compactly stored. Flow logs require more space, since they utilize timestamps and custom parameters. Flow logs usually support a log overwrite mechanism, as memory resources are limited, and when there is no more space for new logs, the oldest are deleted to free-up memory];
in response to a print command of a binary log, obtaining the format string describing an event according to a compilation address of a local static variable corresponding to a format string in the binary log and in combination with a local static variable stored . Konan et al teaches event and memory configuration but doesn’t teach explicitly in response to triggering of a binary log including a plurality of event items, determining a timestamp and a format string describing an event, which are included in each of the plurality of event items, wherein the event items belong to events that occur during running of firmware in the memory system and an executable and linkable format (ELF) file in which the firmware is located however, Bagchi et al teaches [0169] at runtime, the record code in binary firmware 1320 logs events, e.g., values read from NDRs such as peripheral registers, polling loops, or interrupts. At replay time, the emulator uses the instrumentation map 1322 to decide which instructions access peripheral registers and thus need to be fed from the log, and to determine how to decode the items in that log] and [0076] an exemplary compilation process is shown in FIG. 1. OSes are typically monolithic in the sense that OS and application code are compiled together to generate a single binary. TARDIS runtime code is split into TARDIS OS-specific code 108 and TARDIS record code 102. The code 108 that is OS-specific is used to schedule tasks such as flushing buffers or compressing traces. Task management is OS dependent (in code 108). The TARDIS record code 102 contains functions that record events such as interrupts and peripheral or other NDR reads. In the example shown, the record code 102 itself is not instrumented. Instrumentation of application code 104 is implemented by inserting into application code 104 calls to routines in the record code 102. These calls can be in lined to reduce execution time at the cost of code size in a link-time-optimization pass. Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate binary log. The modification would have been obvious because one of ordinary skill in the art would have been motivated to combine teaching into binary logs are designed to handle large volumes of data without performance degradation, making them ideal for high-traffic applications paired with a linkable format, the structured nature of the binary data allows for efficient indexing, streaming, and integration into other systems.
Regarding claim 10
Konan et al teaches
wherein each of the plurality of event items further includes at least one parameter describing an event, and the at least one parameter describing an event is filled in a placeholder of the obtained format string describing an event and when the obtained format string and the corresponding timestamp are outputted together, a filled format string and the corresponding timestamp are outputted together [0069] FIG. 4 is a schematic illustration of a firmware event tracker 40, showing creation of a tracker event log 41. The tracker event log includes multiple event-items 42, for example, event-items 42a-42d. Each of the event-items 42a-42d is defined by a timestamp, a unique identifier (ID), and one to five custom parameters. A custom parameter may identify a specific channel, die, block, page, and/or column. Each of the custom parameters may be of a double word (DWORD) type. In the illustrated embodiment, event-item 42a has three custom parameters (DW0, DW1, DW2), event-item 42b has one custom parameter (DW0), event-item 42c has four custom parameters (DW0, DW1, DW2, DW3), and event-item 42d has two custom parameters (DW0, DW1) and [0060] The source of the SST in each cell string may be coupled to a common source line CSL, and the drain of each DST may be coupled to the corresponding bit line. Gates of the SSTs in the cell strings may be coupled to the SSL, and gates of the DSTs in the cell strings may be coupled to the DSL. Gates of the memory cells across the cell strings may be coupled to respective word lines. That is, the gates of memory cells MC0 are coupled to corresponding word line WL0, the gates of memory cells MC1 are coupled to corresponding word line WL1, etc. The group of memory cells coupled to a particular word line may be referred to as a physical page. Therefore, the number of physical pages in the memory block 211 may correspond to the number of word lines]. The feature of providing parameter… be obvious for the reasons set forth in the rejection of claim.
Regarding claim 12
Konan et al teaches
acquire a binary log and a local static variable stored in an executable and linkable format (ELF) file in which firmware is located, wherein a compilation address of the local static variable corresponds to a format string describing an event [0060] the source of the SST in each cell string may be coupled to a common source line CSL, and the drain of each DST may be coupled to the corresponding bit line. Gates of the SSTs in the cell strings may be coupled to the SSL, and gates of the DSTs in the cell strings may be coupled to the DSL. Gates of the memory cells across the cell strings may be coupled to respective word lines. That is, the gates of memory cells MC0 are coupled to corresponding word line WL0, the gates of memory cells MC1 are coupled to corresponding word line WL1, etc. The group of memory cells coupled to a particular word line may be referred to as a physical page. Therefore, the number of physical pages in the memory block 211 may correspond to the number of word lines];
based on the acquired local static variable, parse the compilation address of the local static variable in the binary log, to obtain the format string describing an event [0097] in order to perform failure analysis (FA) using the firmware event tracker 40 including the tracker event log 41 and its associated tracker event-items 42, a vendor specific protocol is implemented over a device/host interface, which provides the ability to read tracker buffers from the non-volatile memory, i.e., NAND. When all data related to the event-items 42 is read, such data is parsed according to the tracker layout and event-items 42 are sorted by timestamps. Parsed data can be exported to a csv file and analyzed in detail] and [0103] FIG. 12 is a flow chart illustrating an aspect of using the firmware event tracker 40 in which event-items have been recorded in a tracker event log. In particular, FIG. 12 shows an embodiment of the prebuild script process. At step 1201, source and header files in the tracker event log 41 are parsed to detect and define all unique identifiers, detect and define all group identifiers, and build and define mapping between unique identifiers and group identifiers. Then, at step 1202, a file with description of all parsed event-items 42 entered in the tracker event log 41 is generated. Index files with all source definitions are generated at step 1203];
output the obtained format string and a corresponding timestamp together [0066] Debugging with internal logging entails storing device events inside the device itself with the ability to extract them over a host interface. A log type can be classified as either statistical or flow. The former captures statistics of the occurrences of internal events, while the latter captures events with timestamps and parameters. Statistical logs are useful for a generic overview during device FA, and can narrow down a problematic scenario very quickly. For example, incremented statistics for a device being over temperature gives a clue on a possible root cause of failure, but it does not give an exact timestamp, i.e., when the event happened and under what circumstances. Flow logs, on the other hand, provide an entire history of events that happened on the device. A shortcoming of flow logs, though, is memory usage and performance. Statistical logs are usually implemented with simple increments of global variables and can be compactly stored. Flow logs require more space, since they utilize timestamps and custom parameters. Flow logs usually support a log overwrite mechanism, as memory resources are limited, and when there is no more space for new logs, the oldest are deleted to free-up memory]. The feature of providing log and parse… would be obvious for the reasons set forth in the rejection of claim 1.
Regarding claim 13
Konan et al teaches
each of the plurality of event items of the binary log further includes at least one parameter describing an event, and the at least one parameter describing an event is filled in a placeholder of the obtained format string describing an event; and when the obtained format string and the corresponding timestamp are outputted together, a filled format string and the corresponding timestamp are outputted together [0059] The exemplary memory block 211 may further include a plurality of cell strings 221 respectively coupled to bit lines BL0 to BLm-1. The cell string of each column may include one or more drain selection transistors DST and one or more source selection transistors SST. In the illustrated embodiment, each cell string has one DST and one SST. In a cell string, a plurality of memory cells or memory cell transistors MC0 to MCn-1 may be serially coupled between the selection transistors DST and SST. Each of the memory cells may be formed as a multi-level cell (MLC) storing data information of multiple bits] and [0104] FIG. 13 is a flow chart illustrating another aspect of using the firmware event tracker 40 to analyze firmware. In this embodiment, a host device performs failure analysis of firmware using the tracker event log 41, which is stored in NAND memory device. At step 1301, communication is established between the host device and the NAND memory device. Next, at step 1302, individual event-items 42 in the tracker event log 41 are selected using their respective unique identifiers, or group(s) of event-items are selected using their respective group identifiers. The selected event-items or group(s) of event-items are read at step 1303. An operation of parsing data of the selected event-items 42 or the selected group(s) of event-items 42 is performed at step 1304. The data can be parsed with an index file generated in operation 94 (of FIG. 9). The event-items 42 selected individually or as part of a group are sorted by timestamps at step 1305. The details of the sorted event-items 42 are then analyzed to perform FA on the firmware at step 1306]. The feature of providing timestamp… would be obvious for the reasons set forth in the rejection of claim 1.
Relevant Prior Art
US 8700868 B1 Dornbach teaches Methods And Systems For Incrementing A Logarithmic Count
US 9798607 B1 Kulkarni et al teaches System And Method For Smart Error Handling Mechanism For An Application
US 10810074 B2 Yu et al teaches Unified Error Monitoring, Alerting, And Debugging Of Distributed Systems
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Anil Khatri whose telephone number is (571)272-3725. The examiner can normally be reached M-F 8:30-5:00.
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, Wei Zhen can be reached at 571-272-3708. 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.
/ANIL KHATRI/Primary Examiner, Art Unit 2191
Prosecution Insights