DETAILED ACTION
The Office Action is in response to claims filed 07/29/2026.
The objection to claim 9 has been withdrawn in view of the applicant’s amendments to claim 9.
Claims 1-20 are pending.
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 .
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1 and 11 are rejected under 35 U.S.C. 103 as being unpatentable over US 20110191752 Al hereinafter "Cleraux" in view of US 20100325359 A1 hereinafter "Goel" in view of US 20230130429 A1 hereinafter “Lee” and further in view of US 20220206806 A1 hereinafter “Wang”.
With regards to claim 1, Cleraux teaches
establishing a communication link between a target device and host device; (Cleraux
[0039]," Turning to the system, 300, in addition to the target device 320, the system 300
includes a server 330 and a host device 310 in communication with the target device 320 via the
server 350. While the server 330 is illustrated in FIG. 3 as the link between the host 310 and the
target 320, it should be noted that the functions of the server 330 may be incorporated within the
host 310, itself. In other words, the host 310 may communicate directly with the target 320.
Accordingly, the depiction of the host 310 and server 330 in FIG. 3 as a separate entity is merely
for illustrative purposes, and is not intended to limit the configurations and components of any
embodiments of the system 300.")
receiving a set breakpoint command at the target device; (Cleraux [0016], “Furthermore, the exemplary embodiments may allow a user to call a routine with an arbitrary set of parameters on a target, and the debugging agent on the target may perform the call. Specifically, the debugging agent on the target [at the target device] may parse byte code stream received from a host debugger, prepare a stack frame, perform the call, and provide a return value to the host debugger [receiving a set breakpoint command].") [Examiner's Note: A user can perform a call as a command which is received at the target device in order to set a breakpoint therein.]
in response to the received set breakpoint command, setting a breakpoint associated with execution of software at the target device; (Cleraux [0026-27], “The target 120 may operate using a user code, which comprises a program running in an operating system or a stand-alone program. The user code may be written in any programming language (e.g., C/C++, Java, Assembly language, etc.). The user code may be any program that the developer desires to run on the target 120 … According to the exemplary embodiments described herein, the user may set one or more conditional breakpoints. Specifically, the user may describe the condition that is necessary to trigger the conditional breakpoint, as well as the additional instructions to be performed if the conditions of the breakpoint are met (e.g., if the breakpoint is triggered, or "hit"). Thus, the breakpoint evaluation code may allow the condition to be monitored on the target side and inform the host 110 (e.g., via the server 130) when the breakpoint hit event occurs.”)
identifying a breakpoint hit at the target device during the execution of the software; (Cleraux [0035-36], “Thus, at this point in the process the monitoring for the defined conditional breakpoints is placed under the control of the debugging agent 126, meaning that the host 110 does not need to remotely monitor the running code for breakpoints. As described above, this greatly decreases the amount of communications needed between the target 120 and the host 110 during the debugging process. Those of skill in the art will understand that this does not necessarily mean that the host 110 will not monitor for any breakpoints, but merely that the debugging agent 126 will monitor for those specific conditional breakpoints that have been defined by the developer and the generated byte code expression has been sent to the debugging agent 126. In step 270, the debug agent 126 on the target 120 may evaluate the generated byte code expression. In other words, the debug agent 126 may determine whether or not the condition of the conditional breakpoint has been met. If the condition is met, the method may advance to step 280.”) [Examiner’s Note: A debugging agent may be located on the target device. Thus it will be able to identify a hit during software execution]
Cleraux teaches the target device but does not teach: receiving a callback routine
creation command at the target device;
creating, in response to the received callback routine creation command, a callback
routine in a callback memory space included in memory of the target device;
However, in an analogous art Goel teaches receiving a callback routine creation
command at the target device; (Goel [0073], "The tracing method can include the operation of
obtaining a machine instruction for a computer program from a computer memory, as in block
510. Alternatively, the machine instructions can be supplied by an instruction callback module or
a debugging application to the instruction decoding module. The machine instruction can be
decoded into an opcode and operands, as in block 520.")
creating, in response to the received callback routine creation command, a callback
routine in a callback memory space included in memory of the target device; (Goel [0065-
68], "A dataflow primitive engine 330 is configured to categorize the machine instructions (or
opcodes) received from the decoding module 320 into one of a plurality of dataflow primitive
classifications. The dataflow primitive engine can then generate one or more dataflow primitives
for each machine instruction received [creating, in response to the received callback routine
creation command, a callback routine] A second caching level may include the caching of
data flow primitives generated for the opcodes. This caching can include the caching one or more
primitive instructions that are associated with each machine instruction in a dataflow primitive
sub-table 354. The dataflow primitives stored in the cache can be associated with and looked up
by the instruction address 352 and/or the opcode 356. The dataflow primitive sub-table 354 is
configured to cache grouped primitives that have already been generated for individual machine
instructions in order to enable re-use of the grouped primitives on the dataflow state table each
time the same machine instruction is executed. The caching of the primitives may include the
caching of operand data fields, operand bit-masks, and pointers to lookup and/or update
operations by instruction address, as desired [in a callback memory space included in memory of
the target device].") [Examiner's Note: Callback instructions can be provided by an instruction
callback module which initiates the generation of a dataflow primitive that is cached in an
allocated piece of memory (primitive sub-table). A dataflow primitive is described as an
operational instruction which is analogous to a callback function]
Therefore, it would have been obvious to one of ordinary skill in the art before the
effective filing date of the claimed invention to have incorporated the teachings of Goel into the
teachings of Cleraux. This combination of teachings would have resulted in a method for
scripting a breakpoint on a target device, as in Cleraux, with the generation of dataflow
primitives that are generated and stored in accordance with intended tracking of dataflow
associated with machine instructions, as in Goel. One of ordinary skill in the art would have been
motivated to combine these teachings for the purpose of tracking dataflow or untrusted data
throughout the debugging or program tracing playback to view the untrusted data uses and
influences (Goel [0017]).
The combination of Cleraux and Goel does not teach: in response to the identified breakpoint hit, (i) saving a breakpoint context, (ii) invoking the callback routine stored in the callback memory space, and (iii) upon completion of execution of the callback routine, clearing the breakpoint, restoring the breakpoint context, and continuing execution of the software.
However, in an analogous art Lee teaches in response to the identified breakpoint hit, (i) saving a breakpoint context, (Lee [0060], “ For example, referring to FIG. 2, when it meets a break instruction (break.instr) while executing the program, the target processor may suspend execution of the program, store the address value (the PC value) of the break instruction (break.instr) in the internal debug.PC register thereof, and execute the code of the handler program (break.handler). Subsequently, in the handler program (break .handler), context data, such as the content of general-purpose registers, a stack, debug.PC, and the like of the target processor immediately before the break instruction (break .instr) is executed, may be stored in the context memory buffer (debug.context). Here, using the value of Core.ID corresponding to the target processor, the context data may be stored at the location assigned to the target processor in the debug.context memory buffer.”)
[…] and (iii) upon completion of execution of the callback routine, clearing the breakpoint (Lee, [0103], “Subsequently, the IRQ is cleared such that the handler program (break.handler) is terminated, and after the handler program (break.handler) is terminated, the instruction at the address indicated by the value of debug.PC is executed, whereby the control flow may be returned to the instruction at the address indicated by the value of debug.PC at step S718.”)
[…] and continuing execution of the software. (Lee [0067-68], “For example, break.handler illustrated in FIG. 2 sets the value of debug.PC as the PC value in a hardware manner after the operation thereof is finished, whereby the control flow may be returned to the instruction at the location corresponding to the address value stored in debug.PC. Subsequently, the target processor resumes execution of the program using the program execution binary, and may continue execution of instructions until it meets break.instr.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Lee into the teachings of Cleraux in view of Goel. This combination of teachings would have resulted in a method for scripting a breakpoint on a target device, as in Cleraux, with the generation of dataflow primitives that are generated and stored in accordance with intended tracking of dataflow associated with machine instructions, as in Goel, by using a debugging interrupt at a breakpoint to execute any debugging software therein, as in Lee. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of inserting debug execution code at a breakpoint set by a user for debugging an execution binary of a program (Lee [0049]).
The combination of Cleraux, Goel, and Lee teaches: in response to the identified breakpoint hit, (i) saving a breakpoint context, (iii) upon completion of execution of the callback routine, clearing the breakpoint and continuing execution of the software but does not teach: [in response to the identified breakpoint hit, (i) saving a breakpoint context,] (ii) invoking the callback routine stored in the callback memory space, [and (iii) upon completion of execution of the callback routine, clearing the breakpoint,] restoring the breakpoint context, [and continuing execution of the software.]
However, in an analogous art Wang teaches […] (ii) invoking the callback routine stored in the callback memory space, (Wang [0043], “In yet another embodiment, an interrupt pre-processing unit (for example, the microcode control unit 460 is constructed as an interrupt pre-processing unit, or the interrupt control unit under the RISC/RISC-V architecture is modified as an interrupt pre-processing unit) may be used to invoke a corresponding interrupt service program to call the simulation module 122 when a NOP instruction corresponding to the ready-for-execution instruction 132 (currently an extended instruction) is retired. In one embodiment, the interrupt pre-processing unit may be microcode stored in a ROM (Read Only Memory) or codes programmed by PLA (Programmable Logic Array). In an embodiment, a system call of requesting the operating system 120 to activate the simulation module 122 may be applied by means of interrupts as aforementioned. Specifically, the simulation module 122 may be programmed as a callback function and the ready-for-execution instruction 132 (or only its format information) may be sent as parameters to this callback function. And, after this programmed callback function implements the conversions and executions of the simulation program corresponding to the ready-for-execution instruction 132, this callback function may store associated execution result in the simulation-execution-result store region 1246 and then inform the processor 110 of retrieving the stored execution result therefrom.”) restoring the breakpoint context, […] (Wang [0083], “In step S714, the simulation module 112 executes the simulation program. As previously described, all the information generated in the execution processes of block 714 may be stored in the simulation-execution-result store region 1246 through the address indicated by the simulation-execution-result pointer register 116C. Please note that the simulation execution result generated by the simulation program is remained in the simulation-execution-result store region 1246. In step S716, a notification regarding simulation completion is set in the simulation-execution-result store region 1246 so as to inform the processor 110 of resuming/restoring the pre-stored context (that is, the context-related execution parameters of the processor 110 pre-stored in the state stack of the processor-current-state store region 1242 before the simulation module 122 is invoked is read/obtained from the address indicated by the processor-current-state pointer register 116A). The processor 110 then quits the simulation module 122 and terminates associated simulation operations for the extended instruction.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Wang into the teachings of Cleraux in view of Goel and further in view of Lee. This combination of teachings would have resulted in a method for scripting a breakpoint on a target device, as in Cleraux, with the generation of dataflow primitives that are generated and stored in accordance with intended tracking of dataflow associated with machine instructions, as in Goel, by using a debugging interrupt at a breakpoint to execute any debugging software therein, as in Lee, and executing the debugging software as a callback function, as in Wang. to One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of saving the state of the program execution before executing the callback function for additional instructions (Wang [0058]).
Claim 11 is directed to an electronic device corresponding to the method as disclosed in claim 1. Thus, claim 11 is rejected for the same reasons set forth in claim 1.
Claims 2, 8, 12, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Cleraux in view of Goel in view of Lee in view of Wang as applied to claims 1 and 11 above, and further in view of US 20110126175 A1 hereinafter "Suizu" in view of US 20030005415 A1 hereinafter "Bates".
With regards to claim 2, the rejection of claim 1 is incorporated.
The combination of Cleraux, Goel, Lee, and Wang does not teach: generating, by an exception inducing instruction, an interrupt;
identifying a breakpoint control block in an active breakpoints data structure;
However, in an analogous art Suizu teaches generating, by an exception inducing
instruction, an interrupt; (Suizu [0060], "When a program execution command is entered in
the debugging process (S105 of FIG. 3: YES), the debugging device 1 executes the program in
the program execution process (S116 of FIG. 3). When a step execution command is entered in
the debugging process (S106 of FIG. 3: YES), the debugging device 1 executes a program step in
the step execution process (S117 of FIG. 3). Subsequently, when the program counter reaches a
hardware breakpoint set in the hardware break setting registers 22 and 23, a hardware break
interrupt occurs. This calls the hardware break interrupt handler.")
identifying a breakpoint control block in an active breakpoints data structure; (Suizu [0027-28], "A hardware breakpoint table 35 in FIG. 2 is stored in the memory 3 or the
like of the debugging device 1. The hardware breakpoint table 35 stores information such as the
addresses of desired hardware breakpoints settings. A program for executing processes such as a
hardware break interrupt handler 31, a debugging process 32, a hardware breakpoint change
process 33, and a hardware breakpoint table setting process 34 illustrated in FIG. 2 is stored in
the memory 3 or the like, and is executed by the CPU When a hardware break interrupt
occurs, the hardware break interrupt handler 31 is called. The hardware break interrupt handler
31 refers to the value of the program counter 21 and information stored in the hardware
breakpoint table 35 to call the debugging process 32 or hardware breakpoint change process 33.
Specifically, if the value of the program counter 21 at the time when the hardware break interrupt
is generated matches the value of one of the hardware breakpoint addresses stored in the
hardware breakpoint table 35, the debugging process 32 is called. Conversely, if the value of the
program counter 21 at the time when the hardware break interrupt has occurred does not match
the values of any hardware breakpoint addresses stored in the hardware breakpoint table 35, the
hardware breakpoint change process 33 is called.") [Examiner's Note: When a program counter
reaches a specific value the interrupt handler uses the counter to determine the appropriate
process that needs to be invoked (breakpoint control block) as stored in the hardware breakpoint
table.]
Therefore, it would have been obvious to one of ordinary skill in the art before the
effective filing date of the claimed invention to have incorporated the teachings of Suizu into the
teachings of Cleraux in view of Goel in view of Lee and further in view of Wang. This combination of teachings would have resulted in a method for scripting a breakpoint on a target device, as in Cleraux, with the generation of dataflow primitives that are generated and stored in accordance with intended tracking of dataflow associated with machine instructions, as in Goel, by using a debugging interrupt at a breakpoint to execute any debugging software therein, as in Lee, and executing the debugging software as a callback function, as in Wang, while handling the debugging of a program using a hardware breakpoint table, as in Suizu. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of receiving an operation for debugging a software program on the debugging device (Suizu [0025]).
The combination of Cleraux, Goel, Lee, Wang, and Suizu does not teach: storing an opcode at a memory address, wherein the memory address is in a predetermined memory region of the memory and wherein the breakpoint control block stores the opcode and the memory address.
However, in an analogous art Bates teaches storing an opcode at a memory address,
wherein the memory address is in a predetermined memory region of the memory (Bates
[0072], "At step 904, the job identifier 316 is retrieved. At step 906, the breakpoint manager adds
an entry to the breakpoint list 314. The breakpoint address in memory is then computed in step
908 and the returned breakpoint address location is saved in the information table 320 at step
910. At step 912, the breakpoint is set by substituting the current instruction or OpCode 324
(operations code) with the breakpoint in memory 118. At step 914, a completion message is
returned to the command processor 206.") and wherein the breakpoint control block stores
the opcode and the memory address. (Bates [0055], "A breakpoint list 314 is created from the
plurality of job records that is to be utilized by the breakpoint manager 128 and the interrupt
handler 214. The breakpoint list 314 comprises a list of active breakpoints (i.e., breakpoints 312)
referenced to the respective job identifiers. The breakpoint list 314 references a plurality of
breakpoint information tables 318. Specifically, a first breakpoint 316 associated with JOB ID 1
points to a first breakpoint information table 320. Breakpoint information table 320 includes the
breakpoint memory address 322 where the breakpoint resides in the main memory 118 and the
original opcode 324 that was replaced by the breakpoint instruction. This original opcode 324 is
used to return the computer program 124 to its original state when a breakpoint is removed and
also to allow the breakpoint to be masked from other jobs.") [Examiner's Note: A list will have a
list ofjobs (or control blocks) the control blocks have a table wherein the breakpoints, memory
addresses, and the breakpoint information themselves.]
Therefore, it would have been obvious to one of ordinary skill in the art before the
effective filing date of the claimed invention to have incorporated the teachings of Bates into the
teachings of Cleraux in view of Goel in view of Lee in view of Wang and further in view of Suizu. This combination of teachings would have resulted in a method for scripting a breakpoint on a target device, as in Cleraux, with the generation of dataflow primitives that are generated and stored in accordance with intended tracking of dataflow associated with machine instructions, as in Goel, by using a debugging interrupt at a breakpoint to execute any debugging software therein, as in Lee, and executing the debugging software as a callback function, as in Wang, while handling the debugging of a program using a hardware breakpoint table, as in Suizu, and managing active breakpoints in accordance with the state of the program, as in Bates. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of breakpoint management in a debugger program to remove or set breakpoints depending on usefulness (Bates [0040]).
With regards to claim 8, the rejection of claim 2 is incorporated.
Cleraux does not teach: wherein the breakpoint control block comprises a plurality of
information including: instruction opcode information;
callback location information;
However, in an analogous art Goel teaches wherein the breakpoint control block
comprises a plurality of information including: instruction opcode information; (Goel
[0066-67], "The dataflow state table 340 can store addressed memory locations that are flagged
and tracked at a bitwise level. The dataflow primitives use the operands of the machine
instruction to update a dataflow status for the memory locations affected by the machine
instruction. In this embodiment, an example of a dataflow caching table 350 is configured to
cache one or more levels of information. This avoids the repeated decoding of the opcodes from
the machine instructions each time the machine instruction is executed. For a first caching level,
the opcodes associated with each machine instruction can be stored by address.")
callback location information; (Goel [0071], "The instruction being currently executed
by the computer program can be received by the dataflow tracking system via an instruction
callback interface, as illustrated by item 415. The instruction call back interface will provide an
instruction address and machine instruction to the decoding module and/or dataflow caching
table. In block 420, the instruction address can be used to perform a cache lookup. In block 430,
the dataflow tracking system that is performing the method of FIG. 4 will check to see if the
instruction at the given address has been stored in the cache.")
Therefore, it would have been obvious to one of ordinary skill in the art before the
effective filing date of the claimed invention to have incorporated the teachings of Goel into the
teachings of Cleraux. This combination of teachings would have resulted in a method for
scripting a breakpoint on a target device, as in Cleraux, with the generation of dataflow
primitives that are generated and stored in accordance with intended tracking of dataflow
associated with machine instructions, as in Goel. One of ordinary skill in the art would have been
motivated to combine these teachings for the purpose of tracking dataflow or untrusted data
throughout the debugging or program tracing playback to view the untrusted data uses and
influences (Goel [0017]).
The combination of Cleraux Goel Lee and Wang teaches the breakpoint control block but does not teach: [the breakpoint control block] comprises instruction location information; and active status information.
However, in an analogous art Suizu teaches instruction location information; (Suizu
[0027], "A hardware breakpoint table 35 in FIG. 2 is stored in the memory 3 or the like of the
debugging device 1. The hardware breakpoint table 35 stores information such as the addresses
of desired hardware breakpoints settings. A program for executing processes such as a hardware
break interrupt handler 31, a debugging process 32, a hardware breakpoint change process 33,
and a hardware breakpoint table setting process 34 illustrated in FIG. 2 is stored in the memory 3
or the like, and is executed by the CPU 2.")
[...] active status information. (Suizu [0046], "When a hardware breakpoint setting
command is entered as a debugger command, the debugging process calls the hardware
breakpoint table setting process illustrated in FIG. 3. The hardware breakpoint table, which
contains management information of the set hardware breakpoints, is stored in the memory or the
like of the debugging device.")
Therefore, it would have been obvious to one of ordinary skill in the art before the
effective filing date of the claimed invention to have incorporated the teachings of Suizu into the
teachings of Cleraux in view of Goel in view of Lee and further in view of Wang. This combination of teachings would have resulted in a method for scripting a breakpoint on a target device, as in Cleraux, with the generation of dataflow primitives that are generated and stored in accordance with intended tracking of dataflow associated with machine instructions, as in Goel, by using a debugging interrupt at a breakpoint to execute any debugging software therein, as in Lee, and executing the debugging software as a callback function, as in Wang, while handling the debugging of a program using a hardware breakpoint table, as in Suizu. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of receiving an operation for debugging a software program on the debugging device (Suizu [0025]).
Claims 12 and 18 are directed to an electronic device corresponding to the method as
disclosed in claims 2 and 8. Thus, claims 12 and 18 are rejected for the same reasons set forth in
claims 2 and 8.
Claims 3 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Cleraux in
view of Goel in view of Lee in view of Wang in view of Suizu in view of Bates as applied to claims 2 and 12 above, and further in view of US 20120110554 Al hereinafter "Bates 2".
With regards to claim 3, the rejection of claim 2 is incorporated.
Cleraux does not teach: updating the breakpoint control block to include the opcode
based on the changed content of the opcode and the memory address of the opcode;
However, in an analogous art Goel teaches updating the breakpoint control block to
include the opcode based on the changed content of the opcode and the memory address of
the opcode; (Goel [0067-68], "In this embodiment, an example of a dataflow caching table 350
is configured to cache one or more levels of information. This avoids the repeated decoding of
the opcodes from the machine instructions each time the machine instruction is executed. For a
first caching level, the opcodes associated with each machine instruction can be stored by
address. An opcode caching sub-table 356 can cache opcodes generated for machine instructions
by instruction memory address 352. The opcodes may be received from the decoding module
[updating to include the opcode] Blocks of lookup and update code can also be cached for
later use when multiple instructions have identical operations and operands [the breakpoint
control block based on the changed content of the opcode]. Caching of the primitives and
dataflow lookup and/or update operations by instruction address or opcode means the system
will not need to recompute these operations when the dataflow tracking is executed again for the
same instruction [and the memory address of the opcode].")
Therefore, it would have been obvious to one of ordinary skill in the art before the
effective filing date of the claimed invention to have incorporated the teachings of Goel into the
teachings of Cleraux. This combination of teachings would have resulted in a method for
scripting a breakpoint on a target device, as in Cleraux, with the generation of dataflow
primitives that are generated and stored in accordance with intended tracking of dataflow
associated with machine instructions, as in Goel. One of ordinary skill in the art would have been
motivated to combine these teachings for the purpose of tracking dataflow or untrusted data
throughout the debugging or program tracing playback to view the untrusted data uses and
influences (Goel [0017]).
The combination of Cleraux, Goel, Lee, Wang, Suizu, and Bates teaches an exception inducing instruction but does not teach: moving the breakpoint control block from an available breakpoints data structure to the active breakpoints data structure;
changing, [via the exception inducing instruction,] content of the opcode specified by
the set breakpoint command; and
marking a status of the breakpoint control block as active.
However, in an analogous art Bates 2 teaches moving the breakpoint control block
from an available breakpoints data structure to the active breakpoints data structure;
(Bates2 [0064], "As illustrated in FIG. 5, once processing is begun 500, then for each routine on
the call stack 505, processing determines whether the routine is a new entry in the control point
table (representative of routines on the call stack) 510. If "yes", then an entry is created in a
stack-based internal breakpoint data structure 515 for the routine, adding a disabled entry for
each line of the routine on the call stack 515. Thereafter, processing starts setting active internal
breakpoints by referencing the disabled list 520, and for each entry in the disabled list sets an
active internal breakpoint 525, thereby removing the entry from the disabled list and adding it to
the active list of stack-based internal breakpoints 530.")
changing, [...] content of the opcode specified by the set breakpoint command;
(Bates2 [0055], "As used herein, an "internal breakpoint" means a breakpoint type separate from
a user breakpoint, but which is also implemented by replacing an opcode with one that will cause
a trap to occur when it is executed. In one embodiment, an internal breakpoint is an
unconditional breakpoint, and is tracked separate from any user breakpoints. Upon encountering
an internal breakpoint, the debugger handles the trap, and in doing so, gets control at the
breakpoint. To resume from the breakpoint, the debugger replaces the correct opcode and lets the
code run. As used herein, program control simply means that a debugger can regain control and
stop execution of the code at the appropriate point to complete the step-type operation.") and
marking a status of the breakpoint control block as active. (Bates2 [0069], "The structure can
be populated as programs are loaded or added to debug. Every debuggable routine which is
currently loaded should have a line record in the structure that corresponds to its entry point. The
entry-point-based data structure includes an active breakpoint(s) list 700 and a disabled
breakpoint(s) list 710. As illustrated, the active breakpoint(s) list 700 is accessed via an address
hash table 720. When internal breakpoints are set, their line records are removed from the
disabled breakpoint list 710, and added to the active breakpoint list 700 and to the address hash
table 720. Address hash table 720 is for active line records only. In one embodiment, only line
records in the active list are in the address hash table, and removal from the active breakpoint list
700 implies removal from the address hash table 720 as well.") [Examiner's Note: Bates2
teaches that adding a breakpoint to an active list allows for it to be loaded for debugging
purposes and thus indicating a status of active.]
Therefore, it would have been obvious to one of ordinary skill in the art before the
effective filing date of the claimed invention to have incorporated the teachings of Bates 2 into
the teachings of Cleraux in view of Goel in view of Lee in view of Wang in view of Suizu and further in view of Bates. This combination of teachings would have resulted in a method for scripting a breakpoint on a target device, as in Cleraux, with the generation of dataflow primitives that are generated and stored in accordance with intended tracking of dataflow associated with machine instructions, as in Goel, by using a debugging interrupt at a breakpoint to execute any debugging software therein, as in Lee, and executing the debugging software as a callback function, as in Wang, while handling the debugging of a program using a hardware breakpoint table, as in Suizu, managing active breakpoints in accordance with the state of the program, as in Bates, and providing data structures that track and enable setting/disabling breakpoints, as in Bates 2. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of setting active internal breakpoints and disabling unnecessary internal breakpoints that are established through a data structure when implementing a step-type operation (Bates 2 [0025]).
Claim 13 is directed to an electronic device corresponding to the method as disclosed in
claim 3. Thus, claim 13 is rejected for the same reasons set forth in claim 3.
Claims 4 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Cleraux in
view of Goel in view of Lee in view of Wang in view of Suizu in view of Bates in view of Bates 2 as applied to claims 3 and 13 above, and further in view of US 12242598 B2 hereinafter "Tsirkin".
With regards to claim 4, the rejection of claim 3 is incorporated.
The combination of Cleraux, Goel, Lee, Wang, Suizu, Bates, and Bates2 teaches setting the breakpoint but does not teach: wherein [setting the breakpoint] further includes sending a negative acknowledgement to the host device in response to at least one of: an instruction
address specified in the received set breakpoint command is not a valid instruction
address;
a callback address specified in the received set breakpoint command is not a valid
callback address;
or the breakpoint control block is not available in the available breakpoints data structure.
However, in an analogous art Tsirkin teaches wherein [...] further includes sending a
negative acknowledgement to the host device in response to at least one of: an instruction
address specified in the received set breakpoint command is not a valid instruction
address;
a callback address specified in the received set breakpoint command is not a valid
callback address;
or the breakpoint control block is not available in the available breakpoints data
structure. (Tsirkin Column 10 Lines 28-55, "The list 414 of safe callback values includes
callback_A, callback_B and callback_C (block 426). Specifically, each callback may be a
respective function pointer address and the list 414 may include address A, address_B and
address_C associated with each callback [a valid callback address] Continuing on FIG. 4B,
the application 405 accesses the library 260B (e.g., Library_B) to execute a function with a
callback (block 434). Similar to the steps performed in FIG. 4A, the application 405 may again
access the library 260B to execute various tasks that include callback functions. Then,
Library 260B accesses another library 260A (e.g., Library_A) to execute the function
(block 436). Again, the library 260A initiates callback validation (block 438). As previously
mentioned, the library 260A may be enhanced or extended with an API with access to the
list 414 to perform validations. For example, similar to block 422, the library 260A initiates
callback validation. In the illustrated example, each callback is validated by library 260A prior to
invocation For example, callback D may be an instruction pointer address and the library
260A may compare the function pointer address with other function pointer addresses included
in the list 414. The list 414 of safe callback values includes callback_A, callback_Band
callback_C (block 442). Specifically, each callback may be a respective function pointer address
and the list 414 may include address_A, address_B and address_C associated with each callback.
Since the callback (e.g., callback_I does not match one of the callback values in the list 414,
library 260A confirms that the callback is unsafe and initiates a safe abort of callback
(block 444) [in response to at least one of a callback address specified in the received set
breakpoint command]. By confirming the callback is unsafe prior to invoking the callback, the
method 400 advantageously provides function pointer protection and eliminates the attack vector
of abusing function pointer calls, which prevents the potentially unsafe callback (e.g.,
callback_D) from executing In an example, the application 405 may be paused or closed after
an unsafe callback is detected. For example, the application 405 may be paused or closed until
the origin of the security threat or attack vector is identified and corrected. In the illustrated
example, the library 260A sends and error code 452 to the application 405 (block 450). The error
code 452 or error message may indicate to a user that a security threat exists. [further includes
sending a negative acknowledgement to the host device]") [Examiner's Note: A list ofsafe
callback values is a list of callback addresses that are called to invoke said callback. A received
command may request a specific callback address and during validation if the address does not
match a valid address listed then it is invalid, the callback is aborted, and an error code is sent. ]
Therefore, it would have been obvious to one of ordinary skill in the art before the
effective filing date of the claimed invention to have incorporated the teachings of Tsirkin into
the teachings of Cleraux in view of Goel in view of Lee in view of Wang in view of Suizu in view of Bate and further in view of Bates 2. This combination of teachings would have resulted in a method for scripting a breakpoint on a target device, as in Cleraux, with the generation of dataflow primitives that are generated and stored in accordance with intended tracking of dataflow associated with machine instructions, as in Goel, by using a debugging interrupt at a breakpoint to execute any debugging software therein, as in Lee, and executing the debugging software as a callback function, as in Wang, while handling the debugging of a program using a hardware breakpoint table, as in Suizu, managing active breakpoints in accordance with the state of the program, as in Bates, and providing data structures that track and enable setting/disabling breakpoints, as in Bates 2, and validating an intended callback with a list of safe callbacks to provide an acknowledgement of negative acknowledgement therein, as in Tsirkin. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of providing validation to a callback prior to invocation based on their signatures (Tsirkin Column 3 Lines 53-67).
Claim 14 is directed to an electronic device corresponding to the method as disclosed in
claim 4. Thus, claim 14 is rejected for the same reasons set forth in claim 4.
Claims 5-6 and 15-16 are rejected under 35 U.S.C. 103 as being unpatentable over
Cleraux in view of Goel in view of Lee in view of Wang in view of Suizu in view of Bates as applied to claims 2 and 12 above, and further in view of US 20170004063 A1 hereinafter "Broderick".
With regards to claim 5, the rejection of claim 2 is incorporated.
The combination of Cleraux, Goel, Lee, Wang, Suizu, and Bates does not teach further comprising reserving a portion of the memory as a pseudo flash region for performing breakpoint processing by the target device.
However, in an analogous art Broderick teaches further comprising reserving a portion
of the memory as a pseudo flash region for performing breakpoint processing by the target
device. (Broderick [0038], "In response to a controlling of the flash memory controller 100 to
transition to the debug operating mode S10, at least a part of resources available in
the flash memory controller is allocated for registering and storing debugging related information
in an intermediate allocation operation S5 by an allocation/deallocation block 160 of the flash
memory controller 100. The resources available for allocating comprises at least a part of the
flash RAM 130. The allocation/deallocation block 160 may be further configured to perform reconfiguration operations such as a re-configuration of one or more registers for use by the debug control components 120, which will be more fully described below.")
Therefore, it would have been obvious to one of ordinary skill in the art before the
effective filing date of the claimed invention to have incorporated the teachings of Broderick into
the teachings of Cleraux in view of Goel in view of Lee in view of Wang in view of Suizu and further in view of Bates. This combination of teachings would have resulted in a method for scripting a breakpoint on a target device, as in Cleraux, with the generation of dataflow primitives that are generated and stored in accordance with intended tracking of dataflow associated with machine instructions, as in Goel, by using a debugging interrupt at a breakpoint to execute any debugging software therein, as in Lee, and executing the debugging software as a callback function, as in Wang, while handling the debugging of a program using a hardware breakpoint table, as in Suizu, managing active breakpoints in accordance with the state of the program, as in Bates, and allocating a portion of memory for registering and processing breakpoints, as in Broderick. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of providing a flash memory controller that contains the required components/information for controlling a trace, breakpoint, and/or state sequence (Broderick [0029]).
With regards to claim 6, the rejection of claim 5 is incorporated.
The combination of Cleraux, Goel, Lee, Wang, Suizu, and Bates does not teach wherein the data related to the breakpoint is stored in a debug utility stack in a predefined data space of the pseudo flash region.
However, in an analogous art Broderick teaches wherein the data related to the
breakpoint is stored in a debug utility stack in a predefined data space of the pseudo flash
region. (Broderick [0065-67], "Watchpoint operations are typically used during a debugging
operation to monitor access to predefined addresses, predefined address ranges and/or data
variable addresses. The watchpoint control block 122 is configurable with address information
and is configured to compare monitored accesses to addresses with the configured address
information The breakpoint/watchpoint control block 122 is adapted to detect a modification
of the monitored value or compare the monitored value with a predefined target value configured
at the breakpoint watchpoint/control block 122. In case of a detection, a watchpoint event is
asserted. A trace trigger may be generated in response to an asserted watchpoint event. The
breakpoint/watchpoint control block 122 may make use of one or more registers 136 of the flash
memory controller 100 as comparator value registers to store one or more address, program
counter and/or data target values for being compared with monitored address, data and/or status
information under the control of the breakpoint/watchpoint control block 122") [Examiner's
Note: A breakpoint/watchpoint control block is analogous to a debug utility stack that can
include information for debugging as stored in an allocated flash region.]
Therefore, it would have been obvious to one of ordinary skill in the art before the
effective filing date of the claimed invention to have incorporated the teachings of Broderick into
the teachings of Cleraux in view of Goel in view of Lee in view of Wang in view of Suizu and further in view of Bates. This combination of teachings would have resulted in a method for scripting a breakpoint on a target device, as in Cleraux, with the generation of dataflow primitives that are generated and stored in accordance with intended tracking of dataflow associated with machine instructions, as in Goel, by using a debugging interrupt at a breakpoint to execute any debugging software therein, as in Lee, and executing the debugging software as a callback function, as in Wang, while handling the debugging of a program using a hardware breakpoint table, as in Suizu, managing active breakpoints in accordance with the state of the program, as in Bates, and allocating a portion of memory for registering and processing breakpoints, as in Broderick. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of providing a flash memory controller that contains the required components/information for controlling a trace, breakpoint, and/or state sequence (Broderick [0029]).
Claims 15-16 are directed to an electronic device corresponding to the method as
disclosed in claims 5-6 respectively. Thus, claims 15-16 are rejected for the same reasons set
forth in claims 5-6.
Claims 7 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Cleraux in
view of Goel in view of Lee in view of Wang in view of Suizu in view of Bates in view of Broderick as applied to claims 6 and 16 above, and further in view of US 20120198278 A1 hereinafter "Williams".
With regards to claim 7, the rejection of claim 6 is incorporated.
The combination of Cleraux, Goel, Lee, Wang, Suizu, and Bates does not teach saving register contents in the debug utility stack.
However, in an analogous art Broderick teaches saving register contents in the debug
utility stack. (Broderick [0048], "As already described above, on controlling the flash memory
controller 100 to transition to the debug operating mode S10, at least a part of the resources of
the flash memory controller 100 is allocated (cf. operation S5) for debug functionality. In
particular, the allocated part of the resources is provided to register and store debug related
information. Debug related information in particular comprises for instance program trace
information relating to a flow of a program executed on one or more of the processor cores, data
trace information relating to changes of data stored at one or more specified address ranges
and/or status information relating to internal status of one or more components of the data
processing system.") [Examiner's Note: Allocating memory space for breakpoint information
and internal status of data processing components can comprise saving register contents to a
debug utility stack]
Therefore, it would have been obvious to one of ordinary skill in the art before the
effective filing date of the claimed invention to have incorporated the teachings of Broderick into
the teachings of Cleraux in view of Goel in view of Lee in view of Wang in view of Suizu and further in view of Bates. This combination of teachings would have resulted in a method for scripting a breakpoint on a target device, as in Cleraux, with the generation of dataflow primitives that are generated and stored in accordance with intended tracking of dataflow associated with machine instructions, as in Goel, by using a debugging interrupt at a breakpoint to execute any debugging software therein, as in Lee, and executing the debugging software as a callback function, as in Wang, while handling the debugging of a program using a hardware breakpoint table, as in Suizu, managing active breakpoints in accordance with the state of the program, as in Bates, and allocating a portion of memory for registering and processing breakpoints, as in Broderick. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of providing a flash memory controller that contains the required components/information for controlling a trace, breakpoint, and/or state sequence (Broderick [0029]).
The combination of Cleraux, Goel, Lee, Wang, Suizu, Bates, and Broderick does not teach: wherein storing the data related to the breakpoint hit includes: disabling other interrupts;
However, in an analogous art Williams teaches wherein storing the data related to the
breakpoint hit includes: disabling other interrupts; (Williams [0079], "In addition to the
ability to provide granularity in whether or not kernel debug is allowed, there may also be the
ability to inhibit the taking of debugging exceptions when particular code is executed. This is
provided by the current debug mask value or mask flag 43. The mask flag is set by processor 30
when executing a particular code. Thus, if the processor is executing code at the EL1 level and
that code is critical code interruption of which might cause a software malfunction then the
processor 30 sets the debug mask flag. Then if a debug exception is generated it cannot be taken
at this level as this mask flag inhibits it from being taken.")
Therefore, it would have been obvious to one of ordinary skill in the art before the
effective filing date of the claimed invention to have incorporated the teachings of Williams into
the teachings of Cleraux in view of Goel in view of Lee in view of Wang in view of Suizu in view of Bates and further in view of Broderick. This combination of teachings would have resulted in a method for scripting a breakpoint on a target device, as in Cleraux, with the generation of dataflow primitives that are generated and stored in accordance with intended tracking of dataflow associated with machine instructions, as in Goel, by using a debugging interrupt at a breakpoint to execute any debugging software therein, as in Lee, and executing the debugging software as a callback function, as in Wang, while handling the debugging of a program using a hardware breakpoint table, as in Suizu, managing active breakpoints in accordance with the state of the program, as in Bates, and allocating a portion of memory for registering and processing breakpoints, as in Broderick, and determining when an interrupt should be taken in accordance with debugging services, as in Williams. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of a host debugger with storage that indicates whether or not a debug exception should be taken using a register bank for breakpoint and watchpoint values (Williams [0066]).
Claim 17 is directed to an electronic device corresponding to the method as disclosed in
claim 7. Thus, claim 17 is rejected for the same reasons set forth in claim 7.
Claims 10 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Cleraux in
view of Goel in view of Lee in view of Wang as applied to claims 1 and 11 above, and further in view of US 8726209 B1 hereinafter "Lamant".
With regards to claim 10, the rejection of claim 1 is incorporated.
The combination of Cleraux Goel Lee and Wang does not teach: further comprising validating, by the target device, the created callback routine using an error identification operation.
However, in an analogous art Lamant teaches further comprising validating, by the
target device, the created callback routine using an error identification operation. (Lamant
Columns 7-8 Lines 57-67 and 1-8, "Upon completion of the debugging user interface, the flow
proceeds to block 116 where the layout is again attempted to be generated at this layout
generation step of block 116. However, the break points are activated such that generation of the
layout is stopped or arrested mid-execution such that the system state, parameter values, and
variable values, remain. The user is able to iteratively step between block 116 and block 117
where the user is able to determine whether the callback function and the layout generation were
successful. Upon a successful completion of the debugging process at block 117, the flow
proceeds to block 118 where the automatically-inserted break point is then removed. Care is
taken to avoid removing any other break points set manually or by other means. In this manner,
only the break point which was previously set automatically by the debugging UI is removed.
Once the break point has been removed, the flow proceeds to block 119 where the test-layout is
successfully generated and the debugging is completed.")
Therefore, it would have been obvious to one of ordinary skill in the art before the
effective filing date of the claimed invention to have incorporated the teachings of Lamant into
the teachings of Cleraux in view of Goel in view of Lee and further in view of Wang. This combination of teachings would have resulted in a method for scripting a breakpoint on a target device, as in Cleraux, with the generation of dataflow primitives that are generated and stored in accordance with intended tracking of dataflow associated with machine instructions, as in Goel, by using a debugging interrupt at a breakpoint to execute any debugging software therein, as in Lee, and executing the debugging software as a callback function, as in Wang, and validating the callback function to ensure a proper test-layout, as in Lamant. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of verifying the successful generation of a test layout to better initialize the callbacks and their associated breakpoints (Lamant Column 7 Lines 4-36).
Claim 20 is directed to an electronic device corresponding to the method as disclosed in
claim 10. Thus, claim 20 is rejected for the same reasons set forth in claim 10.
Allowable Subject Matter
Claim 9 allowed.
Claim 19 objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Response to Arguments
Applicant’s arguments with respect to claims 1-8 and 10-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
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 nonprovisional extension fee (37 CFR 1.17(a)) 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 mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TRAVIS VIET TRAN whose telephone number is (571)272-3720. The examiner can normally be reached Monday-Friday 8:30AM-5PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Wei Mui 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.
/T.V.T./Examiner, Art Unit 2191 /WEI Y MUI/Supervisory Patent Examiner, Art Unit 2191
Prosecution Insights