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 6, 14, and 19 are objected to because of the following informalities:
Claim 6, line 3: replace “that item” with --the item--.
Claim 14, line 3: “the instructions” lacks proper antecedent basis.
Claim 19, line 3: replace “that trace data sequence” with --the trace data sequence--.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 10, 11, 12, 13, 14, 15, 16, 18, and 19 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claims 10, 11, 12, 13, 14, 15, and 16, it is unclear whether or not “the predicted trace data” referred to in line 7 of claim 10 is referencing the predicted trace data in line 4 of claim 10 or line 7 of claim 1. For examination purposes, the claim will be treated as referring to --the predicted trace data-- in line 7 of claim 1.
Regarding claim 12,
line 4: “that could be” is indefinite. For examination purposes, the claim will be treated at --to be--.
Regarding claim 18,
line 9: it is unclear whether or not “a sequence of events” is referring to the sequence of events introduced in line 5, or a new instance of a sequence of events. For examination purposes, the claim will be treated as “the sequence of events”.
line 9: it is unclear whether or not “a target program” is referring to the target program introduced in line 6, or a new instance of a target program. For examination purposes, the claim will be treated as “the target program”.
lines 9-10: it is unclear whether or not “a processor” is referring to the processor introduced in line 6, or a new instance of a processor. For examination purposes, the claim will be treated as “the processor”.
Regarding claim 19,
line 2: it is unclear whether or not “the sequence of events” is referring to the sequence of events introduced in line 5 of claim 18 or line 9 of claim 18. For examination purposes, the claim will be treated as referring to “the sequence of events” in line 5 of claim 18.
line 3: it is unclear whether or not “that trace data sequence” is referring to “each trace data sequence” introduced in line 8 of claim 18 or line 1 or claim 19. For examination purposes, the claim will be treated as referring to “each trace data sequence” in line 8 of claim 18.
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 20 is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim does not fall within at least one of the four categories of patent eligible subject matter because the claim is directed toward a program, which is considered software per se.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 2, 3, 4, 5, 7, 17, 18, 19, 20, and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Pei et al. (StateFormer: Fine-Grained Type Recovery from Binaries using Generative State Modeling, Pei hereinafter) in view of Cui et al. (US10565511, Cui hereinafter).
Regarding claim 1, Pei discloses: A method for trace generation (Pei, see page [692] section 2.3 paragraph 2, “The training task performed in GSM requires a neural network to reconstruct the whole micro-execution traces (i.e., all recorded program states) in the training data based on the corresponding code blocks…”), comprising:
obtaining input trace data (“runtime execution traces”) indicative of a sequence of events occurring during execution of a target program on (Pei, see page [694] section 3.1 paragraph 1, “To train StateFormer with GSM, we need to obtain runtime execution traces of binary programs…”);
providing a query input (“𝜇State traces”) to a trained generative machine learning model, where the query input is based on the input trace data (Pei, see page [691] col 2 paragraph 2, “We design a novel pretraining task, Generative State Modeling (GSM), where we train a neural network to reconstruct the complete set of its execution states while taking the assembly code and a very small subset of its execution states (e.g., register values at specific program points) as input…”), (see Pei, page 694 col 1 paragraph 2, “We collect 𝜇State traces and mask a random subset of them to train the model to reconstruct the complete 𝜇State trace. 𝜇State consists of two sources of information. (1) The concrete values of all registers, memory addresses, and hardcoded offsets that appear in the instruction, dubbed 𝜇DataState. (2) The Boolean annotation indicating whether each instruction in the code is executed in a given 𝜇State, dubbed 𝜇ControlState… Section 3.2 elaborates on how these two parts of 𝜇State are used to train StateFormer.”); and
processing the query input using the trained generative machine learning model to generate predicted trace data (“reconstruct the complete 𝜇State trace”) providing a more detailed representation of the sequence of events than is indicated by the input trace data (Pei, see page [691] col 2 paragraph 2), (Pei, see page [693], col 1 paragraph 3, “…While in GSM, the unmasked states alone provide little observable patterns due to high masking rate ś the model has to also look at the corresponding instructions, understand their execution effects on the unmasked states, in order to correctly predict the masked states.”), (Pei, see page [692] section 2.3 paragraph 2), (Pei, see page [699] section 5.5 paragraph 2, “…We observe that the validation MSE drops to 0.00011, which translates to average absolute distance (by taking the square root) between prediction and groundtruth as 0.011 (√0.00011 = 0.011)…”), (see Pei, page 694 col 1 paragraph 2).
Pei does not appear to distinctly disclose:
However, Cui discloses:
obtaining input trace data indicative of a sequence of events occurring during execution of a target program on a processor (Cui see col 8 lines 13-21, “The system also obtains control flow information for a set of processor instructions that executed during the prior execution of the application (act 310). This control flow information may be obtained from a thin/sparse hardware trace, for example, such as an Intel® PT (processor trace), or any other processor trace that omits values for a plurality of different memory locations and which may also omit timestamps for each processor instruction in the set of identified preceding processor instructions…”); and
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 a method of using a trained generative model to reconstruct a complete execution state trace from a partial trace as taught by Pei to include obtaining input trace data indicative of a sequence of events occurring during execution of a target program on a processor as taught by Cui for the result of allowing developers to more accurately locate and fix potential bugs.
Regarding claim 2, Pei discloses:
in which the input trace data is indicative of a sampled subset of events occurring during execution of the target program on the processor (Pei, see page [695] col 1 paragraph 2, “We sample a random subset of 𝜇DataState and replace them with (e.g., the grayed-out tokens as shown in Figure 3) tokens in the model input so that the model is trained to reconstruct the removed 𝜇DataState…”), (Pei, see page [694] section 3.1 paragraph 1, “To train StateFormer with GSM, we need to obtain runtime execution traces of binary programs…”), and
the trained generative machine learning model predicts missing events that occurred during execution of the target program but were omitted from the input trace data due to sampling (see Pei, page 694 col 1 paragraph 2, “We collect 𝜇State traces and mask a random subset of them to train the model to reconstruct the complete 𝜇State trace…”), (Pei, see page [693], col 1 paragraph 3, “…While in GSM, the unmasked states alone provide little observable patterns due to high masking rate ś the model has to also look at the corresponding instructions, understand their execution effects on the unmasked states, in order to correctly predict the masked states.”).
Regarding claim 3, Pei does not appear to distinctly disclose:
in which the input trace data comprises instruction trace data providing program flow information indicative of which instructions were executed during execution of the target program on the processor.
However, Cui discloses:
in which the input trace data comprises instruction trace data providing program flow information indicative of which instructions were executed during execution of the target program on the processor (Cui see col 8 lines 13-15, “The system also obtains control flow information for a set of processor instructions that executed during the prior execution of the application (act 310)...”), (Cui, see col 9 lines 54-59, “…The control flow 420 also identifies the types of processor instructions that are executed, even though the actual state values of those instructions (e.g., memory locations and values in those locations) are not recorded or included in the control flow 420 or recorded state 415 for each instruction.”).
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 a method of using a trained generative model to reconstruct a complete execution state trace from a partial trace as taught by Pei to include the input trace data comprises instruction trace data providing program flow information indicative of which instructions were executed during execution of the target program on the processor as taught by Cui for the result of applying the model to only the path indicated by program flow information.
Regarding claim 4, Pei does not appear to distinctly disclose:
in which the input trace data is trace data captured using trace capture hardware configured to monitor operation of the processor during execution of the target program.
However, Cui discloses:
in which the input trace data is trace data captured using trace capture hardware configured to monitor operation of the processor during execution of the target program (Cui see col 8 lines 13-21, “The system also obtains control flow information for a set of processor instructions that executed during the prior execution of the application (act 310). This control flow information may be obtained from a thin/sparse hardware trace, for example, such as an Intel® PT (processor trace), or any other processor trace that omits values for a plurality of different memory locations and which may also omit timestamps for each processor instruction in the set of identified preceding processor instructions…”).
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 a method of using a trained generative model to reconstruct a complete execution state trace from a partial trace as taught by Pei to include the input trace data is trace data captured using trace capture hardware configured to monitor operation of the processor during execution of the target program as taught by Cui for the result of obtaining relevant and meaningful predicted trace data.
Regarding claim 5, Pei discloses:
in which the query input also comprises (Pei, see page [691] col 2 paragraph 2, “We design a novel pretraining task, Generative State Modeling (GSM), where we train a neural network to reconstruct the complete set of its execution states while taking the assembly code and a very small subset of its execution states (e.g., register values at specific program points) as input…”).
Pei does not appear to distinctly disclose:
However, Cui discloses:
(Cui, see col 6 lines 56-60, “…the sparse hardware trace data comprising control flow information for operation blocks of processor instructions that executed during the application's prior execution are obtained, along with sparse timestamp data, which indicates at least one timestamp for each operation block…”), (Cui, see col 14 lines 21-23, “…The hardware timestamps 800 associated with the different Code Blocks (A-G) may also be obtained from the control flow data (e.g., as obtained from the sparse thread traces)…”).
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 a method of using a trained generative model to reconstruct a complete execution state trace from a partial trace as taught by Pei to include system information captured during execution of the target program on the processor as taught by Cui for the result of obtaining more accurate output from the model.
Regarding claim 7, Pei does not appear to distinctly disclose:
in which the system information comprises synchronisation information for synchronising items of trace data of the input trace data with a point of execution of the target program.
However, Cui discloses:
in which the system information comprises synchronisation information for synchronising items of trace data of the input trace data with a point of execution of the target program (Cui, see col 6 lines 56-60, “…the sparse hardware trace data comprising control flow information for operation blocks of processor instructions that executed during the application's prior execution are obtained, along with sparse timestamp data, which indicates at least one timestamp for each operation block…”), (Cui, see col 13 lines 46-49, “…The ordering of the operation blocks in the single merged sequence is based, in some instances, on the operation timestamp associated with each operation block…”).
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 a method of using a trained generative model to reconstruct a complete execution state trace from a partial trace as taught by Pei to include synchronisation information for synchronising items of trace data of the input trace data with a point of execution of the target program as taught by Cui for the result of allowing the model output to match with the correct moment within execution.
Regarding claim 17, Pei discloses:
in which the predicted trace data is generated through (Pei, see page [692] section 2.3 paragraph 2, “The training task performed in GSM requires a neural network to reconstruct the whole micro-execution traces (i.e., all recorded program states) in the training data based on the corresponding code blocks…”),
(Pei, see page [691] col 2 paragraph 2, “We design a novel pretraining task, Generative State Modeling (GSM), where we train a neural network to reconstruct the complete set of its execution states while taking the assembly code and a very small subset of its execution states (e.g., register values at specific program points) as input…”).
Pei does not appear to distinctly disclose:
where output trace data generated for a given iteration of processing is input as
However, Cui discloses:
(Cui, see col 8 lines 39-44, “Then, using this final recorded state information and the control flow information obtained from the sparse trace, the system identifies the state information for at least some of the preceding processor instructions by performing an iterative backward and forward analysis of the processor instructions (act 315)…”),
where output trace data generated for a given iteration of processing is input (Cui, see col 8 line 66-col 9 line 4, “… once the processor instructions are traversed (in reverse) to identify one, some, or all values possible, the system can then traverse forward through the processor instructions to infer new states that may have been unknown and that can now be resolved with the inferred information…”).
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 a method of using a trained generative model to reconstruct a complete execution state trace from a partial trace as taught by Pei to include trace data generated through multiple iterations of processing and where output trace data generated for a given iteration of processing is input for a further iteration of processing as taught by Cui for the result of obtaining more complete trace data.
Regarding claim 18, Pei discloses: A method for training a generative machine learning model for trace generation (Pei, see page [691] col 2 paragraph 2, “We design a novel pretraining task, Generative State Modeling (GSM), where we train a neural network to reconstruct the complete set of its execution states while taking the assembly code and a very small subset of its execution states (e.g., register values at specific program points) as input…”), the method comprising:
providing a generative machine learning model defined by model parameters representing a transformation function for transforming a query input into predicted trace data (Pei, see page [691] col 2 paragraph 2),
where the query input is based on input trace data indicative of a sequence of events occurring during execution of a target program (Pei, see page 694 section 3.2 paragraph 1, “We construct 5 sequences for StateFormer input, namely (1) static assembly code sequence, (2) 𝜇DataState sequence, (3) instruction position sequence, (4) opcode/operand position sequence, and (5) architecture sequence…”), and
providing a training set of trace data sequences, each trace data sequence indicative of a sequence of events occurring during actual or simulated execution of a target program on a processor (Pei, see page [693] section 3.1 paragraph 1, “To train StateFormer with GSM, we need to obtain runtime execution traces of binary programs…”), (Pei, see page [696] section 4 paragraph 2, “To log the program states (𝜇State) for pretraining StateFormer on GSM task, we implement micro-execution using Unicorn [76], a cross-architecture CPU emulator based on QEMU[11]…”); and
applying a training function to train the generative machine learning model using the training set of trace data sequences, to generate updated values for the model parameters (Pei, see page [695] col 2 paragraph 1, “The first part of the objective function aims to minimize the Mean Squared Error (MSE) between the predicted 8-byte and the groundtruth 8-byte for the only masked 𝜇DataState… As all the modules of StateFormer are differentiable, i.e., NAU, FFN used for aggregating input sequences, self-attention layers, and ℎ𝑣 and ℎ𝑖, optimizing Equation 1 can be efficiently solved by gradient descent.”).
Pei does not appear to distinctly disclose:
the predicted trace data provides a more detailed representation of the sequence of events than is indicated by the input trace data;
However, Cui discloses:
(Cui see col 8 lines 13-15, “The system also obtains control flow information for a set of processor instructions that executed during the prior execution of the application (act 310)...”), and
the predicted trace data provides a more detailed representation of the sequence of events than is indicated by the input trace data (Cui, see col 9 lines 54-59, “…The control flow 420 also identifies the types of processor instructions that are executed, even though the actual state values of those instructions (e.g., memory locations and values in those locations) are not recorded or included in the control flow 420 or recorded state 415 for each instruction.”), (Cui, see col 8 lines 39-44, “Then, using this final recorded state information and the control flow information obtained from the sparse trace, the system identifies the state information for at least some of the preceding processor instructions by performing an iterative backward and forward analysis of the processor instructions (act 315)…”);
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 a method of using a trained generative model to reconstruct a complete execution state trace from a partial trace as taught by Pei to include input trace data indicative of a sequence of events occurring during execution of a target program on a processor and the predicted trace data provides a more detailed representation of the sequence of events than is indicated by the input trace data as taught by Cui for the result of training the model to rebuild full traces.
Regarding claim 19, Pei discloses:
generating, for each trace data sequence of the training set, one or more degraded trace data sequences representing the sequence of events in less detail than that trace data sequence (Pei, see page [692] section 2.3 paragraph 2, “…for each training sample in each epoch, we randomly mask some states in the traces.”);
wherein the training function comprises, for a given degraded trace data sequence: applying the transformation function to the given degraded trace data sequence, to generate a given predicted trace data sequence (Pei, see page [695] col 1 paragraph 2, “We sample a random subset of 𝜇DataState and replace them with (e.g., the grayed-out tokens as shown in Figure 3) tokens in the model input so that the model is trained to reconstruct the removed 𝜇DataState…”); and
adjusting the model parameters based on a comparison of the given predicted trace data sequence with a corresponding trace data sequence of the training set from which the given degraded trace data sequence was derived (Pei, see page [695], col 2 paragraph 1, “The first part of the objective function aims to minimize the Mean Squared Error (MSE) between the predicted 8-byte and the groundtruth 8-byte for the only masked 𝜇DataState… As all the modules of StateFormer are differentiable, i.e., NAU, FFN used for aggregating input sequences, self-attention layers, and ℎ𝑣 and ℎ𝑖, optimizing Equation 1 can be efficiently solved by gradient descent.”).
Regarding claim 20, Pei does not appear to distinctly disclose: A program comprising instructions which, when executed on a data processing apparatus, cause the data processing apparatus to perform the method according to claim 1.
However, Cui discloses: A program comprising instructions which, when executed on a data processing apparatus, cause the data processing apparatus to perform the method according to claim 1 (Cui, see col 17 lines 61-63, “Storage 1210 is shown as including executable code/instructions 1115 and trace data 1120, which is representative of the trace data discussed earlier…”), (Cui, see col 17 lines 57-60, “…FIG. 11 shows that computer system 1100 includes at least one processor 1105 (aka a “hardware processing unit”) and storage 1110.” ).
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 a method of using a trained generative model to reconstruct a complete execution state trace from a partial trace as taught by Pei to include a program comprising instructions which, when executed on a data processing apparatus, cause the data processing apparatus to perform the method according to claim 1 as taught by Cui for the result of allowing the software to be stored and executed on any computer.
Regarding claim 21, Pei discloses: An apparatus (Pei, see page [696] section 4 paragraph 1, “…All the experiments are run on a Linux server with Ubuntu 18.04, Intel Xeon 4214 at 2.20GHz with 48 virtual cores, 188GB RAM, and 4 Nvidia RTX 2080-Ti GPUs…”) comprising:
(Pei, see page [696] section 4 paragraph 2, “To log the program states (𝜇State) for pretraining StateFormer on GSM task, we implement micro-execution using Unicorn [76], a cross-architecture CPU emulator based on QEMU[11]…”); and
processing circuitry to provide a query input to a trained generative machine learning model, where the query input is based on the input trace data (Pei, see page [696] section 4 paragraph 1, “…All the experiments are run on a Linux server with Ubuntu 18.04, Intel Xeon 4214 at 2.20GHz with 48 virtual cores, 188GB RAM, and 4 Nvidia RTX 2080-Ti GPUs…”), (Pei, see page [691] col 2 paragraph 2, “We design a novel pretraining task, Generative State Modeling (GSM), where we train a neural network to reconstruct the complete set of its execution states while taking the assembly code and a very small subset of its execution states (e.g., register values at specific program points) as input…”), and
process the query input using the trained generative machine learning model to generate predicted trace data providing a more detailed representation of the sequence of events than is indicated by the input trace data (Pei, see page [691] col 2 paragraph 2), (Pei, see page [693], col 1 paragraph 3, “…While in GSM, the unmasked states alone provide little observable patterns due to high masking rate ś the model has to also look at the corresponding instructions, understand their execution effects on the unmasked states, in order to correctly predict the masked states.”), (Pei, see page [692] section 2.3 paragraph 2, “The training task performed in GSM requires a neural network to reconstruct the whole micro-execution traces (i.e., all recorded program states) in the training data based on the corresponding code blocks…”). (Pei, see page [699] section 5.5 paragraph 2, “…We observe that the validation MSE drops to 0.00011, which translates to average absolute distance (by taking the square root) between prediction and groundtruth as 0.011 (√0.00011 = 0.011)…”).
Pei does not appear to distinctly disclose:
input circuitry
However, Cui discloses:
input circuitry to obtain input trace data indicative of a sequence of events occurring during execution of a target program on a processor (Cui, see col 18 lines 49-51, “…Computer system 1100 will include one or more communication channels that are used to communicate with the network 1125…”), (Cui see col 8 lines 13-15, “The system also obtains control flow information for a set of processor instructions that executed during the prior execution of the application (act 310)...”).
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 a method of using a trained generative model to reconstruct a complete execution state trace from a partial trace as taught by Pei to include input circuitry to obtain input trace data indicative of a sequence of events occurring during execution of a target program on a processor as taught by Cui for the result of obtaining relevant and meaningful predicted trace data.
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Pei and Cui as applied to claim 5 above, and further in view of Huang et al. (US20200293653, Huang hereinafter).
Regarding claim 6, Pei discloses:
in which the query input comprises a sequence of vectors, each vector comprising an item of trace data from the input trace data (Pei, see page [691] col 2 paragraph 2, “We design a novel pretraining task, Generative State Modeling (GSM), where we train a neural network to reconstruct the complete set of its execution states while taking the assembly code and a very small subset of its execution states (e.g., register values at specific program points) as input…”), (Pei, see page [694] section 3.2 paragraph 1, “We construct 5 sequences for StateFormer input, namely (1) static assembly code sequence, (2) 𝜇DataState sequence, (3) instruction position sequence, (4) opcode/operand position sequence, and (5) architecture sequence. Each token of the 5 sequences are aligned and embedded into an embedding (a low-dimensional vector) with the same dimensions, such that they can be easily aggregated as a single sequence of 𝑛 embeddings”).
Pei does not appear to distinctly disclose:
at least one system information field for associating at least one item of system information with that item of trace data.
However, Huang discloses:
at least one system information field for associating at least one item of system information with that item of trace data (Huang, see paragraph [0068], “…the concatenated vector 250 comprises the system call name embedding values followed by the first argument's embedding values, and then the second argument's embedding values, and so on… The resulting vector representations 250-254 are then input to the RNN for processing.”), (Huang, see paragraph [0025], “…a variant of LSTM or GRU cells incorporating timestamp of system calls can be used. In particular, a temporal control layer is provided in the LSTM or GRU cell to update some of the values of the state variable based on the elapsed time from the previous system call event…”).
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 a method of using a trained generative model to reconstruct a complete execution state trace from a partial trace as taught by Pei to include at least one system information field for associating at least one item of system information with that item of trace data as taught by Huang for the result of allowing the model to learn from both the system information and trace data.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Pei and Cui as applied to claim 5 above, and further in view of Gottschlich et al. (US20190319977, Gottschlich hereinafter).
Regarding claim 8, Pei does not appear to distinctly disclose:
in which the system information comprises at least one of: performance monitoring information captured by one or more performance monitoring counters of the processor during execution of the target program on the processor, and profiling information indicative of system behaviour associated with execution of a sampled instruction selected for profiling.
However, Gottschlich discloses:
in which the system information comprises at least one of: performance monitoring information captured by one or more performance monitoring counters of the processor during execution of the target program on the processor, (Gottschlich, see paragraph [0031], “…the telemetry collector 130 can request CPU telemetry events including a processor trace and/or other source of CPU control flow information, one or more performance monitor unit (PMU) counters, etc., gathered over a time interval…”), (Gottschlich, see paragraph [0030], “…The telemetry collector 130 begins to collect the telemetry events when a process of a monitored application begins execution and provides them for processing by the trace processor 140 after the process has terminated.”), (Gottschlich, see paragraph [0041], “…the fingerprint extractor 150 extracts or forms a process fingerprint from the processed trace information from the trace processor 140 and other process event information such as PMU counter(s)…”).
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 a method of using a trained generative model to reconstruct a complete execution state trace from a partial trace as taught by Pei to include performance monitoring information captured by one or more performance monitoring counters of the processor during execution of the target program on the processor as taught by Gottschlich for the result of obtaining predicted trace data that most accurately matches the actual trace data.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Pei and Cui as applied to claim 5 above, and further in view of Chen et al. (US20190042745, Chen hereinafter).
Regarding claim 9, Pei does not appear to distinctly disclose:
in which the system information comprises at least one of: branch statistic information providing a statistical measure of behaviour of branch instructions of the target program, and branch target address information indicative of target addresses of branches taken during execution of the target program.
However, Chen discloses:
in which the system information comprises at least one of: (Chen, see paragraph [0053], “A TIP packet represents the control flow transfer at an indirect branch to the target address contained in the payload of the TIP packet…”).
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 a method of using a trained generative model to reconstruct a complete execution state trace from a partial trace as taught by Pei to include a branch target address information indicative of target addresses of branches taken during execution of the target program as taught by Chen for the result of obtaining a complete sequence of branches that were taken.
Claims 10, 13, and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Pei and Cui as applied to claim 1 above, and further in view of Levine et al. (US5878208, Levine hereinafter).
Regarding claim 10, Pei discloses:
(Pei, see page [691] col 2 paragraph 2, “We design a novel pretraining task, Generative State Modeling (GSM), where we train a neural network to reconstruct the complete set of its execution states while taking the assembly code and a very small subset of its execution states (e.g., register values at specific program points) as input…”); and
(Pei, see page [691] col 2 paragraph 2).
Pei does not appear to distinctly disclose:
validating whether
in response to determining that
However, Levine discloses:
validating whether the (Levine, see col 9 lines 7-21, “…Trace reconstruction software can be utilized which can detect an anomalous path and redo the trace reconstruction utilizing an alternate path in response to such detection. Having available the three output pins of the performance monitor which indicate the occurrence of the execution of each group of instructions, load instructions and store instructions create a situation in which an instruction trace reconstruction can be created by either looking ahead through the proposed instruction trace to correlate that instruction trace with the number of instructions, load instructions and store instructions which are executed, or by restarting the entire trace reconstruction in a so-called "backup and restart" approach to choose a different path at those locations which are suspect within an originally derived trace.”); and
in response to determining that one or more items of (Levine, see col 9 lines 7-21).
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 a method of using a trained generative model to reconstruct a complete execution state trace from a partial trace as taught by Pei to include validating whether the trace data meets at least one validation criterion for checking whether the trace data is realistic, and in response to determining that one or more items of trace data generated each fail the at least one validation criterion, re-processing to generate one or more new instances of the predicted trace data as taught by Levine for the result of obtaining relevant and meaningful predicted trace data.
Regarding claim 13, Pei discloses:
(Pei, see page [691] col 2 paragraph 2, “We design a novel pretraining task, Generative State Modeling (GSM), where we train a neural network to reconstruct the complete set of its execution states while taking the assembly code and a very small subset of its execution states (e.g., register values at specific program points) as input…”).
Pei does not appear to distinctly disclose:
in which the at least one validation criterion includes a performance monitoring counter criterion to determine, based on at least one performance monitoring count value indicative of frequency of a given event during execution of
However, Levine discloses:
in which the at least one validation criterion includes a performance monitoring counter criterion to determine, based on at least one performance monitoring count value indicative of frequency of a given event during execution (Levine, see col 9 lines 7-21, “…Trace reconstruction software can be utilized which can detect an anomalous path and redo the trace reconstruction utilizing an alternate path in response to such detection. Having available the three output pins of the performance monitor which indicate the occurrence of the execution of each group of instructions, load instructions and store instructions create a situation in which an instruction trace reconstruction can be created by either looking ahead through the proposed instruction trace to correlate that instruction trace with the number of instructions, load instructions and store instructions which are executed, or by restarting the entire trace reconstruction in a so-called "backup and restart" approach to choose a different path at those locations which are suspect within an originally derived trace.”), (Levine, see col 8 lines 13-16, “…Block 94 depicts a determination of whether or not "N" instructions have been executed. If so, the process passes to block 96 and a single bit signal is output from the performance monitor…”).
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 a method of using a trained generative model to reconstruct a complete execution state trace from a partial trace as taught by Pei to include at least one validation criterion includes a performance monitoring counter criterion to determine, based on at least one performance monitoring count value indicative of frequency of a given event during execution, whether the sequence of events indicated by the trace data is consistent with the at least one performance monitoring count value as taught by Levine for the result of obtaining relevant and meaningful predicted trace data.
Regarding claim 14, Pei discloses:
(Pei, see page [691] col 2 paragraph 2, “We design a novel pretraining task, Generative State Modeling (GSM), where we train a neural network to reconstruct the complete set of its execution states while taking the assembly code and a very small subset of its execution states (e.g., register values at specific program points) as input…”).
Pei does not appear to distinctly disclose:
in which the at least one validation criterion includes an instruction composition criterion to determine, based on instruction composition information indicative of relative frequency of one or more types of instruction among the instructions executed for
However, Levine discloses:
in which the at least one validation criterion includes an instruction composition criterion to determine, based on instruction composition information indicative of relative frequency of one or more types of instruction among the instructions executed (Levine, see col 9 lines 7-21, “…Trace reconstruction software can be utilized which can detect an anomalous path and redo the trace reconstruction utilizing an alternate path in response to such detection. Having available the three output pins of the performance monitor which indicate the occurrence of the execution of each group of instructions, load instructions and store instructions create a situation in which an instruction trace reconstruction can be created by either looking ahead through the proposed instruction trace to correlate that instruction trace with the number of instructions, load instructions and store instructions which are executed, or by restarting the entire trace reconstruction in a so-called "backup and restart" approach to choose a different path at those locations which are suspect within an originally derived trace.”), (Levine, see col 8 lines 47-53, “While the present description utilizes a count of load instructions and store instructions, those having skill in the art, upon reference to the foregoing, will appreciate that a count of the total instructions executed, along with a count of the number of executions of any specific type of instruction, can be utilized to reconstruct an instruction trace in the manner described herein.”).
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 a method of using a trained generative model to reconstruct a complete execution state trace from a partial trace as taught by Pei to include at least one validation criterion includes an instruction composition criterion to determine, based on instruction composition information indicative of relative frequency of one or more types of instruction among the instructions executed, whether the sequence of events indicated by the trace data is consistent with the instruction composition information as taught by Levine for the result of obtaining relevant and meaningful predicted trace data.
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Pei, Cui, and Levine as applied to claim 10 above, and further in view of Mola et al. (US20190012255, Mola hereinafter).
Regarding claim 11, Pei discloses:
(Pei, see page [691] col 2 paragraph 2, “We design a novel pretraining task, Generative State Modeling (GSM), where we train a neural network to reconstruct the complete set of its execution states while taking the assembly code and a very small subset of its execution states (e.g., register values at specific program points) as input…”).
Pei does not appear to distinctly disclose:
in which the at least one validation criterion includes an input preservation criterion to determine, based on a comparison of
However, Mola discloses:
in which the at least one validation criterion includes an input preservation criterion to determine, based on a comparison of the input trace data and the (Mola, see paragraph [0091], “…To identify mismatches the identification component 401 could identify when cache misses do not happen on the same instruction, or when memory reads/writes have different values or are to different addresses… the identification component 401 could compare the data stored in key frames of the original trace data steam 301a with the values generated during replay, and identify any discrepancies… if the same code instructions, when given the same inputs, execute differently during replay than they did during recording, there is a clear sign that the code has relied on processor undefined behavior.”), (Mola, see paragraph [0101], “…if the trace file 300 includes key fame(s) that occur concurrent with a fork, the undefined behavior handler 400 can compare the values in one or more key frames (e.g., register values) with the values generated during replay in each branch at a corresponding time to determine if there is an exact match.…”).
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 a method of using a trained generative model to reconstruct a complete execution state trace from a partial trace as taught by Pei to include at least one validation criterion includes an input preservation criterion to determine, based on a comparison of the input trace data and the trace data, whether the input trace data has been preserved within the trace data as taught by Mola for the result of obtaining relevant and meaningful predicted trace data.
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Pei, Cui, and Levine as applied to claim 10 above, and further in view of Sultana et al. (US20180095764, Sultana hereinafter).
Regarding claim 12, Pei discloses:
(Pei, see page [691] col 2 paragraph 2, “We design a novel pretraining task, Generative State Modeling (GSM), where we train a neural network to reconstruct the complete set of its execution states while taking the assembly code and a very small subset of its execution states (e.g., register values at specific program points) as input…”).
Pei does not appear to distinctly disclose:
in which the at least one validation criterion includes a source code criterion to determine, based on source code of
However, Sultana discloses:
in which the at least one validation criterion includes a source code criterion to determine, based on source code of the target program, whether the sequence of events(Sultana, see paragraph [0018], “…The control flow validator circuitry may be further configured to determine whether a legitimate execution path exists in the CFG between the first static target address and the second static target address if the CFG includes the first static target address and the second static target address or to signal a control flow violation if the CFG does not include the first static target address or the second static target address.”), (Sultana, see paragraph [0009], “A control flow graph (CFG) is a representation, using graph notation, of control flow, i.e., execution, paths that may be traversed through an application during execution of the application… A control flow graph may be generated by, for example, source code analysis, binary analysis, static binary analysis, execution profiling…”).
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 a method of using a trained generative model to reconstruct a complete execution state trace from a partial trace as taught by Pei to include at least one validation criterion includes a source code criterion to determine, based on source code of the target program, whether the sequence of events is consistent with a realistic program flow path that could be taken when executing the target program defined by source code as taught by Sultana for the result of obtaining relevant and meaningful predicted trace data.
Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over Pei, Cui, and Levine as applied to claim 10 above, and further in view of Price (US20210191841).
Regarding claim 15, Pei discloses:
(Pei, see page [691] col 2 paragraph 2, “We design a novel pretraining task, Generative State Modeling (GSM), where we train a neural network to reconstruct the complete set of its execution states while taking the assembly code and a very small subset of its execution states (e.g., register values at specific program points) as input…”).
Pei does not appear to distinctly disclose:
in which the at least one validation criterion includes a branch target criterion to determine, based on branch target information indicative of target addresses of taken branch instructions executed for
However, Price discloses:
in which the at least one validation criterion includes a branch target criterion to determine, based on branch target information indicative of target addresses of taken branch instructions executed for the target program, whether the sequence of events indicated by the(Price, see paragraph [0058], “At step 506, the trace collector receives a request to add a first trace entry to the replay execution trace log…”), (Price, see paragraph [0059], “At step 512, the trace collector detects whether the live execution trace log contains a second trace entry that matches the first trace entry…”), (Price, see paragraph [0020], “…for each of the identified branches, the live execution trace log 128 may indicate whether the branch was taken, and the target address to which the live execution of the computer program 124 was redirected as a result of the branch…”).
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 a method of using a trained generative model to reconstruct a complete execution state trace from a partial trace as taught by Pei to include at least one validation criterion includes a branch target criterion to determine, based on branch target information indicative of target addresses of taken branch instructions executed for the target program, whether the sequence of events indicated by the trace data is consistent with the branch target information as taught by Price for the result of obtaining relevant and meaningful predicted trace data.
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Pei, Cui, and Levine as applied to claim 10 above, and further in view of Conti et al. (US20060004964, Conti hereinafter).
Regarding claim 16, Pei discloses:
(Pei, see page [691] col 2 paragraph 2, “We design a novel pretraining task, Generative State Modeling (GSM), where we train a neural network to reconstruct the complete set of its execution states while taking the assembly code and a very small subset of its execution states (e.g., register values at specific program points) as input…”).
Pei does not appear to distinctly disclose:
in which the at least one validation criterion includes an operating state criterion to determine, based on context information indicative of a current operating state associated with a portion of
However, Conti discloses:
in which the at least one validation criterion includes an operating state criterion to determine, based on context information indicative of a current operating state associated with a portion of the input trace data, whether a corresponding portion of the (Conti, paragraph [0034], “… For the exemplary ARM1136, the security state machine 56 verifies which instruction was executed by verifying the instruction's address on ETM port 68 signals ETMIA[31:0] and ensures the processor was in the preferred 32 bit ARM instruction set mode during the executing by monitoring the ETMIACTL[4:4] (asserted when Java enabled) and ETMIACTL[3:3] (asserted when Thumb enabled) signals.”), (Conti, see paragraph [0033], “…an ETM port comprises an address bus 70 providing the address of the last executed instruction, as well as an interface bus 71 providing information as to the state of the processor during the last executed instruction…”).
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 a method of using a trained generative model to reconstruct a complete execution state trace from a partial trace as taught by Pei to include at least one validation criterion includes an operating state criterion to determine, based on context information indicative of a current operating state associated with a portion of the input trace data, whether a corresponding portion of the trace data indicates events that would not be allowed in the current operating state as taught by Conti for the result of obtaining relevant and meaningful predicted trace data.
Conclusion
Any inquiry concerning this communication or earlier communications from the
examiner should be directed to Joshua Tran whose telephone number is (571)272-5460.
The examiner can normally be reached on M-F 9-5.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s
supervisor, Hyung Sough can be reached on (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 an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/JOSHUA TRAN/
Examiner, Art Unit 2192
/S. Sough/SPE, Art Unit 2192
Prosecution Insights