DETAILED ACTION
This office action is in response to applicant’s remarks filed on September 2, 2025 in application 18/090,207.
Claims 1-20 are presented for examination. Claims 1, 8, 15 are amended.
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 .
Response to Arguments
Applicant's arguments filed September 2, 2025 have been fully considered but they are not persuasive.
Applicant stated that Subramanian discloses that a debug application includes a table to generate debug commands that specify the desired data using logical addresses but fails to teach updating identifiers of a command string based on an order of the payload arguments within the corresponding debug entry. Subramanian also fails to teach mapping … a log command associated with the debug information to the command string, the command string comprising identifiers that are updated based on an order of the payload arguments within the debug entry.
Examiner disagreed. The claimed limitation recited outputting the error information and debug information as a command string where the debug information is generated by mapping, via a lookup table, a log command to the command string. The command string is being outputted and generated by mapping debug information to the lookup table (debug application 1014 or 922 may have a similar table so that debug command may be generated that specify the desired debug data using logical addresses in a manner that is compatible with a common driver and that allow on-chip debug circuits to identify the debug data to be generated and returned, para. 70, the identifiers is equated to different logical address ranges corresponding to different debug data, fig. 10C, A-G, para. 69).
For these reasons, the rejections are maintained.
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 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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-5, 8-12, 15-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Huang et al. (US 11,275,638) in further view of Xie et al. (US 2017/0083427) in further view of Subramanian et al. (US 2019/0259465).
In regard to claim 1, Huang et al. teach a method comprising:
executing read only memory (ROM) code by a processing system (the firmware ROM is a basic input output system (BIOS) ROM, col. 2 lines 39-50);
detecting errors within the ROM code during a boot process (crashes during a boot session, col. 6 lines 13-43);
generating, via ROM debug circuitry (RDC) of the processing system, error information based on the errors and storing the error information within a first memory element, wherein the error information includes entries, and each of the entries is associated with a respective one of the errors (event logs include pre-defined, cognizable events, col. 6 lines 13-43);
generating, via the RDC, debug information based on the errors and storing the debug information within a second memory element, wherein the debug information is associated with the boot process (debug information can include minute details of a computing system’s operations that do not readily lend to a cognizable pattern, col. 6 lines 13-43); and
outputting, via test circuitry of the processing system, the error information and debug information based on a testing instruction (system runtime output can include debug information and event logs, col. 7 lines 33-52).
Huang et al. does not explicitly teach wherein the debug information comprises a debug entry comprising header information and payload arguments, wherein the header information comprises a data length entry, a log code, and a boot stage.
Xie et al. teach of a generating debugging information as debug code (para. 26). The debug code may take on a variety of forms where an addressing scheme whereby a message that includes a message header and message body … the debug code might indicate the last POST instruction completed or some other fashion the progress of the start up (para. 28).
It would have been obvious to modify the method of Huang et al. by adding Xie et al. debug code output. A person of ordinary skill in the art before the effective filing date of the claimed invention would have been motivated to make the modification because it would aid in rendering it for display in a variety of forms (para. 26-28).
Huang et al. and Xie et al. does not explicitly teach wherein the payload arguments correspond to debug values and a number of the payload arguments corresponds to a length in words of the data length entry, and the payload arguments are associated with the debug entry and outputting as a command string, wherein the debug information is generated by mapping, via a lookup table in the test circuitry, a log command associated with the debug information in the command string, the command string comprising identifiers that are updated based on an order of the payload arguments within the debug entry.
Subramanian et al. teach of using similar format of a read command, a debug command may be directed to a particular debug data by specifying one or more logical addresses within a debug namespace. A table 1050 that specifies such a mapping of a debug namespace 1010 to different debug data (para. 69). A debug command may be used identify the debug data to be generated (e.g., by using a lookup table that may be similar to table 1050)(para. 70-71, 74-76). The identifiers is equated to different logical address ranges corresponding to different debug data (fig. 10C, A-G, para. 69). A debug application 1014 or 922 may have a similar table so that debug command may be generated that specify the desired debug data using logical addresses in a manner that is compatible with a common driver and that allow on-chip debug circuits to identify the debug data to be generated and returned (para. 70). It is noted that applicant’s specification describes the debug information is stored via a command string, para. 51, and in the lookup table, the log command is translated to the command string, para. 52.
It would have been obvious to modify the method of Huang et al. and Xie et al. by adding Subramanian et al. storage device with debug namespace. A person of ordinary skill in the art before the effective filing date of the claimed invention would have been motivated to make the modification because it would aid in generated debug data and for communication with a NVMe interface with a host (para. 20, 51, 64-70)
In regard to claim 2, Huang et al. teach the method of claim 1, wherein the second memory element is a circular memory element (debug information includes first and second debug information and the first debug information stored on the first memory device is partially overwritten by the second debug information, col. 2 lines 22-38) and the first memory element is a non-circular memory element (initial system event logs being captured can be stored in limited firmware memory and additional system event logs are then generated by the operating system and can be stored in a hard drive, col. 6 lines 44-67).
In regard to claim 3, Huang et al. teach the method of claim 1, wherein each of the entries includes an error code for the associated error (event logs include pre-defined, cognizable events, col. 6 lines 13-43).
In regard to claim 4, Huang et al. teach the method of claim 3, wherein each of the entries further includes additional information and a boot stage for the associated error (system event logs can be generated throughout different phases of the computing system’s initialization, col. 6 lines 44-67).
In regard to claim 5, Huang et al. teach the method of claim 1 further comprising indicating an overflow condition of the first memory element based on determining that the first memory element is full (initial system event logs being captured can be stored in limited firmware memory and additional system event logs are then generated by the operating system and can be stored in a hard drive, col. 6 lines 44-67).
In regard to claim 8, Huang et al. teach a read only memory (ROM) debug circuitry (RDC) comprising finite state machine (FSM) circuitry comprising hardware logic configured to:
obtain, from ROM control circuitry (RCC), errors within ROM code during a boot process (crashes during a boot session, col. 6 lines 13-43), wherein the ROM code is executed by a processing system during the boot process (the firmware ROM is a basic input output system (BIOS) ROM, col. 2 lines 39-50), wherein the RDC and the RCC are included in the processing system;
generate, via the FSM circuitry, error information based on the errors and store the error information within a first memory element, wherein the error information includes entries, and each of the entries is associated with a respective one of the errors (event logs include pre-defined, cognizable events, col. 6 lines 13-43); and
generate, via the FSM circuitry, debug information based on the errors and store the debug information within a second memory element (debug information can include minute details of a computing system’s operations that do not readily lend to a cognizable pattern, col. 6 lines 13-43), wherein the error information and debug information are output from the processing system via test circuitry of the processing system based on a test instruction (system runtime output can include debug information and event logs, col. 7 lines 33-52).
Huang et al. does not explicitly teach wherein the debug information comprises a debug entry comprising header information and payload arguments, wherein the header information comprises a data length entry, a log code, and a boot stage associated with the boot process,
Xie et al. teach of a generating debugging information as debug code (para. 26). The debug code may take on a variety of forms where an addressing scheme whereby a message that includes a message header and message body … the debug code might indicate the last POST instruction completed or some other fashion the progress of the start up (para. 28).
Refer to claim 1 for motivational statement.
Huang et al. and Xie et al. does not explicitly teach wherein the payload arguments correspond to debug values and a number of the payload arguments corresponds to a length in words of the data length entry, and the payload arguments are associated with the debug entry and outputting as a command string, wherein the debug information is generated by mapping, via a lookup table in the test circuitry, a log command associated with the debug information in the command string, the command string comprising identifiers that are updated based on an order of the payload arguments within the debug entry.
Subramanian et al. teach of using similar format of a read command, a debug command may be directed to a particular debug data by specifying one or more logical addresses within a debug namespace. A table 1050 that specifies such a mapping of a debug namespace 1010 to different debug data (para. 69). A debug command may be used identify the debug data to be generated (e.g., by using a lookup table that may be similar to table 1050)(para. 70-71, 74-76). The identifiers is equated to different logical address ranges corresponding to different debug data (fig. 10C, A-G, para. 69). A debug application 1014 or 922 may have a similar table so that debug command may be generated that specify the desired debug data using logical addresses in a manner that is compatible with a common driver and that allow on-chip debug circuits to identify the debug data to be generated and returned (para. 70). It is noted that applicant’s specification describes the debug information is stored via a command string, para. 51, and in the lookup table, the log command is translated to the command string, para. 52.
Refer to claim 1 for motivational statement.
In regard to claim 9, Huang et al. teach the RDC of claim 8, wherein the second memory element is a circular memory element (debug information includes first and second debug information and the first debug information stored on the first memory device is partially overwritten by the second debug information, col. 2 lines 22-38) and the first memory element is a non-circular memory element (initial system event logs being captured can be stored in limited firmware memory and additional system event logs are then generated by the operating system and can be stored in a hard drive, col. 6 lines 44-67).
In regard to claim 10, Huang et al. teach the RDC of claim 8, wherein each of the entries includes an error code for the associated error (event logs include pre-defined, cognizable events, col. 6 lines 13-43).
In regard to claim 11, Huang et al. teach the RDC of claim 10, wherein each of the entries further includes additional information and a boot stage for the associated error (system event logs can be generated throughout different phases of the computing system’s initialization, col. 6 lines 44-67).
In regard to claim 12, Huang et al. teach the RDC of claim 8, wherein an overflow condition of the first memory element is indicated based on a determination that the first memory element is full (initial system event logs being captured can be stored in limited firmware memory and additional system event logs are then generated by the operating system and can be stored in a hard drive, col. 6 lines 44-67).
In regard to claim 15, Huang et al. teach a processing system comprising: one or more controllers configured to:
execute read only memory (ROM) code (the firmware ROM is a basic input output system (BIOS) ROM, col. 2 lines 39-50); and
detect errors within the ROM code during a boot process (crashes during a boot session, col. 6 lines 13-43); and
ROM control circuitry configured to:
generate error information based on the errors and store the error information within a first memory element, wherein the error information includes entries, and each of the entries associated with a respective one of the errors (event logs include pre-defined, cognizable events, col. 6 lines 13-43); and
generate debug information based on the errors and store the debug information within a second memory element (debug information can include minute details of a computing system’s operations that do not readily lend to a cognizable pattern, col. 6 lines 13-43), wherein the error information and debug information are output from the processing system based on a test instruction (system runtime output can include debug information and event logs, col. 7 lines 33-52).
Huang et al. does not explicitly teach wherein the debug information comprises a debug entry comprising header information and payload arguments, wherein the header information comprises a data length entry, a log code, and a boot stage associated with the boot process.
Xie et al. teach of a generating debugging information as debug code (para. 26). The debug code may take on a variety of forms where an addressing scheme whereby a message that includes a message header and message body … the debug code might indicate the last POST instruction completed or some other fashion the progress of the start up (para. 28).
Refer to claim 1 for motivational statement.
Huang et al. and Xie et al. does not explicitly teach wherein the payload arguments correspond to debug values and a number of the payload arguments corresponds to a length in words of the data length entry, and the payload arguments are associated with the debug entry and outputting as a command string, wherein the debug information is generated by mapping, via a lookup table in the test circuitry, a log command associated with the debug information in the command string, the command string comprising identifiers that are updated based on an order of the payload arguments within the debug entry.
Subramanian et al. teach of using similar format of a read command, a debug command may be directed to a particular debug data by specifying one or more logical addresses within a debug namespace. A table 1050 that specifies such a mapping of a debug namespace 1010 to different debug data (para. 69). A debug command may be used identify the debug data to be generated (e.g., by using a lookup table that may be similar to table 1050)(para. 70-71, 74-76). The identifiers is equated to different logical address ranges corresponding to different debug data (fig. 10C, A-G, para. 69). A debug application 1014 or 922 may have a similar table so that debug command may be generated that specify the desired debug data using logical addresses in a manner that is compatible with a common driver and that allow on-chip debug circuits to identify the debug data to be generated and returned (para. 70). It is noted that applicant’s specification describes the debug information is stored via a command string, para. 51, and in the lookup table, the log command is translated to the command string, para. 52.
Refer to claim 1 for motivational statement.
Huang et al. and Xie et al. does not explicitly teach the debug information as a command string, wherein the debug information is generated by mapping, via a lookup table in the test circuitry, a log command associated with the debug information in the command string, the command string comprising one or more identifiers that is updated based on the payload arguments.
Subramanian et al. teach of using similar format of a read command, a debug command may be directed to a particular debug data by specifying one or more logical addresses within a debug namespace. A table 1050 that specifies such a mapping of a debug namespace 1010 to different debug data (para. 69). A debug command may be used identify the debug data to be generated (e.g., by using a lookup table that may be similar to table 1050)(para. 70-71, 74-76). It is noted that applicant’s specification describes the debug information is stored via a command string, para. 51, and in the lookup table, the log command is translated to the command string, para. 52.
Refer to claim 1 for motivational statement.
In regard to claim 16, Huang et al. teach the processing system of claim 15, wherein the second memory element is a circular memory element (debug information includes first and second debug information and the first debug information stored on the first memory device is partially overwritten by the second debug information, col. 2 lines 22-38) and the first memory element is a non-circular memory element (initial system event logs being captured can be stored in limited firmware memory and additional system event logs are then generated by the operating system and can be stored in a hard drive, col. 6 lines 44-67).
In regard to claim 17, Huang et al. teach the processing system of claim 15, wherein each of the entries includes an error code for the associated error (event logs include pre-defined, cognizable events, col. 6 lines 13-43).
In regard to claim 18, Huang et al. teach the processing system of claim 17, wherein each of the entries further includes additional information and a boot stage for the associated error (system event logs can be generated throughout different phases of the computing system’s initialization, col. 6 lines 44-67).
In regard to claim 19, Huang et al. teach the processing system of claim 15, wherein an overflow condition of the first memory element is indicated based on a determination that the first memory element is full (initial system event logs being captured can be stored in limited firmware memory and additional system event logs are then generated by the operating system and can be stored in a hard drive, col. 6 lines 44-67).
****************************
Claims 6-7, 13-14 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Huang et al. (US 11,275,638) in further view of Xie et al. (US 2017/0083427) in further view of Subramanian et al. (US 2019/0259465) in further view of Ashmore (US 2008/0201616).
In regard to claim 6, Huang et al. does not explicitly teach the method of claim 1, each of the plurality of debug entries includes a respective header comprising a data length entry, a log code, a boot stage, and associated payload arguments.
Xie et al. teach of a generating debugging information as debug code (para. 26). The debug code may take on a variety of forms where an addressing scheme whereby a message that includes a message header and message body … the debug code might indicate the last POST instruction completed or some other fashion the progress of the start up (para. 28).
It would have been obvious to modify the method of Huang et al. by adding Xie et al. debug code output. A person of ordinary skill in the art before the effective filing date of the claimed invention would have been motivated to make the modification because it would aid in rendering it for display in a variety of forms (para. 26-28).
Huang et al., Xie et al. and Subramanian et al. does not explicitly teach wherein the debug information includes a plurality of debug entries, comprising the debug entry.
Ashmore teaches of a debug log containing timestamps for each print statement. If the firmware executes certain code paths, they are traced (para. 31, fig. 2A), boot log which contains messages indicating various stages reached during the boot process (para. 34, fig. 2C). An example listing of an event log 174 (fig. 2B, event ID and Code, para. 30-34).
It would have been obvious to modify the method of Huang et al., Xie et al. and Subramanian et al. by adding Ashmore enhanced failure analysis capability. A person of ordinary skill in the art before the effective filing date of the claimed invention would have been motivated to make the modification because it would aid in communicating the (failure analysis information) FAI in order to analyze the failure (para. 29).
In regard to claim 7, Huang et al. does not explicitly teach the method of claim 6, wherein the log command comprises the log code, the boot stage, and the payload arguments.
Xie et al. teach of a generating debugging information as debug code (para. 26). The debug code may take on a variety of forms where an addressing scheme whereby a message that includes a message header and message body … the debug code might indicate the last POST instruction completed or some other fashion the progress of the start up (para. 28).
Refer to claim 6 for motivational statement.
In regard to claim 13, Huang et al. does not explicitly teach the RDC of claim 8, each of the plurality of debug entries includes a respective header comprising a data length, a log code, a boot stage, and associated payload arguments.
Xie et al. teach of a generating debugging information as debug code (para. 26). The debug code may take on a variety of forms where an addressing scheme whereby a message that includes a message header and message body … the debug code might indicate the last POST instruction completed or some other fashion the progress of the start up (para. 28).
Refer to claim 6 for motivational statement.
Huang et al., Xie et al. and Subramanian et al. does not explicitly teach wherein the debug information includes a plurality of debug entries comprising the debug entry.
Ashmore teaches of a debug log containing timestamps for each print statement. If the firmware executes certain code paths, they are traced (para. 31, fig. 2A), boot log which contains messages indicating various stages reached during the boot process (para. 34, fig. 2C). An example listing of an event log 174 (fig. 2B, event ID and Code, para. 30-34).
Refer to claim 6 for motivational statement.
In regard to claim 14, Huang et al., Xie et al. and Subramanian et al. does not explicitly teach the RDC of claim 13, the log command comprises the log code, the boot stage, and the payload arguments.
Xie et al. teach of a generating debugging information as debug code (para. 26). The debug code may take on a variety of forms where an addressing scheme whereby a message that includes a message header and message body … the debug code might indicate the last POST instruction completed or some other fashion the progress of the start up (para. 28).
Refer to claim 6 for motivational statement.
In regard to claim 20, Huang et al. does not explicitly teach the processing system of claim 15, each of the plurality of debug entries includes a respective header comprising a data length entry, a log code, a boot stage, and associated payload arguments.
Xie et al. teach of a generating debugging information as debug code (para. 26). The debug code may take on a variety of forms where an addressing scheme whereby a message that includes a message header and message body … the debug code might indicate the last POST instruction completed or some other fashion the progress of the start up (para. 28).
Refer to claim 1 for motivational statement.
Huang et al., Xie et al. and Subramanian et al. does not explicitly teach wherein the debug information includes a plurality of debug entries, and wherein the debug information includes a plurality of debug entries, and
Ashmore teaches of a debug log containing timestamps for each print statement. If the firmware executes certain code paths, they are traced (para. 31, fig. 2A), boot log which contains messages indicating various stages reached during the boot process (para. 34, fig. 2C). An example listing of an event log 174 (fig. 2B, event ID and Code, para. 30-34).
Refer to claim 6 for motivational statement.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See PTO 892.
Liu (US 12,450,007) command trigger log specific debugging information
Sethi et al. (US 2024/0152442) failure prediction and troubleshooting
Pandurangan et al. (US 11,822,490) debug logs
Talvitie (US 2024/0044979) debug architecture
************************
Tapus et al. (US 2023/0339102) lookup table that matches the respective hardware level commands
Peng et al. (US 2020/0158778) table lookup and convert debug requestion into commands operations
McFadden et al. (US 8,843,895) debug manager code and look-up table
************************
Moshe et al. (US 2023/0401321) collect boot logs, debug logs (para. 13)
Hillier (US 9,753,823) debug unit with data payload preceded by a signal header
Reeve et al. (US 2020/0344112) debug an application with a header and a payload portion (para. 76)
Kurts et al. (US 2015/0278058) debug information module may collect, arrange, organize or summarize the data gathered (par. 48) display in proper format (para. 49)
Usgaonkar et al. (US 10,078,113) Xilinx, debug data and JTAG link
Menon et al. (US 9,632,895) packetized debug data
Ansari et al. (US 10,896,119) Xilinx, each debug packet includes a header and optional payload and a CRC field
************************
Vidyadhara et al. (US 11,726,880) debug analysis during a boot process
Moshe et al. (US 2022/0164139) firmware generate debug data and device logs
Menon et al. (US 2019/0042391) debug information include trace logs
Kim et al. (US 2019/0012465) debug register for boot process
Datta et al. (US 2017/0083393) debug during boot process
Conner et al. (US 2015/0186232) debug messages and trace logs
Hormuth et al. (US 2013/0325998) debug port storage
Fai et al. (US 2013/0007348) debug firmware generate error logs and debug info
Yodaiken et al. (US 2006/0282815) boot process display trace data to developer
Madden et al. (US 6,996,706) monitoring boot process for debug
Rothman et al. (US 2005/0289333) comprehensive log of pre-boot data
Marsland (US 6,289,448) debug a boot process
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LOAN TRUONG whose telephone number is 408-918-7552. The examiner can normally be reached on 10AM-6PM PST M-F.
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, Thomas Ashish can be reached on 571-272-0631. 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.
/Loan L.T. Truong/Primary Examiner, Art Unit 2114 Loan.truong@uspto.gov