DETAILED ACTION
This Action is a response to the RCE filed 3 August 2026 in view of the reply filed 3 April 2026. Claims 1, 7-10, 12-16 and 20 are amended; claims 6 and 19 are canceled; claims 21-22 are newly added. Claims 1-5, 7-18 and 20-22 remain pending for examination.
Examiner notes that the most recently presented claims have been fully reconsidered in view of the complete record in view of the Information Disclosure Statement filed 3 August 2026 and all references cited therein (or cited in the Notification of First Office Action dated 16 July 2026 and filed 3 August 2026).
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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after allowance or after an Office action under Ex Parte Quayle, 25 USPQ 74, 453 O.G. 213 (Comm'r Pat. 1935). Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, prosecution in this application has been reopened pursuant to 37 CFR 1.114. Applicant's submission filed on 3 August 2026 has been entered.
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 3 August 2026 is being considered by the examiner.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. § 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-3, 7-10, 12, 14, 16-17 and 20-22 are rejected under 35 U.S.C. § 103 as being unpatentable over Krajec, Russell S., U.S. 2014/0019985 A1 (“Krajec”) in view of Costa et al., U.S. 2009/0132861 A1 (“Costa”).
Regarding claim 1, Krajec teaches: A method, implemented at a computer system that includes a processor (Krajec, e.g., FIG. 2 and ¶¶89-91, describing a device such as a server computer system including a hardware platform comprising at least a processor), for removing payload data from an execution trace (Krajec, e.g., ¶5, “A tracer may obfuscate trace data …”), the method comprising:
identifying a payload data item within an execution trace; identifying particular executable code that interacted with the payload data item (Krajec, e.g., ¶99, “raw trace data 226 may include data elements processed by the applications 254, as well as references to application elements such as function names and other descriptors”);
determining, based on the payload data item and the particular executable code, one or more constraints that execution of the particular executable code that interacted with the payload data item has placed on the payload data item …; and replacing a value of the payload data item in the execution trace with information maintaining the one or more constraints while omitting the payload data item (Krajec, e.g., ¶75, “obfuscator 108 may create obfuscated trace data 110 using several different mechanisms …” See also, e.g., ¶77, “Another example of a non-lossy system may be the use of a non-reversible secure hash …” Examiner’s note: see dependent claims 6 and 10, wherein one example of the constraints comprises data structured to preserve code flow, which further comprises a replacement value for the payload data item, and the replacement value is generated based on a hash of the payload data item).
Krajec does not more particularly teach that the one or more constraints reflect how the particular executable code operated on the payload data item during recording of the execution trace, and replacing a payload data value with information maintaining the one or more constraints, causing code flow during replay of the execution trace to be preserved. However, Costa does teach: [determining one or more constraints], the one or more constraints reflecting how the particular executable code operated on the payload data item during recording of the execution trace (Costa, e.g., ¶26, “techniques may be used to log inputs and to detect errors …” See also, e.g., ¶27, “execution trace may be generated … comprises the sequence of x86 instructions executed by each thread and the concrete values of source and destination operands for each instruction …” See also, e.g., ¶29, “path conditions may be computed (in block 103) using forward symbolic execution on the trace …” and ¶38, “Whenever the symbolic execution encounters a branch that depends on the input (i.e. the branch instruction tests a flag with a symbolic value), it adds a path condition to ensure that inputs that satisfy the path condition follow the same execution path (i.e. the execution path in the trace) …”);
[replacing payload data in the trace with the constraints], causing code flow of the particular executable code during a replay of the execution trace is preserved relative to code flow during the recording of the execution trace (Costa, e.g., ¶48, “Having generate path conditions, these may be included within an error report (block 104) … Alternatively … the path conditions may be used to generate a new input which can be included within the error report in addition to or instead of the path conditions … It may be useful in some circumstances to include the new input and the path conditions in the error report, for example so that the input can be used immediately to reproduce the error …” Examiner’s note: the error report in these embodiments includes the trace, the path conditions (constraints) and at least one new input value that replaces an original input value for at least one path condition) for the purpose of performing testing and retesting of particular applications based on trace data including path conditions in order to generate and replace certain data values (Costa, e.g., ¶¶49-56).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system and method for tracing and debugging including trace data obfuscation and replacement as taught by Krajec to provide that the one or more constraints reflect how the particular executable code operated on the payload data item during recording of the execution trace, and replacing a payload data value with information maintaining the one or more constraints, causing code flow during replay of the execution trace to be preserved because the disclosure of Costa shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for logging and providing error reports to provide that the one or more constraints reflect how the particular executable code operated on the payload data item during recording of the execution trace, and replacing a payload data value with information maintaining the one or more constraints, causing code flow during replay of the execution trace to be preserved for the purpose of performing testing and retesting of particular applications based on trace data including path conditions in order to generate and replace certain data values (Costa, Id.).
Claims 16 and 20 are rejected for the reasons given in the rejection of claim 1 above. Examiner notes that with respect to claim 16, Krajec further teaches: A computer system for removing payload data from an execution trace (Krajec, e.g., ¶5, “A tracer may obfuscate trace data …”), comprising: a processor; and a computer-readable storage medium that stores computer-executable instructions that are executable by the processor (Krajec, e.g., FIG. 2 and ¶¶89-92, disclosing a device such as a server computer that includes a hardware platform comprising at least a processor and memory that contains executable code) to at least: [[[perform the method of claim 1]]]; and with respect to claim 20, Krajec further teaches: A computer-readable hardware storage device that stores computer-executable instructions that are executable by a processor system (Krajec, e.g., FIG. 2 and ¶¶89-92, disclosing a device such as a server computer that includes a hardware platform comprising at least a processor and memory that contains executable code) to at least: [[[perform the method of claim 1]]].
Regarding claim 2, the rejection of claim 1 is incorporated, and Krajec further teaches: wherein the one or more constraints comprise one or more bytes of the particular executable code (Krajec, e.g., ¶¶81-84, “Some trace data may be stored in cleartext … store function names in cleartext yet may obfuscate data passed to and from a function … Context descriptors of application elements may be extracted from a source code description of the application. Some embodiments may include a source code analyzer that extracts the descriptors … of application elements, such as functions, variables, data elements … parameter names, tags, control flow diagrams …” Examiner’s note: at least payload data is replaced while maintaining the information indicative of the byte(s) of code that operated on the payload data, i.e., a function call).
Claim 17 is rejected for the additional reasons given in the rejection of claim 2 above.
Regarding claim 3, the rejection of claim 2 is incorporated, and Krajec further teaches: wherein the information maintaining the one or more constraints includes the one or more bytes of the particular executable code (Krajec, e.g., ¶¶81-84, “Some trace data may be stored in cleartext … store function names in cleartext yet may obfuscate data passed to and from a function … Context descriptors of application elements may be extracted from a source code description of the application. Some embodiments may include a source code analyzer that extracts the descriptors … of application elements, such as functions, variables, data elements … parameter names, tags, control flow diagrams …” Examiner’s note: at least payload data is replaced while maintaining the information indicative of the byte(s) of code that operated on the payload data, i.e., a function call)).
Regarding claim 7, the rejection of claim 1 is incorporated, but Krajec does not more particularly teach that the data structured to preserve code flow comprises a replacement value for the payload data item that is identified based on execution of a constraint solver on at least the particular executable code. However, Costa does teach: wherein the information maintaining the one or more constraints comprises a replacement value for the payload data item, and the method further comprises identifying the replacement value based on execution of a constraint solver on at least the particular executable code (Costa, e.g., ¶49, “when an error is detected … a trace is collected … trace is then used to generate path conditions (block 103), which in turn are used to generate a new input …” See also, e.g., ¶50, “generation of a new input (block 201) uses a … solver … other solvers may be used such as constraint solvers …”) for the purpose of performing testing and retesting of particular applications based on trace data including path conditions in order to generate and replace certain data values (Costa, e.g., ¶¶49-56).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system and method for tracing and debugging including trace data obfuscation and replacement as taught by Krajec to provide that the data structured to preserve code flow comprises a replacement value for the payload data item that is identified based on execution of a constraint solver on at least the particular executable code because the disclosure of Costa shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for logging and providing error reports to provide that the data structured to preserve code flow comprises a replacement value for the payload data item that is identified based on execution of a constraint solver on at least the particular executable code for the purpose of performing testing and retesting of particular applications based on trace data including path conditions in order to generate and replace certain data values (Costa, Id.).
Regarding claim 8, the rejection of claim 1 is incorporated, and Krajec further teaches: wherein the information maintaining the one or more constraints comprises a replacement value for the payload data item, and the method further comprises identifying the replacement value based on random value generation (Krajec, e.g., ¶75, “obfuscator 108 may create obfuscated trace data 110 using several different mechanisms …” and ¶79, “a lookup database 112 may be used to assign a random … value to a raw value … a record for each new raw value may be assigned … and the index may serve as the obfuscated values …”).
Regarding claim 9, the rejection of claim 1 is incorporated, and Krajec further teaches: wherein the information maintaining the one or more constraints comprises a replacement value for the payload data item, and the method further comprises identifying the replacement value based on a lookup from a set of available replacement values (Krajec, e.g., ¶75, “obfuscator 108 may create obfuscated trace data 110 using several different mechanisms …” and ¶79, “a lookup database 112 may be used to assign a random … value to a raw value … a record for each new raw value may be assigned … and the index may serve as the obfuscated values …”).
Regarding claim 10, the rejection of claim 1 is incorporated, and Krajec further teaches: wherein the information maintaining the one or more constraints comprises a replacement value for the payload data item, and the method further comprises generating the replacement value based on computing a hash of the payload data item (Krajec, e.g., ¶75, “obfuscator 108 may create obfuscated trace data 110 using several different mechanisms …” See also, e.g., ¶77, “Another example of a non-lossy system may be the use of a non-reversible secure hash …”).
Regarding claim 12, the rejection of claim 10 is incorporated, and Krajec further teaches: wherein replacing the value of the payload data item in the execution trace with the information maintaining the one or more constraints comprises at least one of, replacing the value of the payload data item with the hash, or tagging the replacement value with the hash (Krajec, e.g., ¶75, “obfuscator 108 may create obfuscated trace data 110 using several different mechanisms …” See also, e.g., ¶77, “Another example of a non-lossy system may be the use of a non-reversible secure hash …”).
Regarding claim 14, the rejection of claim 1 is incorporated, and Krajec further teaches: wherein the information maintaining the one or more constraints an instruction of a code path to follow in the particular executable code (Krajec, e.g., ¶¶81-84, “Some trace data may be stored in cleartext … store function names in cleartext yet may obfuscate data passed to and from a function … Context descriptors of application elements may be extracted from a source code description of the application. Some embodiments may include a source code analyzer that extracts the descriptors … of application elements, such as functions, variables, data elements … parameter names, tags, control flow diagrams …” Examiner’s note: at least payload data is replaced while maintaining the information indicative of the control flow of the code).
Regarding claim 21, the rejection of claim 16 is incorporated, and Krajec further teaches: wherein the information maintaining the one or more constraints comprises a replacement value for the payload data item, and the computer-executable instructions that are executable by the processor to identify the replacement value based on at least one of:
execution of a constraint solver on at least the particular executable code1; random value generation (Krajec, e.g., ¶75, “obfuscator 108 may create obfuscated trace data 110 using several different mechanisms …” and ¶79, “a lookup database 112 may be used to assign a random … value to a raw value … a record for each new raw value may be assigned … and the index may serve as the obfuscated values …”);
a lookup from a set of available replacement values (Krajec, e.g., ¶75, “obfuscator 108 may create obfuscated trace data 110 using several different mechanisms …” and ¶79, “a lookup database 112 may be used to assign a random … value to a raw value … a record for each new raw value may be assigned … and the index may serve as the obfuscated values …”); or
computing a hash of the payload data item (Krajec, e.g., ¶75, “obfuscator 108 may create obfuscated trace data 110 using several different mechanisms …” See also, e.g., ¶77, “Another example of a non-lossy system may be the use of a non-reversible secure hash …”).
Regarding claim 22, the rejection of claim 16 is incorporated, and Krajec further teaches: wherein the information maintaining the one or more constraints comprises at least one of: a specification of a set of one or more valid values for the payload data item2; or an instruction of a code path to follow in the particular executable code (Krajec, e.g., ¶¶81-84, “Some trace data may be stored in cleartext … store function names in cleartext yet may obfuscate data passed to and from a function … Context descriptors of application elements may be extracted from a source code description of the application. Some embodiments may include a source code analyzer that extracts the descriptors … of application elements, such as functions, variables, data elements … parameter names, tags, control flow diagrams …” Examiner’s note: at least payload data is replaced while maintaining the information indicative of the control flow of the code).
Claims 4-5 and 18 are rejected under 35 U.S.C. § 103 as being unpatentable over Krajec in view of Costa, and in further view of Mola, Jordi, U.S. 2018/0113789 A1 (“Mola”).
Regarding claim 4, the rejection of claim 1 is incorporated, but Krajec in view of Costa does not more particularly teach that the one or more constraints comprise a memory address corresponding to the payload data item. However, Mola does teach: wherein the one or more constraints comprise a memory address corresponding to the payload data item (Mola, e.g., ¶195, “based on the value being cached into the reserved cache line, logging the value into a trace data stream …” See also, e.g., ¶200, “as a result of detecting the cache miss, cache a value at the particular location in the system memory and initiate logging of the value at the particular location in the system memory into a log file associated with tracing …” and ¶201, “logging raw cached information, as well as data that has been transformed … obfuscation of information … physical address of a memory page may be obfuscated … when logging TLB entries in a user mode trace”) for the purpose of logging various cache operations in order to debug incidents of cache misses (Mola, e.g., ¶¶190-201).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system and method for tracing and debugging including trace data obfuscation and replacement as taught by Krajec in view of Costa to provide that the one or more constraints comprise a memory address corresponding to the payload data item because the disclosure of Mola shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for tracing code execution to provide that the one or more constraints comprise a memory address corresponding to the payload data item for the purpose of logging various cache operations in order to debug incidents of cache misses (Mola, Id.).
Claim 18 is rejected for the additional reasons given in the rejection of claim 4 above.
Regarding claim 5, the rejection of claim 4 is incorporated, and Mola further teaches: wherein the information maintaining the one or more constraints includes the memory address (Mola, e.g., ¶195, “based on the value being cached into the reserved cache line, logging the value into a trace data stream …” See also, e.g., ¶200, “as a result of detecting the cache miss, cache a value at the particular location in the system memory and initiate logging of the value at the particular location in the system memory into a log file associated with tracing …” and ¶201, “logging raw cached information, as well as data that has been transformed … obfuscation of information … physical address of a memory page may be obfuscated … when logging TLB entries in a user mode trace”).
Claim 11 is rejected under 35 U.S.C. § 103 as being unpatentable over Krajec in view of Costa, and in further view of Ionescu et al., U.S. 2017/0322836 A1 (“Ionescu”).
Regarding claim 11, the rejection of claim 10 is incorporated, but Krajec in view of Costa does not more particularly teach that computing the hash of the payload data item comprises applying a salt to the payload data item. However, Ionescu does teach: wherein computing the hash of the payload data item comprises applying a salt to the payload data item (Ionescu, e.g., ¶26, “A salt is a value that should be randomly generated and combined with a password in some way to produce a hash value …”) for the purpose of securing sensitive data using a variety of cryptographic techniques (Ionescu, e.g., ¶¶17-31).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system and method for tracing and debugging including trace data obfuscation and replacement as taught by Krajec in view of Costa to provide that computing the hash of the payload data item comprises applying a salt to the payload data item because the disclosure of Ionescu shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for cryptographic security of payload data to provide that computing the hash of the payload data item comprises applying a salt to the payload data item for the purpose of securing sensitive data using a variety of cryptographic techniques (Ionescu, Id.).
Claim 13 is rejected under 35 U.S.C. § 103 as being unpatentable over Krajec in view of Costa, and in further view of Blinder et al., U.S. 2021/0042631 A1 (“Blinder”).
Regarding claim 13, the rejection of claim 1 is incorporated, but Krajec in view of Costa does not more particularly teach that the data structured to preserve code flow comprises a specification of a set of valid values for the payload data item. However, Blinder does teach: wherein the information maintaining the one or more constraints comprises a specification of a set of one or more valid values for the payload data item (Blinder, e.g., ¶15, “attack description 104 is received from the user and results in a set of user directives 106 for replacing fields of the event log template 102 with new values …” See also, e.g., ¶16, “user may also specify a set of rules 110 that are used to determine values for each of the variables 108 … constraint rules 112, knowledge base rules 114 … constraint rules 112 may be used to determine an acceptable range for each of the variables … determine a proper relationship between the variables …”) for the purpose of generating a series of event logs including data removed from a particular event log with one or more alternative data values based on sets of rules (Blinder, e.g., ¶¶13-19).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system and method for tracing and debugging including trace data obfuscation and replacement as taught by Krajec in view of Costa to provide that the data structured to preserve code flow comprises a specification of a set of valid values for the payload data item because the disclosure of Blinder shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for event logging and modification to provide that the data structured to preserve code flow comprises a specification of a set of valid values for the payload data item for the purpose of generating a series of event logs including data removed from a particular event log with one or more alternative data values based on sets of rules (Blinder, Id.).
Claim 15 is rejected under 35 U.S.C. § 103 as being unpatentable over Krajec in view of Costa, and in further view of Raviv et al., U.S. 2019/0213355 A1 (“Raviv”).
Regarding claim 15, the rejection of claim 1 is incorporated, but Krajec in view of Costa does not more particularly teach that the method is applied transitively to replace an additional instance of the payload data item or derivative thereof in the execution trace with information maintaining the constraints. However, Raviv does teach: wherein the method is applied transitively to replace an additional instance of the payload data item, or a derivative thereof, in the execution trace with the information maintaining the one or more constraints (Raviv, e.g., ¶316, “the debugger guarantees that it will use the same value for all occurrences of a specific field instance …”) for the purpose of generating consistent replacement values for particular sensitive data items during an execution trace (Raviv, e.g., ¶¶311-316).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system and method for tracing and debugging including trace data obfuscation and replacement as taught by Krajec in view of Costa to provide that the method is applied transitively to replace an additional instance of the payload data item or derivative thereof in the execution trace with information maintaining the constraints because the disclosure of Raviv shows that it was known to those of ordinary skill in the pertinent art to improve a time travel debugger that includes redaction of sensitive information to provide that the method is applied transitively to replace an additional instance of the payload data item or derivative thereof in the execution trace with information maintaining the constraints for the purpose of generating consistent replacement values for particular sensitive data items during an execution trace (Raviv, Id.).
Conclusion
Examiner has identified particular references contained in the prior art of record within the body of this action for the convenience of Applicant. Although the citations made are representative of the teachings in the art and are applied to the specific limitations within the enumerated claims, the teaching of the cited art as a whole is not limited to the cited passages. Other passages and figures may apply. Applicant, in preparing the response, should consider fully the entire reference as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art and/or disclosed by Examiner.
Examiner respectfully requests that, in response to this Office Action, support be shown for language added to any original claims on amendment and any new claims. That is, indicate support for newly added claim language by specifically pointing to page(s) and line number(s) in the specification and/or drawing figure(s). This will assist Examiner in prosecuting the application.
When responding to this Office Action, Applicant is advised to clearly point out the patentable novelty which he or she thinks the claims present, in view of the state of the art disclosed by the references cited or the objections made. He or she must also show how the amendments avoid such references or objections. See 37 C.F.R. 1.111(c).
Examiner interviews are available via telephone and video conferencing using a USPTO-supplied web-based collaboration tool. Applicant is encouraged to submit an Automated Interview Request (AIR) which may be done via https://www.uspto.gov/patent/uspto-automated-interview-request-air-form, or may contact Examiner directly via the methods below.
Any inquiry concerning this communication or earlier communication from Examiner should be directed to Andrew M. Lyons, whose telephone number is (571) 270-3529, and whose fax number is (571) 270-4529. The examiner can normally be reached Monday to Friday from 10:00 AM to 6:00 PM ET. If attempts to reach Examiner by telephone are unsuccessful, Examiner’s supervisor, Wei Mui, can be reached at (571) 272-3708. Information regarding the status of an application may be obtained from the Patent Center system. For more information about the Patent Center system, see https://www.uspto.gov/patents/apply/patent-center. 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.
/Andrew M. Lyons/Primary Examiner, Art Unit 2191
1 See Costa, e.g., ¶49, “when an error is detected … a trace is collected … trace is then used to generate path conditions (block 103), which in turn are used to generate a new input …” See also, e.g., ¶50, “generation of a new input (block 201) uses a … solver … other solvers may be used such as constraint solvers …”
2 See Blinder, e.g., ¶15, “attack description 104 is received from the user and results in a set of user directives 106 for replacing fields of the event log template 102 with new values …” See also, e.g., ¶16, “user may also specify a set of rules 110 that are used to determine values for each of the variables 108 … constraint rules 112, knowledge base rules 114 … constraint rules 112 may be used to determine an acceptable range for each of the variables … determine a proper relationship between the variables …”
