DETAILED ACTION
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 .
Response to Amendment
With respect to Applicant’s amendment of claims 15 and 20 with regards to minor informalities, the claim objections with respect to the same have been withdrawn.
Claim Objections
Claims 2 and 12 are objected to because of the following informalities:
a. Claims 2 and 12 recite on Lines 4 and 5, respectively: “based on the the generating” which the Office believes should be “based on the [[the]] generating”.
Appropriate correction is 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, 11 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Breternitz, JR et al. (US PGPUB 2012/0079246; hereinafter “Breternitz”) in view of Alberi et al. (US PGPUB 2011/0296245; hereinafter “Alberi”).
Claim 1: (Currently Amended)
Breternitz teaches a computer-implemented method comprising:
identifying a first error during execution of an application ([0068] “As stated above program code may refer to compiler code, optimization code, application code, library code, or any other known formulation of code.” [0120] “speculative checkpoint code also includes fix-up (may also be referred to as roll-back, restore, reconstruct, recovery, etc.) code… the fix-up code may be entered from:… (3) an exception during speculative execution.” [0126] “in one embodiment, upon an interruption, hardware, software, or combination thereof makes a decision on what to do next. For example, assume a fault, such as a hardware generated fault/event, occurs during atomic execution. The atomic execution is interrupted.”);
determining, in response to the first error, a previous breakpoint in a first code-path of the application prior to a location of the first error ([0110] “upon encountering an actual hardware limitation, exception, interrupt, or other fault; the atomic region is capable of being rolled-back to a recent, interim checkpoint.”);
rewinding the application from the first error to the previous breakpoint; and initiating, in response to the rewinding, a second code-path available at the previous breakpoint ([0118] “Here, multiple scenarios exist for how to handle a roll-back within the optimized code. As a first example, as illustrated by Pseudo Code I below, a speculative checkpoint instruction is paired with a conditional (branch) instruction that is able to differentiate between normal loop execution or a re-execution after a rollback to a speculative checkpoint. The branch instruction, when executed, jumps to a different execution path to handle the roll-back.”).
With further regard to Claim 1, Breternitz does not teach the following, however, Alberi teaches:
wherein the first error is based on executing code of the application ([0051] “When a software failure occurs, the failed process recovers by using the checkpoints and logged data descriptors to replay the corresponding nondeterministic events precisely as they occurred during the pre-failure execution. The process is rolled back to the prior checkpoint.” [0060] “Each process takes checkpoints to reduce the extent of rollback during recovery. After a failure occurs, the failed processes recover by using the checkpoints and logged data descriptors to replay the corresponding nondeterministic events precisely as they occurred during the pre-failure execution.” [0064] “If a software failure occurs during execution of one of the probe virtual machines 104…”).
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 modified the method as disclosed by Breternitz with the further application error details as taught by Alberi in order “ to reduce the extent of rollback during recovery” (Alberi [0060]).
Claim 11: (Currently Amended)
With regard to Claim 11, this claim is equivalent in scope to Claim 1 rejected above, merely having a different independent claim type, and as such Claim 11 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 1.
With further regard to Claim 11, the claim recites additional elements not specifically addressed in the rejection of Claim 1. The Breternitz reference also anticipates these additional elements of Claim 11, for example, wherein the system comprises:
a processor ([0047] “processor 100 is capable of executing a compiler/optimization code 177 to compile application code 176 to support transactional execution, as well as to potentially optimize application code 176.”); and
a computer-readable storage medium communicatively coupled to the processor and storing program instructions which, when executed by the processor, are configured to cause the processor to [perform operations] ([0150] “The embodiments of methods, hardware, software, firmware or code set forth above may be implemented via instructions or code stored on a machine-accessible or machine readable medium which are executable by a processing element.”).
Claim 16: (Currently Amended)
With regard to Claim 16, this claim is equivalent in scope to Claim 1 rejected above, merely having a different independent claim type, and as such Claim 16 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 1.
With further regard to Claim 16, the claim recites additional elements not specifically addressed in the rejection of Claim 1. The Breternitz reference also anticipates these additional elements of Claim 16, for example, Breternitz teaches:
A computer program product, the computer program product comprising a computer readable storage medium having program instructions embodied therewith, the program instructions executable by a processing unit to cause the processing unit to [perform operations] ([0150] “The embodiments of methods, hardware, software, firmware or code set forth above may be implemented via instructions or code stored on a machine-accessible or machine readable medium which are executable by a processing element.”).
Claims 2-5, 7-8, 12-14 and 17-19 are rejected under 35 U.S.C. 103 as being unpatentable over Breternitz in view of Alberi as applied to Claims 1, 11 and 16 above, and further in view of Bohling et al. (US PGPUB 2010/0251214; hereinafter “Bohling”).
Claim 2: (Currently Amended)
Breternitz in view of Alberi teaches all the limitations of claim 1 as described above. Breternitz in view of Alberi does not teach the following, however, Bohling teaches further comprising:
analyzing the application; and generating, in response to the analyzing, a code-path map ([0059] “A code path analyzer module 206 determines 306 each code path flowing from the starting point to the ending point by analyzing the listing of code 106 without execution of the code. This may be done in some embodiments by utilizing a map module 210 to scan the code listing 106 for divergent code paths and generating a decision map corresponding to the various potential code paths between the starting point and ending point.”),
wherein the determining the previous breakpoint is based on the the generating the code-path map ([0012] “a map module that generates a decision map by scanning the listing of code for decision statements, each decision statement comprising code from which two or more code paths diverge,” wherein a “decision statement” is a breakpoint. [0013] “the decision map comprising a representation of decision statements, each decision statement comprising code from which two or more code paths diverge.” [0044] “For example, if a computer program crashes, a user may identify the point at which the program crashed. The user may then be interested in identifying the various paths that possibly lead to the failure point from a known starting point.” [0047] “The starting point typically includes code from which one or more code paths flow. For example, the starting point may be a module, instruction, or other point in the code that lead to additional… code path branches.” [0048] “the start module 202 may receive information that a program failed or crashed within a particular portion of code. In response to that information the start module 202 may determine a starting point at which to begin analysis of the code listing.”).
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 modified the method as disclosed by Breternitz in view of Alberi with the generating of a code-path map as taught by Bohling since “a need exists for an apparatus, system, and method that provide information about and analysis of code paths within large and complex products” (Bohling [0006]), wherein “identification of such potential code paths enables for much more efficient code analyzation and troubleshooting” (Bohling [0044]) and further wherein “This information enables a user or program… to force a particular code path for execution during troubleshooting or other processes” (Bohling [0051]).
Claim 3:
Breternitz in view of Alberi and Bohling teaches the method of claim 2, and Breternitz further teaches:
wherein each breakpoint is associated with a critical portion of the application ([0111] “Turning to FIG. 7a, an embodiment of a flow diagram for a method of optimizing code including providing for speculative checkpoints within a transaction is depicted. In block 705, a section of program code to be optimized is identified… a section/region of code may be identified based on a user identification/hint regarding the section, program analysis, code profiling, code attributes (specific type, format, order, or characteristic--a loop or number of stores--of the region), or other known method for identifying a code region that is to be optimized.” [0112] “In block 720, a speculative checkpoint location within the program code is determined. Note that multiple speculative checkpoints may be determined/assigned within a region of code to be optimized”).
Claim 4:
Breternitz in view of Alberi and Bohling teaches the method of claim 2, and Breternitz further teaches:
wherein the code-path map comprises one or more breakpoints, each breakpoint comprises two or more distinct code-paths configured to obtain a common result ([0122] “Furthermore, in one embodiment, the conditional commit instruction is made aware of the speculative checkpoint, as shown in Pscudo Code L below,” see the diagram below Paragraph [0122] which shows a “Speculative Checkpoint”, i.e. a “breakpoint”, in Code Block B5 which comprises two distinct code paths, i.e. B5->B6->B2 and B-5>B-2, which both obtain a common result.).
Claim 5: (Currently Amended)
Breternitz in view of Alberi and Bohling teaches the method of claim 4, and Breternitz teaches further comprising:
identifying, on the second code-path, a second error ([0068] “As stated above program code may refer to compiler code, optimization code, application code, library code, or any other known formulation of code” [0126] “in one embodiment, upon an interruption, hardware, software, or combination thereof makes a decision on what to do next. For example, assume a fault, such as a hardware generated fault/event, occurs during atomic execution. The atomic execution is interrupted.”);
rewinding the application to the previous breakpoint; and initiating, in response to the rewinding, a third code-path available at the previous breakpoint ([0118] “Here, multiple scenarios exist for how to handle a roll-back within the optimized code. As a first example, as illustrated by Pseudo Code I below, a speculative checkpoint instruction is paired with a conditional (branch) instruction that is able to differentiate between normal loop execution or a re-execution after a rollback to a speculative checkpoint. The branch instruction, when executed, jumps to a different execution path to handle the roll-back.” [0112] “Also similar to the discussion of FIG. 2a, in flows 710, 715 the region of code is demarcated (insert start atomic region instruction at beginning of the section and an end atomic region instruction at the end of the section). And as aforementioned, the code region may include multiple entries and multiple exits. In block 720, a speculative checkpoint location within the program code is determined. Note that multiple speculative checkpoints may be determined/assigned within a region of code to be optimized.”).
Claim 7:
Breternitz in view of Alberi and Bohling teaches the method of claim 4, and Breternitz teaches further comprising:
recording, at each breakpoint, a set of rewind data, wherein the rewind data captures a state of the application prior to proceeding down a relevant code-path, wherein the set of rewind data is configured to allow the rewinding ([0115] “In flow 726, a speculative checkpoint instruction/operation (L1 in B5) is inserted at the speculative checkpoint (loop back edge of B2, B5). In one embodiment, the speculative checkpoint instruction includes any instruction to initiate a checkpoint (current snapshot) of speculative hardware resources. For example, the speculative checkpoint instruction is recognizable by decoders of a processor. And once decoded. scheduled, and executed, causes a speculative register file, a store buffer, or both to be checkpointed (a snapshot of the current state) into checkpoint storage structures, such as a checkpoint speculative register file and a speculative cache.”).
Claim 8:
Breternitz in view of Alberi and Bohling teaches the method of claim 4, and Breternitz teaches further comprising:
determining, in response to the rewinding, all code-paths associated with the breakpoint have an identified error; and rewinding to a next most recent breakpoint ([0127] “Here, the software, such as a handler may decide on what to do next based on any number of factors, such as the type of fault, the difficulty in rolling-back to a most-recent speculative checkpoint, the number of instructions or amount of execution lost by rolling back to a last commit point instead of the most recent speculative checkpoint, or other known factor in choosing a point of execution in a program for a return. Essentially, in this illustrative example, software, such as a handler is making the determination if execution should be rolled-back to the start of an atomic region, the last commit point within the atomic region, or a latest speculative checkpoint within the atomic region. And even though the examples have focused on software making the decision, hardware may also make such a decision. In one embodiment, a new instruction (speculative_rollback) is utilized in making the determination. Here, the speculative_rollback instruction includes any information that once decoded and executed results in a return to the appropriate (speculative checkpoint or recent commit point) in the program code.”).
Claims 12-14:
With regard to Claims 12-14, these claims are equivalent in scope to Claims 2-4 rejected above, merely having a different independent claim type, and as such Claims 12-14 are rejected under the same grounds and for the same reasons as discussed above with regard to Claims 2-4.
Claims 17-19:
With regard to Claims 17-19, these claims are equivalent in scope to Claims 2-4 rejected above, merely having a different independent claim type, and as such Claims 17-19 are rejected under the same grounds and for the same reasons as discussed above with regard to Claims 2-4.
Claims 6, 15 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Breternitz in view of Alberi and Bohling as applied to Claims 4, 12 and 19 above, and further in view of Jana et al. (US PGPUB 2023/0129536; hereinafter “Jana”).
Claim 6:
Breternitz in view of Alberi and Bohling teaches all the limitations of claim 4 as described above. Breternitz in view of Alberi and Bohling does not teach the following, however, Jana teaches further comprising:
processing the second code-path with no errors ([0021] “this technique identifies new execution paths of the changed source code and categorizes them as safe or unsafe based on semantics which helps in detecting presence of such execution paths.”);
flagging the second code-path as error-free ([0034] “an example as depicted in Table 1, where the system 100 processes the received source code as input along with the property to be verified for identification of new program paths for categorizing as safe path and unsafe path… Table 2 shows categorization of new execution paths for each of the other lines. Paths are represented using sequence of line numbers, where start point of program is represented by start… New paths reaching variables y (at line 3), p (at line 8), and q (at line 11), have definition at line 1, 4, and 9, respectively. These new paths belong to the category C2, as the definitions (being present) ensure that the property cannot be violated… the paths in C1 and C2 are safe.”); and
updating the code-path map to indicate the second code-path as a preferred code-path ([0021] “this technique identifies new execution paths of the changed source code and categorizes them as safe or unsafe based on semantics which helps in detecting presence of such execution paths. This technique incrementally builds required dataflow analysis and program dependence information for the source code which is time efficient and accurate.” [0030] “The program analysis module 208 of the system 100 obtains input from the preprocessing stage and generates a data flow analysis (DFA) and a program dependency graph (PDG) for the current version of the source code incrementally.”).
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 modified the method as disclosed by Breternitz in view of Alberi and Bohling with the flagging of code paths as taught by Jana in order to “lessen the burden of a testing or a model checking engine, or even a developer, by presenting only likely unsafe paths to them” (Jana [0005]).
Claim 15: (Currently Amended)
With regard to Claim 15, this claim is equivalent in scope to Claim 6 rejected above, merely having a different independent claim type, and as such Claim 15 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 6.
Claim 20: (Currently Amended)
With regard to Claim 20, this claim is equivalent in scope to Claim 6 rejected above, merely having a different independent claim type, and as such Claim 20 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 6.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Breternitz in view of Alberi and Bohling as applied to Claim 2 above, and further in view of Pohlack et al. (US Patent 12,399,693; hereinafter “Pohlack”).
Claim 9:
Breternitz in view of Alberi and Bohling teaches the method of claim 2. Breternitz in view of Alberi and Bohling does not teach the following, however, Pohlack teaches:
wherein the first code-path is newly deployed code, and the second code-path is previously used code (Col. 10 Ln. 55-62: “the static code analyzer 108 may receive binary executable codes corresponding to two versions of the source code, and may trace the execution paths of the executable codes to identify new or changed paths. Alternatively, the build service 106 may perform the differential analysis of executable codes and provide the static code analyzer 108 with data indicating which execution paths in the executable code have been altered or added.” Col. 12 Ln. 17-24: “It may be desirable to analyze the changed code to identify whether any defects have been produced. To facilitate dynamic analysis, at (3) the input map 116 is referenced to identify inputs corresponding to execution paths that are known to include the changed function. Illustratively, F5′ may be reached by execution path F1-F2-F5 or by F1-F3-F5, by using inputs B, C or A, D, respectively,” wherein Fig. 4 shows “code-paths” comprising “newly deployed code” and “previously used code”.).
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 modified the method as disclosed by Breternitz in view of Alberi and Bohling with the code paths comprising different versions of code as taught by Pohlack in order “to guide the dynamic analysis to prioritize or cover only those segments of code for which defects have been identified, reducing both the computational and time cost of the dynamic analysis” (Pohlack Col. 3 Ln. 64-67).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Breternitz in view of Alberi as applied to Claim 1 above, and further in view of Pohlack.
Claim 10:
Breternitz in view of Alberi teaches the method of claim 1. Breternitz in view of Alberi does not teach the following, however, Pohlack teaches further comprising:
logging the first error (Col. 9 Ln. 54-55: “the targeted fuzzing service 110 may store the defects in defect storage 112”); and
generating an error report comprising the first error report and any additional identified errors (Col. 9 Ln. 56-62: “At (10), the static code analyzer 108 stores a report of identified defects in defect storage 112. In some embodiments, the defect report may comprise a list of identified defects and associated information, including the code paths associated with the defects, the nature and/or severity of defect, the version of the code in which the defect was detected, etc.”).
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 modified the method as disclosed by Breternitz in view of Alberi with the error report as taught by Pohlack in order “to guide the dynamic analysis to prioritize or cover only those segments of code for which defects have been identified, reducing both the computational and time cost of the dynamic analysis” (Pohlack Col. 3 Ln. 64-67).
Response to Arguments
Applicant's arguments, see Pages 9-11 of the Remarks filed April 21, 2026, with respect to the rejections under 35 U.S.C. 102/103 of Claims 1-20 have been fully considered but they are not persuasive.
With respect to the Applicant’s argument, Pages 9-10, that the newly amended language of Claims 1, 11 and 16 is not taught by the previously cited prior art, this argument has been fully considered but is moot in view of the newly cited Alberi et al. (US PGPUB 2011/0296245) reference as discussed above in the respective rejections.
With respect to the Applicant’s next argument, Pages 10-11, that the newly amended language of Claims 2, 12 and 17 is not taught by the previously cited prior art, this argument has been fully considered but is moot in view of the newly cited Bohling et al. (US PGPUB 2010/0251214) reference as discussed above in the respective rejections.
With respect to the Applicant’s further arguments, Page 10 Paragraph 7 of the Remarks, that the features of the remaining claims are not taught by the cited prior art, the Office respectfully disagrees. These arguments rely upon the arguments as presented in relation to claims discussed above, and as such the Office directs the Applicant to the responses above regarding these arguments.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure is as follows:
Hicks et al. (US PGUPB 2020/0394129) discusses a method for automatically avoiding fault paths in software code of a System Under Test (SUT), including the ability to determine which breakpoints are encountered during execution of the fault code path, the number of times each such breakpoint is encountered and an order in which the breakpoints are encountered.
Zhao et al. (“Compiler support for fine-grain software-only checkpointing,” 2012) discusses a proposal for a lightweight and fine-grain checkpointing framework implemented entirely in software, through compiler transformations and optimizations, wherein the programmer can specify arbitrary checkpoint regions and the compiler automatically transforms the code to enable checkpointing for those regions.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Joanne G. Macasiano whose telephone number is (571)270-7749. The examiner can normally be reached Monday to Thursday, 10:30 AM to 6:00 PM Eastern Standard Time.
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, Bradley Teets can be reached at (571) 272-3338. 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.
/JOANNE G MACASIANO/Examiner, Art Unit 2197
Prosecution Insights