DETAILED ACTION
This is the initial Office action based on the preliminary amendment filed on June 28, 2024.
Claims 1-15 are pending.
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
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 Interpretation
Please note that the limitations directed to “executing a predefined debug instruction if included in the hook function” and “upon receiving the debug instruction from the user, executing a functional instruction if included in the debug instruction from the user” in Claim 6 and the limitation directed to “if yes, injecting a hook function into the second thread and executing the second thread in a debug mode” in Claim 9 are optional, as well as any dependent limitations that correspond to these optional limitations, because they are contingent limitations. However, in the interest of compact prosecution, the Examiner is performing full examination on the optional limitations.
Claim Objections
Claims 4-5, 9-10, and 13 are objected to because of the following informalities:
Claim 4, in line 2, recites “adding a hook function.” It should read -- adding the hook function --.
Claim 5, in lines 10-11, recites “obtaining an interruption location, a variable of interest and a predefined condition.” It should read -- obtaining the interruption location, the variable of interest and the predefined condition --.
Claim 9, in lines 3-4, recites “injecting a hook function into the second thread.” It should read -- injecting the hook function into the second thread --.
Claim 10, in line 6, recites “API.” It should read – Application Programming Interface (API) --.
Claim 10, in line 4, recites “the debug instruction received from the user.” It should read -- the debug instruction from the user --.
Claim 10, in line 5, recites “sharing the debug instruction.” It should read -- sharing the debug instruction from the user --.
Claim 13, in line 2, recites “the thread in the virtual machine.” It should read -- the one thread running in the virtual machine --.
Appropriate correction is required.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claim 15 is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
Claim 15 is directed to a computer-readable storage medium on which computer program commands are stored. It is noted that the specification does not provide an explicit definition for a computer-readable storage medium. It is also noted that the specification, in paragraph [0085], includes exemplary language for a computer-readable storage medium that covers signals per se by stating that the computer-readable storage medium “can be any medium or data storage device accessible by a computer, including but not limited to various mediums capable of storing program codes […].” The broadest reasonable interpretation of a claim drawn to a computer-readable storage medium covers forms of non-transitory tangible media and transitory propagating signals per se in view of the ordinary and customary meaning of a computer-readable storage medium, particularly when the specification is silent. See MPEP § 2111.01. When the broadest reasonable interpretation of a claim covers a signal per se, the claim must be rejected under 35 US.C. § 101 as covering non-statutory subject matter. See In re Nuijten, 500 F.3d 1346, 1356-57 (Fed. Cir. 2007) (transitory embodiments are not directed to statutory subject matter) and Interim Examination Instructions for Evaluating Subject Matter Eligibility Under 35 U.S.C. § 101, Aug. 24, 2009; p. 2. Therefore, the claimed computer-readable storage medium is ineligible subject matter under § 101. Applicant is advised to amend the claim to recite “a non-transitory computer-readable storage medium” in order to overcome the 35 U.S.C. § 101 rejection.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 4-7, 9, and 14-15 are rejected under 35 U.S.C. 103 as being unpatentable over CN 106681897A (Provided by Applicant’s IDS, hereinafter “Cheng”) in view of US 7,865,883 (hereinafter “Sistare”) and CN 110032426A (hereinafter “Luo”).
As per Claim 1, Cheng discloses:
A debugging method for a device (paragraph [0002], “This invention relates to the field of computer software programming technology, and in particular to a code debugging method and apparatus.”), comprising:
determining whether a [thread] contains a corresponding breakpoint based on the [thread] and a breakpoint set (paragraph [0054], “When the line number of the running Python code exists in the set of breakpoints created by C#, it means that the Python code has reached the breakpoint location and needs to pause the execution of the Python code, i.e., the line break event function ScriptBreak (emphasis added).”; paragraph [0058], “This blocks the current C# thread, and the execution of the Python code in the IronPython object running in the current C# thread will also be paused (emphasis added).”);
if no, […] executing in a normal mode (paragraph [0038], “As can be seen from the above implementation, the code debugging method adopted in this embodiment of the invention only requires the user to determine the code line position where debugging needs to be paused. When the code program is executed, it can automatically recognize the pause position selected by the user and stop the code program at that position, waiting for the user's next instruction. After receiving the user's instruction to cancel the pause, the execution of the code program is resumed until it runs to the next debug breakpoint code line (emphasis added).”; paragraph [0060], “When you need to resume execution of paused Python code, simply set the value of the `continue` variable inside the C# function to `true`, and then the `while(!)` loop will resume. The loop condition will no longer be true if the loop continues. The loop will exit, and the current C# thread will be unblocked. The Python code running in the IronPython object in the current C# thread can then continue to run (emphasis added).”; paragraph [0029], “Furthermore, when selecting breakpoint locations, users are not limited by the current state of the code. They can determine the locations of all breakpoints in advance before execution, or they can determine the locations of breakpoints in real time during the execution of the code.”) [Examiner’s Remarks: Note that Cheng discloses executing a program (running thread) and pausing the program (thread) when it recognizes and reaches the pause position set by the user in order to start debugging. Moreover, once the user cancels the pause, normal execution of the program is resumed until the next breakpoint. One of ordinary skill of the art would readily comprehend that if the user does not set any (or any subsequent) breakpoints then the thread will continue normal execution.];
if yes, injecting a hook function into the [thread] and […] executing in a debug mode (paragraph [0036], “Once the current line number of the code is determined to be the breakpoint line number, the program will execute the called interrupt event function [hook function], pausing the execution of the code at the current line (emphasis added).”; paragraph [0038], “As can be seen from the above implementation, the code debugging method adopted in this embodiment of the invention only requires the user to determine the code line position where debugging needs to be paused. When the code program is executed, it can automatically recognize the pause position selected by the user and stop the code program at that position [executing debug mode], waiting for the user's next instruction. After receiving the user's instruction to cancel the pause, the execution of the code program is resumed until it runs to the next debug breakpoint code line (emphasis added).”; paragraph [0071], “Module 321 is invoked to call the interrupt event function in the interrupt code based on the interrupt code added after each line of the code (emphasis added).”);
when the hook function in the [thread] is called, determining [to interrupt program execution] (paragraph [0072], “The judgment module 322 is used to determine whether the current line number of the code execution is in the breakpoint set when the interrupt event function called by the calling module 321 is executed (emphasis added).”; paragraph [0092], “[…] determining whether the current line number is in the breakpoint set based on the current line number of the code execution; if it exists, executing an interrupt event function to interrupt the execution of the code (emphasis added).”; paragraph [0054], “Because the Python code executes within the IronPython object, and the IronPython object runs in the current thread of the C# program, you only need to write code that blocks the current C# thread to make it run.”);
[…] exiting the hook function directly and running subsequent codes of the [thread] (paragraph [0037], “To resume the execution of the code, it is necessary to exit the currently running interrupt event function. Based on the above implementation of the interrupt event function, the user can give a stop command in the interrupt event function to exit the loop execution process of the loop function or the paused state of the script function. This restores the execution state of the code (emphasis added).”);
[…] waiting and executing a debug instruction, then exiting the hook function after executing the debug instruction, and running the subsequent codes of the [thread] (paragraph [0018], “According to the code debugging method and apparatus proposed in this invention, as long as the user determines the line of code where debugging needs to be paused, the code program can automatically identify the pause position selected by the user during execution and stop the code program at that position, waiting for the user's next instruction. After receiving the user's instruction to cancel the pause, the execution of the code program is resumed until it runs to the next debug breakpoint line of code (emphasis added).”; paragraph [0079], “The second execution module 332 is used to execute the debug interrupt script called by the interrupt event function executed by the first execution module 331, so as to interrupt the continued execution of the code (emphasis added).”; paragraph [0081], “Termination unit 34 is used to terminate the execution of the interrupt event function executed by execution unit 33 according to the user's instruction and resume the execution of the code (emphasis added).”).
Cheng does not explicitly disclose:
a first thread to be created;
creating the first thread.
However, Sistare discloses:
a first thread to be created (col. 3 lines 45-49, “However, during a debugging session, requests from the program to create and delete threads are processed by the debugger 24. Thus, the debugger 24 will be aware of the existence of each of the threads (emphasis added).”);
creating the first thread (col. 3 lines 45-49, “However, during a debugging session, requests from the program to create and delete threads are processed by the debugger 24. Thus, the debugger 24 will be aware of the existence of each of the threads (emphasis added).”).
Cheng is within the same field of endeavor as the claimed invention regarding the debugging of a program and injection of hook functions. Sistare is also within the same field of endeavor as the claimed invention regarding the debugging of a multi-threaded program and creation of threads.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Sistare into the teaching of Cheng to include “determining whether a first thread to be created contains a corresponding breakpoint based on the first thread and a breakpoint set; if no, creating the first thread and executing in a normal mode; if yes, injecting a hook function into the first thread, and creating the first thread and executing in a debug mode; when the hook function in the first thread is called, determining [to interrupt program execution]; […] exiting the hook function directly and running subsequent codes of the first thread; […] waiting and executing a debug instruction, then exiting the hook function after executing the debug instruction, and running the subsequent codes of the first thread.” The modification would be obvious because one of ordinary skill in the art would be motivated to utilize a system with a debugger that creates threads and controls operations in connection with threads in order for the debugger to scale more appropriately and for more efficient debugging of multi-threaded programs (Sistare, col. 1 lines 9-11 & col. 4 line 67 to col. 5 lines 1-3).
The combination of Cheng and Sistare discloses “when the hook function in the first thread is called, determining [to interrupt program execution],” “[…] exiting the hook function directly and running subsequent codes of the first thread,” and “[…] waiting and executing a debug instruction, then exiting the hook function after executing the debug instruction, and running the subsequent codes of the first thread,” but does not explicitly disclose:
when the hook function in the first thread is called, determining whether a triggering condition of a breakpoint is satisfied;
if no, exiting the hook function directly and running subsequent codes of the first thread;
if yes, suspending code running of the first thread, waiting and executing a debug instruction, then exiting the hook function after executing the debug instruction, and running the subsequent codes of the first thread.
However, Luo discloses:
determining whether a triggering condition of a breakpoint is satisfied (paragraph [0016], “When the target virtual machine receives an external request that triggers the execution of the source code segment that needs to be debugged, the virtual machine will trigger a breakpoint event when the specified debugging event is passed and push the event to the debugger (emphasis added).”; paragraph [0017], “Once a breakpoint event is detected that matches the current debugging conditions, the current thread is suspended. The debugger obtains the data in the thread stack and returns it to the user interface for rendering, so that the debugger can clearly understand all the data in the current thread (emphasis added).”);
if no, running subsequent codes of the [thread] (paragraph [0016], “When the target virtual machine receives an external request that triggers the execution of the source code segment that needs to be debugged, the virtual machine will trigger a breakpoint event when the specified debugging event is passed and push the event to the debugger (emphasis added).”; paragraph [0017], “Once a breakpoint event is detected that matches the current debugging conditions, the current thread is suspended (emphasis added).”; paragraph [0143], “S5. After receiving the time from the target virtual machine, the debugging service suspends the thread, determines whether the debugging conditions are met, and if the conditions are met, obtains the thread information and sends it back to the user layer (emphasis added).”; paragraph [0146], “S8 repeats S5-S7 to complete the steps of the debugger's operation on each line of code and obtains thread information for each running state for the user to debug (emphasis added).”) [Examiner’s Remarks: Note that Luo discloses execution of code that needs to be debugged and that the thread is suspended once a breakpoint that matches the debugging conditions is detected. Luo also discloses repeating steps S5 (determining if debugging conditions are met) to S7 on each line of code. One of ordinary skill in the art would readily comprehend that if the triggering condition of the breakpoint wasn’t satisfied, the execution of the code would continue (running subsequent codes of the thread).];
if yes, suspending code running of the [thread] (paragraph [0017], “Once a breakpoint event is detected that matches the current debugging conditions, the current thread is suspended (emphasis added).”; paragraph [0141], “This step corresponds to the following steps in Figure 4: when the corresponding condition is matched, the thread is suspended and the thread stack data is obtained and given to the user layer; according to the debugger's instructions, single-step debugging is performed, the thread is resumed, and steps 8 and 9 are repeated until the debugging is completed and the connection is disconnected (emphasis added).”).
Luo is within the same field of endeavor as the claimed invention regarding the debugging of a program and breakpoint conditions.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Luo into the combined teachings of Cheng and Sistare to include “when the hook function in the first thread is called, determining whether a triggering condition of a breakpoint is satisfied; if no, exiting the hook function directly and running subsequent codes of the first thread; if yes, suspending code running of the first thread, waiting and executing a debug instruction, then exiting the hook function after executing the debug instruction, and running the subsequent codes of the first thread.” The modification would be obvious because one of ordinary skill in the art would be motivated to take a particular action based on a determination of whether a triggering condition of a breakpoint is satisfied to ensure an action like pausing of the thread is only done when an appropriate breakpoint event has occurred which allows debuggers to understand the actual cause of online problems more quickly and clearly (Luo, paragraphs [0009, 0016, & 0017]).
As per Claim 4, the rejection of Claim 1 is incorporated; and Cheng discloses “wherein said injecting a hook function into the [thread] specifically comprises adding a hook function after each line of code in the [thread] (paragraph [0071], “Module 321 is invoked to call the interrupt event function in the interrupt code based on the interrupt code added after each line of the code.”; paragraph [0054], “Because the Python code executes within the IronPython object, and the IronPython object runs in the current thread of the C# program, you only need to write code that blocks the current C# thread to make it run.”),” but the combination of Cheng and Luo does not explicitly disclose:
the first thread.
However, Sistare discloses:
the first thread (col. 3 lines 45-49, “However, during a debugging session, requests from the program to create and delete threads are processed by the debugger 24. Thus, the debugger 24 will be aware of the existence of each of the threads (emphasis added).”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Sistare into the combined teachings of Cheng and Luo to include “wherein said injecting a hook function into the first thread specifically comprises adding a hook function after each line of code in the first thread.” The modification would be obvious because one of ordinary skill in the art would be motivated to utilize a system with a debugger that creates threads and controls operations in connection with threads in order for the debugger to scale more appropriately and for more efficient debugging of multi-threaded programs (Sistare, col. 1 lines 9-11 & col. 4 line 67 to col. 5 lines 1-3).
As per Claim 5, the rejection of Claim 4 is incorporated; and Cheng discloses “obtaining an interruption location of each location breakpoint in the breakpoint set, and checking if the interruption location is consistent with a current running code location of the [thread] (paragraph [0016], “The judgment unit is used to determine whether the current line number is in the breakpoint set obtained by the acquisition unit, based on the current line number of the code execution.”; paragraph [0054], “Because the Python code executes within the IronPython object, and the IronPython object runs in the current thread of the C# program, you only need to write code that blocks the current C# thread to make it run.”); or obtaining a variable of interest and a predefined condition for each conditional breakpoint in the breakpoint set, and checking if a current value of the variable of interest satisfies the predefined condition during execution of the first thread; or obtaining an interruption location, a variable of interest and a predefined condition for each location conditional breakpoint in the breakpoint set, checking if the interruption location is consistent with a current running code location of the first thread, and simultaneously checking if a current value of the variable of interest satisfies the predefined condition during execution of the first thread,” but the combination of Cheng and Luo does not explicitly disclose:
the first thread.
However, Sistare discloses:
the first thread (col. 3 lines 45-49, “However, during a debugging session, requests from the program to create and delete threads are processed by the debugger 24. Thus, the debugger 24 will be aware of the existence of each of the threads (emphasis added).”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Sistare into the combined teachings of Cheng and Luo to include “obtaining an interruption location of each location breakpoint in the breakpoint set, and checking if the interruption location is consistent with a current running code location of the first thread; or obtaining a variable of interest and a predefined condition for each conditional breakpoint in the breakpoint set, and checking if a current value of the variable of interest satisfies the predefined condition during execution of the first thread; or obtaining an interruption location, a variable of interest and a predefined condition for each location conditional breakpoint in the breakpoint set, checking if the interruption location is consistent with a current running code location of the first thread, and simultaneously checking if a current value of the variable of interest satisfies the predefined condition during execution of the first thread.” The modification would be obvious because one of ordinary skill in the art would be motivated to utilize a system with a debugger that creates threads and controls operations in connection with threads in order for the debugger to scale more appropriately and for more efficient debugging of multi-threaded programs (Sistare, col. 1 lines 9-11 & col. 4 line 67 to col. 5 lines 1-3).
As per Claim 6, the rejection of Claim 5 is incorporated; and Cheng further discloses:
executing a predefined debug instruction if included in the hook function (paragraph [0079], “The second execution module 332 is used to execute the debug interrupt script called by the interrupt event function [hook function] executed by the first execution module 331, so as to interrupt the continued execution of the code.”);
waiting for a debug instruction from a user (paragraph [0018], “According to the code debugging method and apparatus proposed in this invention, as long as the user determines the line of code where debugging needs to be paused, the code program can automatically identify the pause position selected by the user during execution and stop the code program at that position, waiting for the user's next instruction. After receiving the user's instruction to cancel the pause, the execution of the code program is resumed until it runs to the next debug breakpoint line of code.”); and
upon receiving the debug instruction from the user, executing a functional instruction if included in the debug instruction from the user (paragraph [0018], “[…] the code program can automatically identify the pause position selected by the user during execution and stop the code program at that position, waiting for the user's next instruction. After receiving the user's instruction to cancel the pause, the execution of the code program is resumed until it runs to the next debug breakpoint line of code.”).
As per Claim 7, the rejection of Claim 6 is incorporated; and Cheng further discloses:
when the debug instruction from the user comprises a breakpoint update instruction which is configured to add a new breakpoint to the breakpoint set or remove an existing breakpoint from the breakpoint set, executing the breakpoint update instruction (paragraph [0018], “Since the method used in this invention updates the breakpoint line numbers in the breakpoint set in real time, it is possible to add or delete the breakpoints required by the user at any time during the execution of the code program, providing a more flexible debugging method for the code program […] the user dynamically selects the point where to pause during the code debugging process and resumes the code's running state under the user's control.”).
As per Claim 9, the rejection of Claim 7 is incorporated; and Cheng further discloses:
when the new breakpoint is added after a breakpoint update, checking if there is a second thread executing in a normal mode related to the new breakpoint (paragraph [0018], “Since the method used in this invention updates the breakpoint line numbers in the breakpoint set in real time, it is possible to add or delete the breakpoints required by the user at any time during the execution of the code program, providing a more flexible debugging method for the code program […] the user dynamically selects the point where to pause during the code debugging process and resumes the code's running state under the user's control (emphasis added).”; paragraph [0031], “Depending on the user's selection, the collection will continuously update the breakpoint line numbers, adding new breakpoints or deleting existing ones.”; paragraph [0038], “When the code program is executed, it can automatically recognize the pause position selected by the user and stop the code program at that position, waiting for the user's next instruction. After receiving the user's instruction to cancel the pause, the execution of the code program is resumed [executing in normal mode] until it runs to the next debug breakpoint code line (emphasis added).”); if yes, injecting a hook function into the second thread and executing the second thread in a debug mode (paragraph [0032], “Determine whether the current line number is in the breakpoint set based on the current line number of the code execution.”; paragraph [0036], “Once the current line number of the code is determined to be the breakpoint line number, the program will execute the called interrupt event function, pausing the execution of the code at the current line.”; paragraph [0071], “Module 321 is invoked to call the interrupt event function [hook function] in the interrupt code based on the interrupt code added after each line of the code (emphasis added).”; paragraph [0038], “When the code program is executed, it can automatically recognize the pause position selected by the user and stop the code program at that position [executing debug mode], waiting for the user's next instruction. After receiving the user's instruction to cancel the pause, the execution of the code program is resumed until it runs to the next debug breakpoint code line (emphasis added).”; paragraph [0058], “This blocks the current C# thread, and the execution of the Python code in the IronPython object running in the current C# thread will also be paused.”).
As per Claim 14, the rejection of Claim 1 is incorporated; and Cheng further discloses:
A device, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, performs the debugging method according to claim 1 (paragraph [0089], “The code debugging device includes a processor and a memory. The aforementioned acquisition unit, judgment unit, execution unit, and termination unit are all stored in the memory as program units, and the processor executes the aforementioned program units stored in the memory to achieve the corresponding functions.”; paragraph [0095], “These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner […].”).
As per Claim 15, the rejection of Claim 1 is incorporated; and Cheng further discloses:
A computer-readable storage medium, on which computer program commands are stored, wherein the computer program commands are executed by a processor to implement the debugging method according to claim 1 (paragraph [0095], “These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and/or one or more block diagrams.”; (paragraph [0089], “The code debugging device includes a processor and a memory. The aforementioned acquisition unit, judgment unit, execution unit, and termination unit are all stored in the memory as program units, and the processor executes the aforementioned program units stored in the memory to achieve the corresponding functions.”).
Claims 2 and 3 are rejected under 35 U.S.C. 103 as being unpatentable over Cheng in view of Sistare and Luo as applied to Claim 1 above, and further in view of US 2014/0215441 (hereinafter “Thukkaram”).
As per Claim 2, the rejection of Claim 1 is incorporated; and Cheng discloses “the breakpoint set (paragraph [0054], “When the line number of the running Python code exists in the set of breakpoints created by C#, it means that the Python code has reached the breakpoint location and needs to pause the execution of the Python code, i.e., the line break event function ScriptBreak.”),” but the combination of Cheng and Luo does not explicitly disclose:
wherein the breakpoint set is stored in a breakpoint configuration file, from which breakpoint information is read when creating a thread.
However, Thukkaram discloses:
wherein the breakpoint [information] is stored in a breakpoint configuration file, from which breakpoint information is read when [executing the application] (paragraph [0055], “In an embodiment, breakpoint information may be stored in memory, a configuration file, local or remote data store or the like. Such debugger configuration information may be provided to a debug server or a process that monitors the execution of the application so that determination may be made during the execution of the application whether the breakpoint has been reached (emphasis added).”).
Thukkaram is within the same field of endeavor as the claimed invention regarding the utilization of a configuration file to store breakpoint information.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Thukkaram into the combined teachings of Cheng and Luo to include “wherein the breakpoint set is stored in a breakpoint configuration file, from which breakpoint information is read when [executing the application].” The modification would be obvious because one of ordinary skill in the art would be motivated to store breakpoint information in a configuration file in order to allow for effective dynamic updating of breakpoint information and a centralized location for breakpoint information which helps improve organization (Thukkaram, paragraph [0055]).
The combination of Cheng, Luo, and Thukkaram does not explicitly disclose:
wherein the breakpoint set is stored in a breakpoint configuration file, from which breakpoint information is read when creating a thread.
However, Sistare discloses:
[request] information is read when creating a thread (col. 3 lines 45-49, “However, during a debugging session, requests from the program to create and delete threads are processed by the debugger 24. Thus, the debugger 24 will be aware of the existence of each of the threads.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Sistare into the combined teachings of Cheng, Luo, and Thukkaram to include “wherein the breakpoint set is stored in a breakpoint configuration file, from which breakpoint information is read when creating a thread.” The modification would be obvious because one of ordinary skill in the art would be motivated to utilize a system with a debugger that creates threads and controls operations in connection with threads in order for the debugger to scale more appropriately and for more efficient debugging of multi-threaded programs (Sistare, col. 1 lines 9-11 & col. 4 line 67 to col. 5 lines 1-3).
As per Claim 3, the rejection of Claim 2 is incorporated; and Cheng further discloses:
wherein breakpoints in the breakpoint set are selected from at least one of three types: location breakpoints representing interruptions occurred at specific locations in the thread during code execution (paragraph [0054], “When the line number of the running Python code exists in the set of breakpoints created by C#, it means that the Python code has reached the breakpoint location and needs to pause the execution of the Python code, i.e., the line break event function ScriptBreak.”; paragraph [0058], “This blocks the current C# thread, and the execution of the Python code in the IronPython object running in the current C# thread will also be paused.”); conditional breakpoints representing interruptions occurred when a variable of interest satisfies a predefined condition during code execution; and location conditional breakpoints representing interruptions occurred at specific locations in the thread and simultaneously when a variable of interest satisfies a predefined condition.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Cheng in view of Sistare and Luo as applied to Claim 7 above, and further in view of US 11,200,151 (hereinafter “Cates”).
As per Claim 8, the rejection of Claim 7 is incorporated; and Cheng discloses “disabling the hook function in the [thread] (paragraph [0084], “The stop module 342 is used to stop the execution of the interrupt event function according to the termination instruction obtained by the acquisition module, so that the code can continue to execute.”; paragraph [0054], “Because the Python code executes within the IronPython object, and the IronPython object runs in the current thread of the C# program, you only need to write code that blocks the current C# thread to make it run.”),” but the combination of Cheng and Luo does not explicitly disclose:
disabling the hook function in the first thread when all breakpoints corresponding to the first thread have been executed or when no breakpoints corresponding to the first thread exist after a breakpoint update.
However, Cates discloses:
[stopping re-execution] when all breakpoints corresponding to the [commands] have been executed (col. 37 lines 47-50, “After logging the test result from a particular run of the software test, the debugging software can re-execute the software test again until all debugger commands corresponding to all breakpoints have been executed.”).
Cates is within the same field of endeavor as the claimed invention regarding the execution of breakpoints.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Cates into the combined teachings of Cheng and Luo to include “disabling the hook function in the [thread] when all breakpoints corresponding to the [commands] have been executed.” The modification would be obvious because one of ordinary skill in the art would be motivated to utilize a system that re-executes testing until all breakpoints have been executed in order to implement alterations/mutations in code which allows target code pathways to be tested during iterations of a software test without multiple independent versions of the source code being pre-generated and compiled, thereby reducing consumption of computing resources (Cates, col. 4 lines 50-59). Moreover, stopping re-execution once all of the breakpoints have run ensures that unnecessary execution doesn’t take place.
The combination of Cheng, Luo, and Cates does not explicitly disclose:
disabling the hook function in the first thread when all breakpoints corresponding to the first thread have been executed or when no breakpoints corresponding to the first thread exist after a breakpoint update.
However, Sistare discloses:
the first thread (col. 3 lines 45-49, “However, during a debugging session, requests from the program to create and delete threads are processed by the debugger 24. Thus, the debugger 24 will be aware of the existence of each of the threads.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Sistare into the combined teachings of Cheng, Luo, and Cates to include “disabling the hook function in the first thread when all breakpoints corresponding to the first thread have been executed or when no breakpoints corresponding to the first thread exist after a breakpoint update.” The modification would be obvious because one of ordinary skill in the art would be motivated to utilize a system with a debugger that creates threads and controls operations in connection with threads in order for the debugger to scale more appropriately and for more efficient debugging of multi-threaded programs (Sistare, col. 1 lines 9-11 & col. 4 line 67 to col. 5 lines 1-3).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Cheng in view of Sistare and Luo as applied to Claim 6 above, and further in view of US 2004/0193885 (hereinafter “Fisk”).
As per Claim 10, the rejection of Claim 6 is incorporated; and Cheng does not explicitly disclose:
communicating with the user through a communication thread of an intermediary layer, and storing the debug instruction received from the user in variables within the intermediary layer for sharing the debug instruction with the first thread through an API of the intermediary layer.
However, Luo discloses:
communicating with the user through a communication thread of an intermediary layer (paragraphs [0012 & 0013], “The user interface establishes a communication connection with the server. The user interface receives debugging instructions containing information about the code to be debugged from the debugger and then sends them to the server.”; paragraph [0116], “The debugging service running on the server can translate user operations into debugging commands.”; paragraph [0117], “The task of establishing virtual machine connections is handled by the virtual machine connection manager. Once the connection is successfully established, the user interaction layer will be notified of the connection result information.”);
the debug instruction received from the user (paragraph [0116], “The debugging service running on the server can translate user operations into debugging commands. These commands are sent to the virtual machine running the target program on the front end via a connection. The target virtual machine then performs the corresponding operation based on the received commands and sends the debugging results back to the debugging service on the server. The debugging service then sends the formatted data back to the user interface and provides visual data feedback to the user.”);
for sharing the debug instruction with the [thread] (paragraph [0116], “The debugging service running on the server can translate user operations into debugging commands. These commands are sent to the virtual machine running the target program on the front end via a connection. The target virtual machine then performs the corresponding operation based on the received commands and sends the debugging results back to the debugging service on the server. The debugging service then sends the formatted data back to the user interface and provides visual data feedback to the user.”; paragraph [0021], “The user interface provides a user interface for inputting debugging commands, setting breakpoint events, selecting source code segments, and displaying debugging results.”; paragraph [0141], “[…] when the corresponding condition is matched, the thread is suspended and the thread stack data is obtained and given to the user layer; according to the debugger's instructions, single-step debugging is performed […].”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Luo into the teaching of Cheng to include “communicating with the user through a communication thread of an intermediary layer; the debug instruction received from the user; for sharing the debug instruction with the [thread].” The modification would be obvious because one of ordinary skill in the art would be motivated to communicate with a user through a communication thread to share debug instructions with the thread in order to ensure the program is properly debugged according to the user’s instructions (Luo, paragraphs [0012, 0013, & 0016]).
The combination of Cheng and Luo does not explicitly disclose:
communicating with the user through a communication thread of an intermediary layer, and storing the debug instruction received from the user in variables within the intermediary layer for sharing the debug instruction with the first thread through an API of the intermediary layer.
However, Fisk discloses:
storing the [application state] in variables within the [storage] (paragraph [0052], “The variables to be saved as application "state" are kept, under program control as pool variables associated with the previously mentioned context identifier.”; paragraph [0065] “Step 5. The variable pool for each application function is decrypted and read into the Application Domain 108 from external storage 110.”) for sharing the [pool variables] with the [thread] through an API of the [pool variables] (paragraph [0055], “Each application thread has the ability to call the "pool" APIs as well as many other Vault Controller APIs while it is processing. The threads 116, use the pool variable functions "to get", "store" and "remove or delete" pool variables.”).
Fisk is within the same field of endeavor as the claimed invention regarding the use of APIs to share data with threads.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Fisk into the combined teachings of Cheng and Luo to include “communicating with the user through a communication thread of an intermediary layer, and storing the debug instruction received from the user in variables within the intermediary layer for sharing the debug instruction with the [thread] through an API of the intermediary layer.” The modification would be obvious because one of ordinary skill in the art would be motivated to store information in variables and utilize APIs for data sharing with threads in order to effectively centralize and organize where certain data is stored by using variables and effectively automate data exchange with reduced human intervention by utilizing APIs (Fisk, paragraphs [0052 & 0055]).
The combination of Cheng, Luo, and Fisk does not explicitly disclose:
communicating with the user through a communication thread of an intermediary layer, and storing the debug instruction received from the user in variables within the intermediary layer for sharing the debug instruction with the first thread through an API of the intermediary layer.
However, Sistare discloses:
the first thread (col. 3 lines 45-49, “However, during a debugging session, requests from the program to create and delete threads are processed by the debugger 24. Thus, the debugger 24 will be aware of the existence of each of the threads.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Sistare into the combined teachings of Cheng, Luo, and Fisk to include “communicating with the user through a communication thread of an intermediary layer, and storing the debug instruction received from the user in variables within the intermediary layer for sharing the debug instruction with the first thread through an API of the intermediary layer.” The modification would be obvious because one of ordinary skill in the art would be motivated to utilize a system with a debugger that creates threads and controls operations in connection with threads in order for the debugger to scale more appropriately and for more efficient debugging of multi-threaded programs (Sistare, col. 1 lines 9-11 & col. 4 line 67 to col. 5 lines 1-3).
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Cheng in view of Sistare and Luo as applied to Claim 1 above, and further in view of US 6,971,097 (hereinafter “Wallman”).
As per Claim 11, the rejection of Claim 1 is incorporated; and Cheng discloses “wherein the hook function is implemented in [C# language] (paragraph [0085], “Furthermore, the device uses Python code to edit the code and C# functions to edit the interrupt event function.”),” but the combination of Cheng, Sistare, and Luo does not explicitly disclose:
wherein the hook function is implemented in Lua language or C++ language.
However, Wallman discloses:
[…] implemented in C++ language (col. 11 lines 7-13, “A virtual machine may generally be created using any suitable computing language. Suitable computing languages include, but are not limited to, the C computing language, the C++ computing language, and the Java.TM. programming language. By way of example, a virtual machine created using the C or C++ computing languages may execute more efficiently than a virtual machine created using.”).
Wallman is within the same field of endeavor as the claimed invention regarding the creation of virtual machines in C++.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Wallman into the combined teachings of Cheng, Sistare, and Luo to include “wherein the hook function is implemented in Lua language or C++ language.” The modification would be obvious because one of ordinary skill in the art would be motivated to implement a function in C++ for more efficient execution compared to certain languages (Wallman, col. 11 lines 7-13).
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Cheng in view of Sistare and Luo as applied to Claim 1 above, and further in view of US 2022/0129212 (hereinafter “Koike”).
As per Claim 12, the rejection of Claim 1 is incorporated; and the combination of Cheng and Luo does not explicitly disclose:
creating a virtual machine for each first thread to be created, with only one thread running in each virtual machine.
However, Koike discloses:
creating a virtual machine for each [thread], with only one thread running in each virtual machine (paragraph [0032], “The VM 204 is generated for each thread of the expanded application installed in the image forming apparatus 100. FIG. 2 shows the configuration that a VM 204a and a VM 204b for running two threads of the expanded application 202 are generated, and a VM 204c for running one thread of the expanded application 203 is generated.”; paragraph [0034], “The VM thread 207a corresponds to the VM 204a, the VM thread 207b corresponds to the VM 204b, and the VM thread 207c corresponds to the VM 204c.”).
Koike is within the same field of endeavor as the claimed invention regarding the creation of virtual machines with a single thread running on each machine.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Koike into the combined teachings of Cheng and Luo to include “creating a virtual machine for each [thread], with only one thread running in each virtual machine.” The modification would be obvious because one of ordinary skill in the art would be motivated to utilize virtual machines created to run a single thread in order to achieve isolation where each thread operates within its own resources which can help prevent a failure/error in one thread/virtual machine from affecting the other threads/virtual machines (Koike, paragraphs [0032 & 0034]).
The combination of Cheng, Luo, and Koike does not explicitly disclose:
creating a virtual machine for each first thread to be created, with only one thread running in each virtual machine.
However, Sistare discloses:
first thread to be created (col. 3 lines 45-49, “However, during a debugging session, requests from the program to create and delete threads are processed by the debugger 24. Thus, the debugger 24 will be aware of the existence of each of the threads.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Sistare into the combined teachings of Cheng, Luo, and Koike to include “creating a virtual machine for each first thread to be created, with only one thread running in each virtual machine.” The modification would be obvious because one of ordinary skill in the art would be motivated to utilize a system with a debugger that creates threads and controls operations in connection with threads in order for the debugger to scale more appropriately and for more efficient debugging of multi-threaded programs (Sistare, col. 1 lines 9-11 & col. 4 line 67 to col. 5 lines 1-3).
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Cheng in view of Sistare, Luo, and Koike as applied to Claim 12 above, and further in view of Wallman and “Safe Record Sharing in Dynamic Programming Languages” (hereinafter “Skyrme”).
As per Claim 13, the rejection of Claim 12 is incorporated; and the combination of Cheng, Sistare, Luo, and Koike does not explicitly disclose:
wherein the virtual machine and the thread in the virtual machine are created by using C++ language through a Lanes library.
However, Wallman discloses:
wherein the virtual machine and the thread in the virtual machine are created by using [C++ language] (col. 11 lines 7-13, “A virtual machine may generally be created using any suitable computing language. Suitable computing languages include, but are not limited to, the C computing language, the C++ computing language, and the Java.TM. programming language. By way of example, a virtual machine created using the C or C++ computing languages may execute more efficiently than a virtual machine created using.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Wallman into the combined teachings of Cheng, Sistare, Luo, and Koike to include “wherein the virtual machine and the thread in the virtual machine are created by using [C++ language].” The modification would be obvious because one of ordinary skill in the art would be motivated to create a virtual machine using C++ language since virtual machines created using C++ may execute more efficiently than other languages (Wallman, col. 11 lines 7-13).
The combination of Cheng, Sistare, Luo, Koike, and Wallman does not explicitly disclose:
wherein the virtual machine and the thread in the virtual machine are created by using C++ language through a Lanes library.
However, Skyrme discloses:
using [C language] through a Lanes library (page 29, “The Lua C API allows C applications to create and manipulate multiple states at a time. In addition, when Lua code is loaded in a Lua state, its execution can be controlled just like a coroutine: it can be suspended (yielded) and resumed. The combination of multiple independent states and system threads allows for the implementation of Lua libraries for concurrent programming that support parallel execution. Examples of such libraries include luaproc [66] and Lua Lanes [53].”; page 29, “The Lua Lanes library, like luaproc, uses multiple Lua states to host independent execution flows of Lua code (or lanes). However, unlike luaproc, in Lua Lanes each execution flow of Lua code is associated with a single system thread, i.e., there is a 1:1 mapping.”).
Skyrme is within the same field of endeavor as the claimed invention regarding the utilization of the Lanes library.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Skyrme into the combined teachings of Cheng, Sistare, Luo, Koike, and Wallman to include “wherein the virtual machine and the thread in the virtual machine are created by using C++ language through a Lanes library.” The modification would be obvious because one of ordinary skill in the art would be motivated to utilize a Lanes library for effective parallel execution and the association of each execution flow of code with a single system thread (Skyrme, page 29).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Feven H. Huruy whose telephone number is (571) 272-3826. The examiner can normally be reached Mon-Fri. 7:30am-3:45pm.
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.
/F.H.H./Examiner, Art Unit 2191
/WEI Y MUI/Supervisory Patent Examiner, Art Unit 2191
Prosecution Insights