DETAILED ACTION
The Office Action is in response to claims filed 07/10/2024.
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 A1 hereinafter “Cleraux” in view of US 20100325359 A1 hereinafter “Goel”.
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;
in response to the received set breakpoint command, setting a breakpoint at the target device. (Cleraux [0016], “Specifically, the exemplary embodiments may allow a user to set conditional breakpoints, wherein the evaluation of the conditions may be performed on the target (e.g., by a debugging agent on the target) [setting a breakpoint at the target device]. This will dramatically reduce the time needed to evaluate the condition, and thus, improve the time required for debugging. 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 [in response to the received set breakpoint command]. 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.]
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]).
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 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.
Cleraux further teaches identifying a breakpoint hit at the target device; (Cleraux [0027], “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.”)
storing data related to the breakpoint hit; (Cleraux [0021-22], “A conditional breakpoint may be described as code or instructions that cause a break to occur in execution only if a specific condition is satisfied (e.g., met). A sensorpoint may be, for example, an instrumentation point inserted into a program code, thereby allowing software developers to perform diagnostic applications on the code. However, the exemplary embodiments are not limited to using sensorpoints, but may be implemented using any mechanism that can instrument a program. As will be discussed in detail below, sensorpoint modules comprise program code that the developer can implement on the target 120. Monitoring data may include any relevant data that the developer desires to receive from the target 120, such as device information, alarms and error messages, log information, and audit information (e.g., information related to users modifying devices and/or sensorpoint modules) … Using the workbench software 118, the user can create conditional breakpoints and sensorpoint modules, write and edit code for the breakpoints and sensorpoints, compile the code, abstract a parameter profile from the compiled code, and save the breakpoints and sensorpoints to a database or as a local file.”)
Cleraux does not teach: invoking the callback routine stored in the callback memory space;
However, in an analogous art Goel teaches invoking the callback routine stored in the callback memory space; (Goel [0069], “Cached results can be retrieved from the cache instead of recalculated, thus avoiding unnecessary repetition of opcode decoding and primitive generating steps or operations. Subsequent executions of the same machine instruction can include calling the primitive's pre-computed lookup and update code (or handler address for the lookup and update code), which in turn calls the pre-computed lookup and update operations to track the data propagation of that instruction. The pre-computed lookup and update operations provide the executable code that looks up the appropriate memory addresses and dataflow bitmaps in the dataflow state table and applies the operations discussed to the dataflow state table, as exemplified in Table A and B. Representing dataflow state lookup and update operations with pre-computed operations aids in maximizing run-time efficiency.”)
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: 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 2… 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. 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, 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, 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 of jobs (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 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, 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 and Goel 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. 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, 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 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, 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 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, 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 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, 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_B and 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_D) 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 of safe 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 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, 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 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, 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 re-configuration 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 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, 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, 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 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, 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 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, 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 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, 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, 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 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, 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 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 and Goel 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. 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, 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
Claims 9 and 19 are 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.
Conclusion
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