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 .
Claim Objections
Claims 15 and 20 are objected to because of the following informalities:
Claims 15 and 20 recite on Lines 3-5, “the alternate code-path” which should be “the second code-path”, as recited in Claim 6 which is similar to Claims 15 and 20.
Appropriate correction is required.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1, 11 and 16 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Breternitz, JR et al. (US PGPUB 2012/0079246; hereinafter “Breternitz”).
Claim 1:
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” [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 the 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.”).
Claim 11:
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:
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.”).
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 2-5, 7-10, 12-14 and 17-19 are rejected under 35 U.S.C. 103 as being unpatentable over Breternitz as applied to Claims 1, 11 and 16 above, and further in view of Pohlack et al. (US Patent 12,399,693; hereinafter “Pohlack”).
Claim 2:
Breternitz teaches all the limitations of claim 1 as described above. Breternitz does not teach the following, however, Pohlack teaches further comprising:
analyzing the application; and generating, in response to the analysis, a code-path map (Col. 8 Ln. 9-13: “With respect to FIG. 2, illustrative interactions are depicted for performing an initial analysis of a new code, including the development of guidance data in the form of an input map by a targeted fuzzing service,” wherein the “input map” is the “code-path map”. Col. 8 Ln. 63-66: “the targeted fuzzing service 110 performs an initial analysis and generates an input mapping. In some embodiments, the dynamic analysis may be performed simultaneously with the static analysis.”),
wherein the identifying the first error is in response to the generating the code-path map (Col. 9 Ln. 10-19: “The targeted fuzzer may generate progressive inputs to trigger execution of areas of executable code corresponding to the areas of source code identified by the static code analyzer 108 to be associated with potential defects... the targeted fuzzing service 110 may generate a map of inputs and associated execution paths as it analyzes the code.” Further, Col. 9 Ln. 28-36: “As the targeted fuzzing service 110 performs successive executions of the executable code with varying inputs, it may be configured to identify code defects that are triggered by the execution. For example, a particular input to an executable code may cause the code to crash or generate an error. In some embodiments, the targeted fuzzing service may be configured to note the defect, the execution path that led to it, and the input that caused execution of the execution path.”).
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 generating of a code-path map 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 3:
Breternitz in view of Pohlack 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 Pohlack 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:
Breternitz in view of Pohlack 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 most recent code-path; and initiating, in response to the rewinding, a third code-path available at the most recent 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 Pohlack 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 Pohlack 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.”).
Claim 9:
Breternitz in view of Pohlack teaches the method of claim 2. Breternitz 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 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:
Breternitz teaches the method of claim 1. Breternitz 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 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).
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 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Breternitz in view of Pohlack as applied to Claims 4 and 19 above, and further in view of Jana et al. (US PGPUB 2023/0129536; hereinafter “Jana”).
Claim 6:
Breternitz in view of Pohlack teaches all the limitations of claim 4 as described above. Breternitz in view of Pohlack 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 Pohlack 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 20:
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 15 is rejected under 35 U.S.C. 103 as being unpatentable over Breternitz as applied to Claim 11 above, and further in view of Jana.
Claim 15:
Breternitz teaches all the limitations of claim 11 as described above. Breternitz does not teach the following, however, Jana teaches wherein the program instructions are further configured to cause the processor to:
process the alternate 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.”);
flag the alternate 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
update the code-path map to indicate the alternate 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 system as disclosed by Breternitz 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]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure is as follows:
Bohling et al. (US PGPUB 2010/0251214) discloses an apparatus, system, and method for analyzing code paths, including a code path analyzer module which creates a decision map comprising the various code paths based on the analysis of the code listing.
Tapus et al. (“FixD : Fault Detection, Bug Reporting, and Recoverability for Distributed Applications,” 2007) discusses a system, called FixD, that addresses the problems of fault-detection, bug reporting, and recoverability of distributed applications, wherein FixD enables the execution to be resumed from a prior checkpoint, and a different path followed, when there is an error that occurs during execution of a distributed application.
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