DETAILED ACTION
Remarks
Applicant’s amendment and response dated 5/27/2026 has been provided in response to the 4/7/2026 Office Action which rejected claims 1-20, wherein claims 1-3, 5, 8-10, and 12-20 have been amended. Thus, claims 1-20 remain pending in this application and have been fully considered by the examiner.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Response to Arguments
Applicant’s arguments, see pages 8-10, filed 5/27/2026, with respect to claims 1-20 have been fully considered and are persuasive. The rejection of claims 1-20 under 35 U.S.C 101 has been withdrawn.
Applicant’s arguments with respect to claims have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Objections
Claims 8-14 are objected to because of the following informalities:
Claim 8, “the optimized binary” and “the non-optimized binary” in lines 5-6 lack proper antecedent basis.
Claims 9-14 depend on the objected claim and inherit the same issue.
Appropriate correction is required.
Claim Interpretation
As to claims 3 and 6, Applicant should please note that "The broadest reasonable interpretation of a method (or process) claim having contingent limitations requires only those steps that must be performed and does not include steps that are not required to be performed because the condition(s) precedent are not met. For example, assume a method claim requires step A if a first condition happens and step B if a second condition happens. If the claimed invention may be practiced without either the first or second condition happening, then neither step A or B is required by the broadest reasonable interpretation of the claim. If the claimed invention requires the first condition to occur, then the broadest reasonable interpretation of the claim requires step A. If the claimed invention requires both the first and second conditions to occur, then the broadest reasonable interpretation of the claim requires both steps A and B; See Ex parte Schulhauser, Appeal 2013-007847 (PTAB April 28, 2016) (precedential) for an analysis of contingent claim limitations in the context of both method claims and system claims. In Schulhauser, both method claims and system claims recited the same contingent step. When analyzing the claimed method as a whole, the PTAB determined that giving the claim its broadest reasonable interpretation, "[i]f the condition for performing a contingent step is not satisfied, the performance recited by the step need not be carried out in order for the claimed method to be performed" (quotation omitted). Schulhauser at 10. When analyzing the claimed system as a whole, the PTAB determined that "[t]he broadest reasonable interpretation of a system claim having structure that performs a function, which only needs to occur if a condition precedent is met, still requires structure for performing the function should the condition occur." Schulhauser at 14. Therefore "[t]he Examiner did not need to present evidence of the obviousness of the [] method steps of claim 1 that are not required to be performed under a broadest reasonable interpretation of the claim (e.g., instances in which the electrocardiac signal data is not within the threshold electrocardiac criteria such that the condition precedent for the determining step and the remaining steps of claim 1 has not been met);" however to render the claimed system obvious, the prior art must teach the structure that performs the function of the contingent step along with the other recited claim limitations. Schulhauser at 9, 14" - see MPEP 2114.04 (II). Therefore, the steps of “adding a guard breakpoint when a breakpoint within the optimized binary is identified” and “sending a notification when a pre-set time constraint is exceeded”, as recited in claims 3 and 6 respectively, are contingent limitations, given their broadest reasonable interpretation, and are not required.
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, 2, 8, 9, 15 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over by Guan et al. (US Patent Application Publication 2014/0289707 A1) in view of Tallam et al. (US Patent Application Publication 20150317139 A1).
As to claim 1, Guan teaches a computer-implemented method for dynamic redirection between an optimized binary and a non-optimized binary during execution of the optimized binary by a debugger (See e.g. [0011]- A method, system, and/or computer program product enable dynamic code switching in a debugging process. A first version of a binary and a second version of a binary for each compiling unit in the source code program are generated, where the first version is an optimized version, and wherein the second version is a non-optimized debuggable version), comprising:
obtaining the optimized binary and a non-optimized binary for debugging a corresponding binary by the debugger (see e.g. Fig.6 and associated text, e.g. [0038]- In step 610, for a source code program to be debugged, a first version of binary and a second version of binary are generated for each compiling unit in the source code program, wherein the first version is an optimized version, the second version is a non-optimized debuggable version),
causing execution of the optimized binary or the non-optimized binary by the debugger during a debugging process (See e.g. [0051]- In step 620, the debugger loads the first version of binaries of all the compiling units in memory to be run by the debugger, as shown in step 1 in FIG. 8. This ensures that performance is prioritized by default. Here, it is noted that when the optimized version of binary is loaded into the memory, the bubbles are reserved in the memory so as to leave enough space for possible later code switching),
triggering redirection between the optimized binary and the non-optimized binary during the debugging process (See e.g. Fig. 8 and associated text, e.g. [0050]- With reference to FIG. 6 again, steps 620-650 are performed by the debugger, and correspond to the trigger behaviors in FIG. 8, [0053]- According to the result of monitoring in step 630, in step 640, in response to the determination that a compiling unit in the source code program is to be debugged, the second version of binary of the compiling unit is dynamically loaded in the same storing address in the memory as that of the first version of binary of the compiling unit; For example, step 2 in FIG. 8 may be referred to) and [0054]- According to the result of monitoring in step 630, in step 650, in response to a determination that debugging of a compiling unit in the source code program is to be cancelled, the first version of binary of the compiling unit is dynamically reloaded in the same storing address in the memory as that of the second version of binary of the compiling unit. For example, step 3 in FIG. 8 may be referred to), wherein the redirection is triggered based on encountering a trigger during the debugging process, the trigger including at least one of a trigger for causing redirection from the optimized binary to the non-optimized binary that includes identifying a breakpoint within the optimized binary during execution of the optimized binary (see e.g. [0052]- The debugging operation refers to various debugging operations on source codes performed by the user on a source code view through a debugger. Examples of debugging operations may include: set a breakpoint and [0055]- the determination that a compiling unit in the source code program is to be debugged comprises: setting a first breakpoint in a compiling unit) [or a trigger for causing redirection from the non-optimized binary to the optimized binary that includes encountering an updated position independent portion within the non-optimized binary during execution of the non- optimized binary and which redirects execution of the debugger to a location in the optimized binary corresponding to the location identifier of the optimized binary;] and
redirecting execution between the optimized binary and the non-optimized binary based on the trigger wherein redirection is performed seamlessly without recompiling the optimized binary or the non-optimized binary (see e.g. [0058]-[0059] and Fig.9 and associated text, e.g. [0060]- FIG. 9 is a block diagram showing a system for dynamic code switching in debugging process according to an embodiment of the present invention; The debugger is configured to: load the first version of binaries of all the compiling units in memory; monitor the user's debugging operation; in response to a determination that a compiling unit in the source code program is to be debugged, dynamically reload the second version of binary of the compiling unit in the same storing address in the memory as that of the first version of binary of the compiling unit; and in response to a determination that debugging of a compiling unit in the source code program is to be cancelled, dynamically reload the first version of binary of the compiling unit in the same storing address in the memory as that of the second version of binary of the compiling unit).
Guan teaches the non-optimized binary and the optimized binary (see e.g. [0038]), does not specifically teach wherein the non-optimized binary includes one or more position independent portions created during compilation of the non-optimized binary or updating the one or more position independent portions based on a location identifier.
In an analogous art of software debugging, however, Tallam teaches wherein a non-optimized binary includes one or more position independent portions created during compilation of the non-optimized binary (see e.g. Fig.4 and associated text, e.g. [0033]- An example method begins with compiling position independent code to create an executable binary without creating memory loads for obtaining global variable addresses as illustrated in FIG. 4 (403). A global variable may be identified within the position independent code (405) and it may be determined whether the global variable is defined in the executable binary (407) and updating the one or more position independent portions based on a location identifier (e.g. address, see e.g. [0033]- If the global variable is not defined in the executable binary, a definition for the global variable may be created in the executable binary reducing the need to load the global variable's address from memory. The executable may have data sections that define various global variables. A definition may be created in the executable by reserving enough bytes of memory at the next available address offset, for example, 0xafbc, in the data section, to hold the entire size of the global variable in the data section. The global variable may be accessed using this address (offset).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Guan to incorporate/implement the limitations as taught by Tallam in order to provide a more efficient method of developing and optimizing software for the purpose of improving performance.
As to claim 2, Guan also teaches compiling the optimized binary (See e.g. [0038], wherein both the optimized binary and the non-optimized binary are concurrently stored in memory prior to execution (see e.g. [0045]- two versions of binaries (compiled versions of original codes) are generated, which are for example referred to as opt bin (i.e., optimized version) and dbg bin(i.e., non-optimized version) below. These two versions of binaries are linked into a same executable by a linker).
As to claim 8, the limitations of the claims are substantially similar to the limitations of claim 1, and therefore, it is rejected for the reasons stated above.
As to claim 9, the limitations of the claims are substantially similar to the limitations of claim 2, and therefore, it is rejected for the reasons stated above.
As to claim 15, the limitations of the claims are substantially similar to the limitations of claim 1, and therefore, it is rejected for the reasons stated above.
As to claim 16, the limitations of the claims are substantially similar to the limitations of claim 2, and therefore, it is rejected for the reasons stated above.
Claims 3-4, 10-11, and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Guan et al. (US Patent Application Publication 2014/0289707 A1) in view of Tallam et al. (US Patent Application Publication 20150317139 A1), as applied to claims 1, 8, and 15 above, and further in view of Iyer et al. (US Patent Application Publication 2020/0125475 A1).
As to claim 3, Guan in view of Tallam teaches the optimized binary (see e.g. [0038]), but does not specifically teach adding a guard breakpoint when a breakpoint is identified.
In an analogous art of software debugging, however, Iyer teaches adding a guard breakpoint (e.g. adding instrumentation) when a breakpoint is identified (See e.g. [0068]- the instrumentation module 150 identifies segments of the source code that are to be instrumented according to correlations between the control flow graph 170 and the source code such as procedural transitions within the source code as identified by directed edges in the graph 170 or locations where a data argument is used/modified as identified in the graph 170; Moreover, the instrumentation module 150 automatically adds the instrumentation according to the identified segments); Applicant should please note that because the limitation of “adding a guard breakpoint when a breakpoint within the optimized binary is identified” is a contingent limitation, the limitation of adding a guard breakpoint, as taught by Iyer, meets the requirements of the claim).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Guan in view of Tallam to incorporate/implement the limitations as taught by Iyer in order to provide a more efficient method of developing and debugging software.
As to claim 4, Iyer further teaches wherein the guard breakpoint is added based on a dependency graph (See e.g. [0068]- the instrumentation module 150 identifies segments of the source code that are to be instrumented according to correlations between the control flow graph 170 and the source code such as procedural transitions within the source code as identified by directed edges in the graph 170 or locations where a data argument is used/modified as identified in the graph 170; Moreover, the instrumentation module 150 automatically adds the instrumentation according to the identified segments).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Guan in view of Tallam to incorporate/implement the limitations as taught by Iyer in order to provide a more efficient method of developing and debugging software.
As to claim 10, Guan in view of Tallam teaches the optimized binary (see e.g. [0038]), and when a breakpoint within the optimized binary is identified (see e.g. [0052]), but does not specifically teach adding a guard breakpoint.
In an analogous art of software debugging, however, Iyer teaches adding a guard breakpoint (e.g. adding instrumentation, See e.g. [0068]- the instrumentation module 150 identifies segments of the source code that are to be instrumented according to correlations between the control flow graph 170 and the source code such as procedural transitions within the source code as identified by directed edges in the graph 170 or locations where a data argument is used/modified as identified in the graph 170; Moreover, the instrumentation module 150 automatically adds the instrumentation according to the identified segments);
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Guan in view of Tallam to incorporate/implement the limitations as taught by Iyer in order to provide a more efficient method of developing and debugging software.
As to claim 11, Iyer further teaches wherein the guard breakpoint is added based on a dependency graph (See e.g. [0068]- the instrumentation module 150 identifies segments of the source code that are to be instrumented according to correlations between the control flow graph 170 and the source code such as procedural transitions within the source code as identified by directed edges in the graph 170 or locations where a data argument is used/modified as identified in the graph 170; Moreover, the instrumentation module 150 automatically adds the instrumentation according to the identified segments).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Guan in view of Tallam to incorporate/implement the limitations as taught by Iyer in order to provide a more efficient method of developing and debugging software.
As to claim 17, the limitations of the claims are substantially similar to the limitations of claim 10, and therefore, it is rejected for the reasons stated above.
As to claim 18, the limitations of the claims are substantially similar to the limitations of claim 11, and therefore, it is rejected for the reasons stated above.
Claims 6 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Guan et al. (US Patent Application Publication 2014/0289707 A1) in view of Tallam et al. (US Patent Application Publication 20150317139 A1), as applied to claims 1 and 8 above, and further in view of Taylor et. al (US Patent Application Publication 2015/0347274 A1).
As to claim 6, Guan in view of Tallam teaches the limitations of claim 1, but does not specifically teach sending a notification when a pre-set time constraint is exceeded.
In an analogous art of software debugging, however, Taylor teaches sending a notification when a pre-set time constraint is exceeded (see Fig.4 and associated text, e.g. [0086]- an example debugger GUI 122; visual representations 210, and [0160]- the timing information 210 will be displayed to the user if the elapsed time of the debuggee exceeds a predefined threshold (such as one defined below or one defined by a user), and the “run operation” under the debugger meets certain criteria).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Guan in view of Tallam to incorporate/implement the limitations as taught by Taylor in order to provide a more efficient method of developing and debugging software for the purpose of improving performance.
As to claim 13, the limitations of the claims are substantially similar to the limitations of claim 6, and therefore, it is rejected for the reasons stated above.
Claims 7, 14, and 20 are rejected under 35 U.S.C. 103 as being unpatentable Guan et al. (US Patent Application Publication 2014/0289707 A1) in view of Tallam et al. (US Patent Application Publication 20150317139 A1), as applied to claims 1, 8, and 15 above, and further in view of Bashkansky et al. (US Patent Application Publication 2009/0064117 A1).
As to claim 7, Guan in view of Tallam teaches the limitations of claim 1, but does not specifically teach displaying the optimized binary and the non-optimized binary on a user interface.
In an analogous art of code optimization, however, Bashkansky teaches displaying the optimized binary and the non-optimized binary on a user interface (See e.g. Fig.1 and associated text, e.g. [0044]- Code analyzer 150 generates as output, or otherwise displays, visual representations of the determined differences between two or more of programs 131, 132 and/or 133. For example, code analyzer 150 displays a visual representation 160 showing instructions (e.g., assembly language instructions) of the non-optimized program 131, for example, a visualization 162 of the non-optimized program. In addition, code analyzer 150 displays a visual representation 170, showing instructions (e.g., assembly language instructions) of the first optimized program 132).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Guan in view of Tallam to incorporate/implement the limitations as taught by Bashkansky in order to provide a more efficient method of analyzing different versions of code that would facilitate faster debugging and optimization of the code.
As to claim 14, the limitations of the claims are substantially similar to the limitations of claim 7, and therefore, it is rejected for the reasons stated above.
As to claim 20, the limitations of the claims are substantially similar to the limitations of claim 7, and therefore, it is rejected for the reasons stated above.
Allowable Subject Matter
Claims 5, 12, 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 CHENECA SMITH whose telephone number is (571)270-1651. The examiner can normally be reached Mon-Fri 8:00AM-4:30PM EST.
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, Hyung S Sough can be reached at 571-272-6799. 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.
/CHENECA SMITH/Examiner, Art Unit 2192
/S. Sough/SPE, Art Unit 2192
Prosecution Insights