DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is in response to the amendment filed July 1, 2026.
Claims 1,2,4-7,9, and 10 are pending.
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Response to Arguments
Applicant's arguments filed July, 1, 2026 have been fully considered but they are not persuasive.
Regarding the interpretations under §112(f) the Examiner agrees the amendments correct the interpretation issues at question and the interpretation is withdrawn.
Regarding the rejection under §103, the Examiner again respectfully disagrees. Specifically, In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). Here, Applicant makes several pages of arguments against rejection mappings the Examiner did not apply, but fails to address those specifically set forth with respect to the contested limitations. Specifically, regarding the limitations newly added to the independent claims, the Examiner set forther specific citations to Suzuki ¶¶47-48, ¶¶59-62 regarding the receiving of start and ending execution ticks which are subtracted, and further ¶35 of Rajagopal teaching dividing execution spans by a processor speed value. Further, regarding the processing and timing of the interrupt, Yim teaches measuring tick values of processing time of the system ¶¶46-48, and further Yim e.g. 706 Fig. 7A and 806 Fig. 8 teaches the CPU continuing to execute the next instructions after processing of cpus stops at breakpoints) As Applicant’s arguments are not persuasive in addressing this specific proposed combination, the rejection is respectfully maintained.
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,2,5,9, and 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Yim”(US PG Pub 2007/0266376) in view of “Suzuki” (US PG Pub 2015/0339208) and further in view of “Rajagopal” (US PG Pub 2002/0143998).
Regarding Claim 1, Yim teaches;
1. A debug device, comprising: a communicator including a physical communication interface configured to communicate with debug interface of a storage device; (See e.g. 518 Fig. 5, ¶51 teaching a hardware debugger system with a jtag interface to interface with a target system)
an interrupt signal generation circuit coupled to the communicator configured to output, when a request to measure an operation time for an instruction is received, an interrupt signal for controlling an interrupt operation of a processor cored included in the storage device through the communicator; (300, Fig. 3, 314, ¶44 Yim teaches a system for setting breakpoints including hardware/software interrupts for debugging including measuring tick values of processing time of the system ¶¶46-48).
a tick count detection circuit coupled to the communicator configured to: receive first tick counts respectively (Yim teaches measuring tick values of processing time of the system ¶¶46-48).
and receive second tick counts respectively (Yim teaches measuring tick values of processing time of the system ¶¶46-48).
wherein the interrupt operation is performed in response to the interrupt signal, and the instruction is executed after the interrupt operation is completed.(Yim e.g. 706 Fig. 7A and 806 Fig. 8 teaches the CPU continuing to execute the next instructions after processing of cpus stops at breakpoints)
wherein the first tick counts are generated by the interrupt operation performed prior to the execution of the instruction in response to the request (Yim teaches measuring tick values of processing time of the system ¶¶46-48, further Yim e.g. 706 Fig. 7A and 806 Fig. 8 teaches the CPU continuing to execute the next instructions after processing of cpus stops at breakpoints)
Yim does not explicitly teach, but Suzuki teaches:
corresponding to a start time point and an end time point of the interrupt operation through the communicator, (see e.g. ¶¶45-50 teaches a process of recording start and end times for the various processes including the interrupting processes as illustrated further in e.g. Fig. 6)
corresponding to a start time point and an end time point of executing the instruction through the communicator; (see e.g. ¶¶45-50 teaches a process of recording start and end times for the various processes including the interrupting processes as illustrated further in e.g. Fig. 6; e.g. in Fig. 6, ¶¶57-62 teaches recording of times for start and end of interrupts and restarting of processes (e.g. SL2) after interrupt is completed)
and a calibration circuit configured to determine the operation time using the first tick counts and the second tick counts. (Suzuki ¶¶47-48, ¶¶59-62 teaches adding and subtracting the recorded start and stop execution times of the different processes to determine the actual execution time of the process).
wherein the calibrator determines the operation time by: acquiring a subtraction value by subtracting a difference between the first tick counts from a difference between the second tick counts, (Suzuki ¶¶47-48, ¶¶59-62 teaches adding and subtracting the recorded start and stop execution times of the different processes to determine the actual execution time of the process). In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date of the application to combine the teachings of Yim and Suzuki as each is directed to performance debugging systems and Suzuki recognized “an accurate execution time of the interrupted process cannot be measured unless the execution time of the other process is subtracted from the time measured by the hardware timer” (¶6).
Suzuki does not teach, but Rajagopal teaches:
and acquiring the operating time by dividing the subtraction value by a speed of the processor core received through the communicator. (Rajagopal e.g. ¶35 teaches dividing tick values by the processor values to accommodate for different processor speeds in calculating processing time; see further e.g. ¶¶32-34)
In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date of the application to combine the teachings of Yim and Rajagopal as each is directed to retrieving and maintaining tick count values and Rajagopal recognized a method by which ” the difference in processor speed can quickly be accommodated.” (¶35).
Regarding Claim 2, Yim et al teach the limitations of claim 1 above, but do not further teach, while Rajagopal teaches:
2. The debug device according to claim 1, wherein the interrupt operation is an operation in which a processor core of the storage device stores tick counts in a register of the storage device. (Rajagopal ¶14 teaches storing tick values in a processor register for retrieval)
in addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date of the application to combine the teachings of Yim and Rajagopal as each is directed to retrieving and maintaining tick count values and Rajagopal recognized use of registers to store tick values allows the values to be “updated at the speed of the microprocessor. The value can be read from the register with a standard, simple, assembly language instruction.” (¶14).
Regarding Claim 5, Yim further teaches:
5. The debug device according to claim 1, wherein the communicator is configured to communicate with the debug interface according to a joint test action group (JTAG) standard. (See 518, Fig. 5, ¶¶50-51 of Yim teaches use of a JTAG based debug interface for debugging the target system)
Regarding Claim 9, Yim further teaches:
A debug method, comprising: transmitting, when a request to measure an operation time for an instruction is received, an interrupt signal for controlling an interrupt operation to a controller of a storage device through a debug interface of the storage device; (300, Fig. 3, 314, ¶44 Yim teaches a system for setting breakpoints including hardware/software interrupts for debugging including measuring tick values of processing time of the system ¶¶46-48).
performing, by the processor core, the interrupt operation of storing tick counts in a register included in the controller; (Yim teaches measuring tick values of processing time of the system ¶¶46-48).
acquiring first tick counts (Yim teaches measuring tick values of processing time of the system ¶¶46-48).
acquiring second tick counts (Yim teaches measuring tick values of processing time of the system ¶¶46-48).
executing, by the processor core, the instruction after the interrupt operation is completed (Yim e.g. 706 Fig. 7A and 806 Fig. 8 teaches the CPU continuing to execute the next instructions after processing of cpus stops at breakpoints).
and executing, by the processor core, the instruction after the interrupt operation is completed. (Yim ¶¶44-46 describe setting breakpoints which include interruption of the executing tasks as illustrated in e.g. fig. 4, including resumption of the tasks after the interruption handler completion; and further see 706 Fig. 7A and 806 Fig. 8)
wherein the first tick counts are generated by the interrupt operation performed prior to the execution of the instruction in response to the request (Yim teaches measuring tick values of processing time of the system ¶¶46-48, further Yim e.g. 706 Fig. 7A and 806 Fig. 8 teaches the CPU continuing to execute the next instructions after processing of cpus stops at breakpoints)
Yim does not explicitly teach, but Suzuki teaches:
respectively corresponding to a start time point and an end time point of the interrupt operation through the debug interface; (see e.g. ¶¶45-50 teaches a process of recording start and end times for the various processes including the interrupting processes as illustrated further in e.g. Fig. 6)
respectively corresponding to a start time point and an end time point of executing the instruction through the debug interface; (see e.g. ¶¶45-50 teaches a process of recording start and end times for the various processes including the interrupting processes as illustrated further in e.g. Fig. 6)
and determining the operation time using the first tick counts and the second tick counts. (Suzuki ¶¶47-48, ¶¶59-62 teaches adding and subtracting the recorded start and stop execution times of the different processes to determine the actual execution time of the process).
wherein the determining the operating time comprises: obtaining a subtraction value by subtracting a difference between the first tick counts from a difference between the second tick counts; (Suzuki ¶¶47-48, ¶¶59-62 teaches adding and subtracting the recorded start and stop execution times of the different processes to determine the actual execution time of the process). In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date of the application to combine the teachings of Yim and Suzuki as each is directed to performance debugging systems and Suzuki recognized “an accurate execution time of the interrupted process cannot be measured unless the execution time of the other process is subtracted from the time measured by the hardware timer” (¶6).
Suzuki does not teach, but Rajagopal teaches:
and acquiring the operating time by dividing the subtraction value by a speed of the processor core. (Rajagopal e.g. ¶35 teaches dividing tick values by the processor values to accommodate for different processor speeds in calculating processing time; see further e.g. ¶¶32-34))
In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date of the application to combine the teachings of Yim and Rajagopal as each is directed to retrieving and maintaining tick count values and Rajagopal recognized a method by which “the difference in processor speed can quickly be accommodated.” (¶35).
Regarding Claim 10, Yim further teaches:
10. The debug method according to claim 9, further comprising: suspending, by a processor core, all operations, which are performed in the controller, in response to the interrupt signal; (Yim ¶¶44-46 describe setting breakpoints which include interruption of the executing tasks as illustrated in e.g. fig. 4)
the interrupt operation is an operation in which the processor core of storing tick counts in a register included in the controller; (Yim teaches measuring tick values of processing time of the system ¶¶46-48).
Claim(s) 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Yim”(US PG Pub 2007/0266376) in view of “Suzuki” (US PG Pub 2015/0339208) further in view of “Rajagopal” (US PG Pub 2002/0143998) as applied above and further in view of “Kim” (US PG Pub 2019/00227907).
Regarding Claim 4, Yim et al teach the limitations of claim 1 above but do not further teach, while Kim teaches:
4. The debug device according to claim 1, wherein the communicator is coupled to an additional debug interface different from a host interface coupled to a host device among a plurality of ports included in the storage device. (See Kim 160, Fig. 6, ¶¶4,8 Kim teaches a debugging port of the storage device 100 coupled to the debug device 300 separate from ports connected to host 200, including ports of the storage device described in Fig. 5a/5b, ¶40).
In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date of the application to combine the teachings of Yim and Kim as each is directed to debugging systems and Kim recognized with ever increasing computer performance “A separate debugging technique for extracting error information may be used to detect or correct such errors” (¶4).
Claim(s) 6 and 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Blaine” (US PG Pub 2013/0212425) in view of (“Yim”(US PG Pub 2007/0266376) and “Suzuki” (US PG Pub 2015/0339208) and further in view of “Rajagopal” (US PG Pub 2002/0143998).
Regarding Claim 6, Blaine teaches:
6. A debug system, comprising:
a storage device including a memory device, a controller configured to control the memory device, and a debug interface; (Blaine Fig. 2, 202, Fig. 2 213, 212, debug interface 205, fig 2. ¶25)
a debug device (Blaine 215, Fig. 2 ¶27)
and a host device configured to: output the request to the debug device, (Blaine 217, Fig. 2 teaches e.g. issuing commands to debugger device 215 in ¶25)
Blaine does not explicitly teach, but Yim teaches:
configured to output, when a request to measure an operation time for an instruction is received, an interrupt signal for controlling an interrupt operation to the controller through the debug interface, (300, Fig. 3, 314, ¶44 Yim teaches a system for setting breakpoints including hardware/software interrupts for debugging including measuring tick values of processing time of the system ¶¶46-48).
acquire first tick counts (Yim teaches measuring tick values of processing time of the system ¶¶46-48)
acquire second tick counts (Yim teaches measuring tick values of processing time of the system ¶¶46-48)
wherein the interrupt operation is performed in response to the interrupt signal, and the instruction is executed after the interrupt operation is completed.(Yim e.g. 706 Fig. 7A and 806 Fig. 8 teaches the CPU continuing to execute the next instructions after processing of cpus stops at breakpoints)
wherein the first tick counts are generated by the interrupt operation performed prior to the execution of the instruction in response to the request (Yim teaches measuring tick values of processing time of the system ¶¶46-48, further Yim e.g. 706 Fig. 7A and 806 Fig. 8 teaches the CPU continuing to execute the next instructions after processing of cpus stops at breakpoints)
In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date of the application to combine the teachings of Blaine with those of Yim as each is directed to debugging systems and Yim recognized “conventional hardware debugging technique cannot provide advanced debugging capabilities such as a debugging capability for securing stability, which is valued in the course of software development, such as a debugging of temporarily occurring transient faults. The temporary faults can be caused by an asynchronous control flow, such as interrupt, and synchronizing and communication between tasks” (¶12).
Blaine further does not teach but Suzuki teahes:
…respectively corresponding to a start time point and an end time point of the interrupt operation through the debug interface, …(see e.g. ¶¶45-50 teaches a process of recording start and end times for the various processes including the interrupting processes as illustrated further in e.g. Fig. 6)
…respectively corresponding to a start time point and an end time point of executing the instruction through the debug interface, and output the first tick counts and the second tick counts; (see e.g. ¶¶45-50 teaches a process of recording start and end times for the various processes including the interrupting processes as illustrated further in e.g. Fig. 6)
and determine the operation time using the first tick counts and the second tick counts received from the debug device as a response to the request. (Suzuki ¶¶47-48, ¶¶59-62 teaches adding and subtracting the recorded start and stop execution times of the different processes to determine the actual execution time of the process).
wherein the determining the operating time comprises: obtaining a subtraction value by subtracting a difference between the first tick counts from a difference between the second tick counts; (Suzuki ¶¶47-48, ¶¶59-62 teaches adding and subtracting the recorded start and stop execution times of the different processes to determine the actual execution time of the process). In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date of the application to combine the teachings of Yim and Suzuki as each is directed to performance debugging systems and Suzuki recognized “an accurate execution time of the interrupted process cannot be measured unless the execution time of the other process is subtracted from the time measured by the hardware timer” (¶6).
Suzuki does not teach, but Rajagopal teaches:
and acquiring the operating time by dividing the subtraction value by a speed of the processor core. (Rajagopal e.g. ¶35 teaches dividing tick values by the processor values to accommodate for different processor speeds in calculating processing time; see further e.g. ¶¶32-34)
In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date of the application to combine the teachings of Yim and Rajagopal as each is directed to retrieving and maintaining tick count values and Rajagopal recognized a method by which “the difference in processor speed can quickly be accommodated.” (¶35).
Regarding Claim 7, Yim further teaches:
7. The debug system according to claim 6, wherein the controller comprises: a processor core configured to perform the interrupt operation and execute the instruction; (300, Fig. 3, 314, ¶44 Yim teaches a system for setting breakpoints including hardware/software interrupts for debugging including measuring tick values of processing time of the system ¶¶46-48) In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date of the application to combine the teachings of Blaine with those of Yim as each is directed to debugging systems and Yim recognized “conventional hardware debugging technique cannot provide advanced debugging capabilities such as a debugging capability for securing stability, which is valued in the course of software development, such as a debugging of temporarily occurring transient faults. The temporary faults can be caused by an asynchronous control flow, such as interrupt, and synchronizing and communication between tasks” (¶12).
Blaine et al do not teach, but Rajagopal teaches:
and a register configured to store the first tick counts and the second tick counts through the processor core, and wherein the interrupt operation is an operation in which the processor core stores the tick counts in the register. (Rajagopal ¶14 teaches storing tick values in a processor register for retrieval)
in addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date of the application to combine the teachings of Yim and Rajagopal as each is directed to retrieving and maintaining tick count values and Rajagopal recognized use of registers to store tick values allows the values to be “updated at the speed of the microprocessor. The value can be read from the register with a standard, simple, assembly language instruction.” (¶14).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. The previous PTO-892 form includes prior art relevant to applicant’s disclosures related to interrupt signal generator systems for us in debug devices systems.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MATTHEW J BROPHY whose telephone number is (571)270-1642. The examiner can normally be reached Monday-Friday, 9am-4:30pm.
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 on 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.
MJB
7/23/2026
/MATTHEW J BROPHY/ Primary Examiner, Art Unit 2191
Prosecution Insights