DETAILED ACTION
This Action is a response to the filing received 26 October 2023. Claims 1-15 were presented for examination. A Preliminary Amendment was filed 26 October 2023, in which claims 1-2, 4, 6-10, 12 and 15 were amended, no claims were canceled, and claims 16-20 were added. Claims 1-20 remain pending for examination.
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 .
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 30 November 2023, 14 March 2024, 1 October 2024, 9 January 2025 and 9 May 2025 are being considered by the examiner.
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. Claim 20 recites a computer storage medium that stores computer-executable instructions. The Specification states that “Computer storage media are physical storage media … that store computer-executable instructions … include computer hardware … or any other hardware storage device(s) …” (Spec. ¶28). This is a non-limiting set of examples of computer storage media. A signal is an example of computer storage medium that is a physical storage medium which may store computer-executable instructions. Accordingly, the broadest reasonable interpretation of computer storage medium includes signals per se, and claim 20 is accordingly ineligible. Examiner recommends the claim be amended to recite a non-transitory computer storage medium.
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-3, 6, 8-10, 12, 14, 16-17 and 19-20 are rejected under 35 U.S.C. § 102(a)(1) as being anticipated by Krajec, Russell S., U.S. 2014/0019985 A1 (“Krajec”).
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 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 that execution of the particular executable code that interacted with the payload data has placed on 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).
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 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 storage medium 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 6, the rejection of claim 1 is incorporated, and Krajec further teaches: wherein the one or more constraints comprise data structured to preserve code flow, and wherein the information maintaining the one or more constraints includes the data structured to preserve code flow (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 claim 10, wherein one example of the constraint comprising data structured to preserve code flow comprises a replacement value for the payload data item, and the replacement value is generated based on a hash of the payload data item).
Claim 19 is rejected for the additional reasons given in the rejection of claim 6 above.
Regarding claim 8, the rejection of claim 6 is incorporated, and Krajec further teaches: wherein the data structured to preserve code flow comprises a replacement value for the payload data item, the method further comprising 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 6 is incorporated, and Krajec further teaches: wherein the data structured to preserve code flow comprises a replacement value for the payload data item, the method further comprising 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 6 is incorporated, and Krajec further teaches: wherein the data structured to preserve code flow comprises a replacement value for the payload data item, the method further comprising 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 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 6 is incorporated, and Krajec further teaches: wherein the data structured to preserve code flow comprises 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).
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.
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 4-5 and 18 are rejected under 35 U.S.C. § 103 as being unpatentable over Krajec in view of Mola, Jordi, U.S. 2018/0113789 A1 (“Mola”).
Regarding claim 4, the rejection of claim 1 is incorporated, but Krajec 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 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 7 is rejected under 35 U.S.C. § 103 as being unpatentable over Krajec in view of Costa et al., U.S. 2009/0132861 A1 (“Costa”).
Regarding claim 7, the rejection of claim 6 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 data structured to preserve code flow comprises a replacement value for the payload data item, the method further comprising 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.).
Claim 11 is rejected under 35 U.S.C. § 103 as being unpatentable over Krajec in view of Ionescu et al., U.S. 2017/0322836 A1 (“Ionescu”).
Regarding claim 11, the rejection of claim 10 is incorporated, but Krajec 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 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 Blinder et al., U.S. 2021/0042631 A1 (“Blinder”).
Regarding claim 13, the rejection of claim 6 is incorporated, but Krajec 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 data structured to preserve code flow 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 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 Raviv et al., U.S. 2019/0213355 A1 (“Raviv”).
Regarding claim 15, the rejection of claim 1 is incorporated, but Krajec 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 payload data item, or derivative thereof, in the execution trace with 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 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