DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response to amendments filed on December 15, 2025.
Claims 1-20 are pending.
Claims 1-4, 6-9, 11-14 and 18-19 have been amended.
Response to Amendment
Drawings
Color photographs and color drawings are not accepted in utility applications unless a petition filed under 37 CFR 1.84(a)(2) is granted. Any such petition must be accompanied by the appropriate fee set forth in 37 CFR 1.17(h), one set of color drawings or color photographs, as appropriate, if submitted via the USPTO patent electronic filing system or three sets of color drawings or color photographs, as appropriate, if not submitted via the via USPTO patent electronic filing system, and, unless already present, an amendment to include the following language as the first paragraph of the brief description of the drawings section of the specification:
The patent or application file contains at least one drawing executed in color. Copies of this patent or patent application publication with color drawing(s) will be provided by the Office upon request and payment of the necessary fee.
Color photographs will be accepted if the conditions for accepting color drawings and black and white photographs have been satisfied. See 37 CFR 1.84(b)(2).
The drawings were received on November 10, 2025. These drawings are not acceptable. Figures 1, 7A-B and 8A-C are not acceptable because the black background makes the figures difficult to see and read.
Claim Objections
Claims 1-20 are objected to because of the following informalities:
Claim 1 appears to contain a typographical error. It states “an continuous execution path” in line 12 which should read “a continuous execution path”.
Claim 3 appears to contain a typographical error in line 3. It states “one of the of pairs…” which should read “one of the pairs…”.
Claim 4 recites the limitation "the place in a program code" in line 3. There is insufficient antecedent basis for these limitations in the claim. In the interest of compact prosecution, the Examiner subsequently interprets this limitation as reading “a place in the program code” for the purpose of further examination.
Claims 6 and 18 recite the limitation "the timeline” in line 3. There is insufficient antecedent basis for these limitations in the claim. In the interest of compact prosecution, the Examiner subsequently interprets this limitation as reading “a timeline” for the purpose of further examination.
Claim 7 contains a typographical error. Claim 7 states to be dependent on claim 7. In the interest of compact prosecution, the Examiner will interpret claim 7 to be dependent on claim 1.
Claims 14 appears to contain a typographical error. It states “the at least one process” in line 8 which should read “the at least one processor”.
Claims 15 appears to contain a typographical error. It states “the plurality the first and second trace markers” in line 3 which should read “the plurality of first and second trace markers”.
Claims 16 appears to contain a typographical error. It states “with an identifier with an identifier” in line 2 which should read “with an identifier”.
Claim 20 recites the limitation “the one or more parent functions” and "the parent functions" in lines 2 and 3 respectively. There is insufficient antecedent basis for these limitations in the claim. In the interest of compact prosecution, the Examiner subsequently interprets this limitation this limitation as “one or more parent functions” and “the one or more parent functions” for the purpose of further examination..
Claims 2-13 and 15-20 depend on the objected to claims and do not resolve the deficiencies and thus, are objected to for at least the same reasons.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
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 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. Claims 1 and 14 state "creating a visual mapping derived solely from trace data". The Examiner has looked through the specification and has been unable to find support explicitly for "derived solely". The specification provides support for “creating a visual mapping derived from trace data” but not explicitly “solely”.
Claims 2-13 and 15-20 depend on the rejected claims and do not resolve the deficiencies and thus, are rejected for at least the same reasons.
Claim 8 is 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.
Claim 8 recite the limitation "wherein a second computing devices" in line 1. It is unclear if the “second computing devices” is supposed to be plural, is referring to the “second computing device” introduced in claim 1 for which claim 8 is dependent on or is a different “second computing device” or “second computing devices”.
Claim Rejections - 35 USC § 102
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)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-2, 6, 13-14, 18 and 20 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by DeMonner et al. (US 2023/0091719).
With respect to Claim 1, DeMonner et al. disclose:
accessing the program code of a computer database on a first computing device; (compiler accesses the user application written in a compiled and/or interpreted language, Paragraphs 17 and 18, lines 1-15 and 1-34; see Figure 3; computer node 120a (first computing device))
analyzing the program code to determine where functions are scheduled to be executed; (determine events such as method invocation, method return, (functions are schedule to be executed) execution of a new line of code, raising of exceptions, and periodic within the user application, Paragraph 18)
inserting into the program code a first trace marker indicating where a given function has begun and a second trace marker indicating where the given function has ended, the first and second trace markers defining a pair; (compiler can insert callbacks as “hooks” (first/second trace markers) such that when processing the executable code, the modified compiler may generate code to provide (or the modified runtime environment may provide) initial signals passed in the callbacks to the client library, as well as to provide results from the callbacks to the client library, Paragraph 18; callbacks are triggered at method invocation (function has begun) and method return (function has ended) (pair), Paragraph 18; callbacks are inserted at entry and/or exit of methods, Paragraph 18)
continuing to insert into the program code a plurality of pairs of first trace markers and second trace markers at the beginning and ending of each function within the program code; (invoking/inserting callbacks at method invocation and method return, Paragraph 18; inserting callbacks at the entry and/or exit of methods (each function within the code), Paragraph 18; capturing a plurality of functions and/or methods of a user application, Paragraph 17, lines 1-7)
running the program code including the first and second trace markers on one of the first computing device or a second computing device and recording a trace; (executing an instance of a user application wherein the user application cooperates with a platform to capture a recording of code execution that includes traces (e.g., timing information such as call duration, entry/exit timestamps and the like) (trace markers) as well as application execution information (e.g., execution of code and associated data/variables), Paragraph 11; capture infrastructure runs in a VMI on computer node 120a (first computing device), Paragraph 19)
and wherein an continuous execution path is drawn on the trace recording for each function that is executed, creating a visual mapping derived solely from trace data of all executed functions. (a call graph (continuous execution path) may be constructed from the recording (derived solely/drawn) to aid visualization, Paragraph 11; the call graph disclosed herein encompasses a history and relationships (through parenting and sequencing/timing information) of all calls in an operation, (both synchronous and asynchronous) (executed functions), Paragraphs 32 and 38; the user may select (click on) a frame to visualize the execution of code on the UI in an organized manner (e.g., synchronously executed methods grouped by a stack of windows layered according to sequential order of execution) across different methods that were invoked (called) during execution of the code along with their associated call parameters, wherein asynchronously invoked methods are visualized distinctively (e.g., grouped as a separately displayed stack of windows)., Paragraph 33)
With respect to Claim 2, all the limitations of Claim 1 have been addressed above; and DeMonner et al. further disclose:
further comprising steps of inserting additional trace markers where a function is being called and where a function is being scheduled to be executed later in the same thread or different threads. (a recording is a faithful representation of code execution that includes trace data and application data embodied as one or more frames corresponding to code (i.e., one or more methods) and associated values as captured during code execution. That is, the recording is directed to capturing a faithful representation of code execution to allow subsequent inspection of code behavior, including events or significant occurrences, (additional trace markers) by a user that may not have known at the time of execution that the occurrences would subsequently be of interest. A method invocation (call) (additional trace marker/function being called) has arguments that are passed to the method and captured, i.e., the capture provides access to actual values of the arguments that are passed to the method. The capture for the method is referred to as a frame, i.e., a frame corresponds to code (e.g., a method) and its values. Other calls inside the frame are invoked and their called methods and arguments are captured. (additional trace markers/function is being scheduled to be executed later in the same thread or different threads) Notably, the return values and the return locations of called methods are also captured and displayed for the frame., Paragraph 31)
With respect to Claim 6, all the limitations of Claim 1 have been addressed above; and DeMonner et al. further disclose:
further comprising a step of defining pairs of method name identifiers and adding the pairs of method name identifiers to the trace markers to link closest slices on the timeline in the trace. (The call graph is configured to intuitively organize the asynchronous invocation, (method name identifiers) which is generally difficult to visually depict, particularly with respect to proper linking and parenting of the asynchronous execution to its current method invocation (frame), Paragraph 35; , the call graph disclosed herein encompasses a history and relationships (through parenting and sequencing/timing information) (pairs of method name identifiers) of all calls in an operation, both synchronous and asynchronous (link the closest slices on a timeline in the trace), Paragraph 32)
With respect to Claim 13, all the limitations of Claim 1 have been addressed above; and DeMonner et al. further disclose:
further comprising a step of reviewing the trace recording to identify areas where performance can be improved. (a developer may employ the platform to provide capture and analysis of the operations (contextualized as “recordings”) to aid in executable code development, debugging, performance tuning, error detection, and/or anomaly capture managed by issue, Paragraph 10)
With respect to Claim 14, DeMonner et al. disclose:
a first computer device including at least one processor and a non-transitory computer readable memory storing program code, (see Figure 3; computer node 120a (first computing device) contains the user application (program code)) the program code including a plurality of first trace markers indicating where a given function has begun and a plurality of corresponding second trace markers indicating where the given function has ended; (compiler can insert callbacks as “hooks” (first/second trace markers) such that when processing the executable code, the modified compiler may generate code to provide (or the modified runtime environment may provide) initial signals passed in the callbacks to the client library, as well as to provide results from the callbacks to the client library, Paragraph 18; callbacks are triggered at method invocation (function has begun) and method return (function has ended) (pair), Paragraph 18; callbacks are inserted at entry and/or exit of methods, Paragraph 18)
the at least one process[or] configured to execute the program code including the plurality of first and second trace markers to produce a trace recording (executing an instance of a user application wherein the user application cooperates with a platform to capture a recording of code execution that includes traces (e.g., timing information such as call duration, entry/exit timestamps and the like) as well as application execution information (e.g., execution of code and associated data/variables), Paragraph 11) including one or more execution paths for each function that has been executed, the one or more execution paths connecting inter-related functions, (a call graph may be constructed (one or more execution paths) from the recording to aid visualization, Paragraph 11; the call graph disclosed herein encompasses a history and relationships (through parenting and sequencing/timing information) of all calls in an operation, (inter-related functions) both synchronous and asynchronous), Paragraph 32) and illustrating when and where each of the functions are scheduled and executed, (the call graph disclosed herein encompasses a history and relationships (through parenting and sequencing/timing information) (when and where) of all calls in an operation, both synchronous and asynchronous. As such, a call graph for an operation contains the information to construct every call stack which existed at every instant during that operation. Particularly, frames executed synchronously are visually grouped in a window so that other frames executed asynchronously to the former frames are visually grouped in a different (separate) window that may be dynamically brought up as the user selects the calls. Return paths of values are further displayed to illustrate the locations from which the calls (frame) returned., Paragraph 32; capture a recording of code execution that includes traces (e.g., timing information such as call duration, entry/exit timestamps and the like) as well as application execution information (e.g., execution of code and associated data/variables) (when and where each of the functions are scheduled and executed), Paragraph 11) wherein a continuous execution path is drawn on the trace recording for each function that is executed, creating a visual mapping derived solely from trace data of all executed functions. (a call graph (continuous execution path) may be constructed from the recording (derived solely/drawn) to aid visualization, Paragraph 11; the call graph disclosed herein encompasses a history and relationships (through parenting and sequencing/timing information) of all calls in an operation, (both synchronous and asynchronous) (executed functions), Paragraphs 32 and 38)
With respect to Claim 18, all the limitations of Claim 14 have been addressed above; and DeMonner et al. further disclose:
wherein the plurality of first and second trace markers each include method name identifiers, the method name identifiers linking the closest slices on the timeline in the trace recording. (The call graph is configured to intuitively organize the asynchronous invocation, (method name identifiers) which is generally difficult to visually depict, particularly with respect to proper linking and parenting of the asynchronous execution to its current method invocation (frame) (pair of method name identifiers), Paragraph 35)
With respect to Claim 20, all the limitations of Claim 14 have been addressed above; and DeMonner et al. further disclose:
wherein the one or more execution paths of each function includes execution paths for the one or more parent functions and all functions that are linked to the parent functions. (the call graph disclosed herein encompasses a history and relationships (through parenting and sequencing/timing information) of all calls in an operation, both synchronous and asynchronous. As such, a call graph for an operation contains the information to construct every call stack which existed at every instant during that operation, Paragraph 32)
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 3 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over DeMonner et al. (US 2023/0091719) in view of Wei-Tsung Lin et al. (“Tracing Function Dependencies Across Clouds”, 2018).
With respect to Claim 3, all the limitations of Claim 1 have been addressed above; and DeMonner et al. do not disclose:
further comprising a step of adding a third trace marker with an identifier within a lambda function if the program code defines the lambda function within one of the pairs of first trace markers and second trace markers.
However, Wei-Tsung Lin et al. disclose:
further comprising a step of adding a third trace marker with an identifier within a lambda function if the program code defines the lambda function. (X-Ray is a tracing tool for AWS that samples the entry and exit of Lambda function instances using unique trace identifiers. (third trace marker) It records function duration and times SDK calls and HTTP accesses that a function makes. This data is sent to an XRay logging service via UDP. The X-Ray logging service visualizes and presents data to developers as logs and dependency trees, called service graphs, A. Serverless Tracing Systems, Page 254, Paragraph 1, lines 3-10)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Wei-Tsung Lin et al. into the teaching of the one or more pairs of first trace markers and second trace markers as taught by DeMonner et al. to include a step of adding a third trace marker with an identifier within a lambda function if the code defines the lambda function in order to help track the performance of serverless applications and tracing their interdependencies. (Wei-Tsung Lin et al., A. Serverless Tracing Systems, Page 254, Paragraph 1, lines 3-10)
With respect to Claim 15, all the limitations of Claim 14 have been addressed above; and DeMonner et al. do not disclose:
wherein the program code further comprises one or more third trace markers with an identifier within a lambda function when the lambda function is within the plurality the first and second trace markers.
However, Wei-Tsung Lin et al. disclose:
wherein the program code further comprises one or more third trace markers with an identifier within a lambda function. (X-Ray is a tracing tool for AWS that samples the entry and exit of Lambda function instances using unique trace identifiers. (third trace marker) It records function duration and times SDK calls and HTTP accesses that a function makes. This data is sent to an XRay logging service via UDP. The X-Ray logging service visualizes and presents data to developers as logs and dependency trees, called service graphs, A. Serverless Tracing Systems, Page 254, Paragraph 1, lines 3-10)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Wei-Tsung Lin et al. into the teaching of first and second trace markers as taught by DeMonner et al. to include wherein the program code further comprises one or more third trace markers with an identifier within a lambda function in order to help track the performance of serverless applications and tracing their interdependencies. (Wei-Tsung Lin et al., A. Serverless Tracing Systems, Page 254, Paragraph 1, lines 3-10)
Claims 4-5 and 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over DeMonner et al. (US 2023/0091719) in view of Sunkara et al. (US 2015/0113122).
With respect to Claim 4, all the limitations of Claim 1 have been addressed above; and DeMonner et al. do not disclose:
wherein upon a Runnable or Callable being created from a function and added to a thread queue, a trace marker with an identifier of the Runnable or Callable is added to the place in a program code where the Runnable or Callable was added to the thread queue.
However, Sunkara et al. disclose:
wherein upon a Runnable or Callable being created from a function and added to a thread queue, a trace marker with an identifier of the Runnable or Callable is added to the place in a program code where the Runnable or Callable was added to the thread queue. (The instrumentation may include instrumenting application server byte code or object code. The constructors may be instrumented such that when they subsequently create an object, in particular a thread handoff object, the object can be tracked. (trace marker) A thread handoff object may be any object that may be likely to result in a new thread being allocated to take control of a process from an existing thread. Examples of automatically instrumented constructors include those that construct objects of callable, runable, and thread. The new thread may be a child thread of the original thread. (thread queue), Paragraph 34)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Sunkara et al. into the teaching of DeMonner et al. to include wherein upon a Runnable or Callable being created from a function and added to a thread queue, a trace marker with an identifier of the Runnable or Callable is added to the place in a program code where the Runnable or Callable was added to the thread queue in order to automatically detect asynchronous handoffs between threads and other software components. (Sunkara et al., Paragraph 4, lines 1-3)
With respect to Claim 5, all the limitations of Claim 1 have been addressed above; and DeMonner et al. do not disclose:
wherein upon a Message being added to the thread queue, a trace marker with an identifier of the Message is added to the function responsible to process the Message.
However, Sunkara et al. disclose:
wherein upon a Message being added to the thread queue, a trace marker with an identifier of the Message is added to the function responsible to process the Message. (The instrumentation may include instrumenting application server byte code or object code. The constructors (Message) may be instrumented such that when they subsequently create an object, in particular a thread handoff object, (added to thread queue) the object can be tracked. (trace marker) A thread handoff object may be any object that may be likely to result in a new thread being allocated to take control of a process from an existing thread. (function responsible to process the Message) Examples of automatically instrumented constructors include those that construct objects of callable, runable, and thread. (Message) The new thread may be a child thread of the original thread., Paragraph 34)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Sunkara et al. into the teaching of DeMonner et al. to include wherein upon a Message being added to the thread queue, a trace marker with an identifier of the Message is added to the function responsible to process the Message in order to automatically detect asynchronous handoffs between threads and other software components. (Sunkara et al., Paragraph 4, lines 1-3)
With respect to Claim 16, all the limitations of Claim 14 have been addressed above; and DeMonner et al. do not disclose:
wherein the program code further comprises one or more fourth trace markers with an identifier of a Runnable or Callable where the Runnable or Callable was added to a thread queue.
However, Sunkara et al. disclose:
wherein the program code further comprises one or more fourth trace markers with an identifier of a Runnable or Callable where the Runnable or Callable was added to a thread queue. (The instrumentation may include instrumenting application server byte code or object code. The constructors may be instrumented such that when they subsequently create an object, in particular a thread handoff object, (added to thread queue) the object can be tracked. (trace marker) A thread handoff object may be any object that may be likely to result in a new thread being allocated to take control of a process from an existing thread. Examples of automatically instrumented constructors include those that construct objects of callable, runable, and thread. The new thread may be a child thread of the original thread. (thread queue), Paragraph 34)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Sunkara et al. into the teaching of DeMonner et al. to include wherein the program code further comprises one or more fourth trace markers with an identifier of a Runnable or Callable where the Runnable or Callable was added to a thread queue in order to automatically detect asynchronous handoffs between threads and other software components. (Sunkara et al., Paragraph 4, lines 1-3)
With respect to Claim 17, all the limitations of Claim 14 have been addressed above; and DeMonner et al. do not disclose:
wherein the program code further comprises one or more fifth trace markers with an identifier of a Message at a function responsible to process the Message.
However, Sunkara et al. disclose:
wherein the program code further comprises one or more fifth trace markers with an identifier of a Message at a function responsible to process the Message. (The instrumentation may include instrumenting application server byte code or object code. The constructors (Message) may be instrumented such that when they subsequently create an object, in particular a thread handoff object, (added to thread queue) the object can be tracked. (trace marker) A thread handoff object may be any object that may be likely to result in a new thread being allocated to take control of a process from an existing thread. (function responsible to process the Message) Examples of automatically instrumented constructors include those that construct objects of callable, runable, and thread. The new thread may be a child thread of the original thread., Paragraph 34)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Sunkara et al. into the teaching of DeMonner et al. to include wherein the program code further comprises one or more fifth trace markers with an identifier of a Message at a function responsible to process the Message in order to automatically detect asynchronous handoffs between threads and other software components. (Sunkara et al., Paragraph 4, lines 1-3)
Claims 7 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over DeMonner et al. (US 2023/0091719) in view of Inagaki et al. (US 2004/0123274).
With respect to Claim 7, all the limitations of Claim [1] have been addressed above; and DeMonner et al. do not disclose:
further comprising a step of adding a class instance identifier to the first and second trace markers to link closest slices that represent methods in a pair and that also have a same class instance identifier.
However, Inagaki et al. disclose:
further comprising a step of adding a class instance identifier to the first and second trace markers to link closest slices that represent methods in a pair and that also have a same class instance identifier. (registering (first and second trace markers) the notified thread identifier, class name (class instance identifier) and method name with the thread processing multiplicity management table and identifying if any method already registered with the same class name and method name and if so, change the trace level in the records with the thread identifiers to “5” (link the closest slices), Paragraphs 35-36)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Inagaki et al. into the teaching of DeMonner et al. to include a step of adding a class instance identifier to the first and second trace markers to link closest slices that represent methods in a pair and that also have a same class instance identifier in order to enable collection of information required for solving a problem caused by simultaneous access to a shared resource in a multithreading environment. (Inagaki et al., Abstract)
With respect to Claim 19, all the limitations of Claim 14 have been addressed above; and DeMonner et al. do not disclose:
wherein the plurality of first and second trace markers each include a class instance identifier, the class instance identifiers link the closest slices that represent methods in a pair that also have the same class instance identifier.
However, Inagaki et al. disclose:
wherein the plurality of first and second trace markers each include a class instance identifier, the class instance identifiers link the closest slices that represent methods in a pair that also have the same class instance identifier. (registering (second trace marker) the notified thread identifier, class name (class instance identifier) and method name with the thread processing multiplicity management table and identifying if any method already registered (first trace marker) with the same class name and method name and if so, change the trace level in the records with the thread identifiers to “5” (link the closest slices), Paragraphs 35-36)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Inagaki et al. into the teaching of DeMonner et al. to include wherein the plurality of first and second trace markers each include a class instance identifier, the class instance identifiers link the closest slices that represent methods in a pair that also have the same class instance identifier in order to enable collection of information required for solving a problem caused by simultaneous access to a shared resource in a multithreading environment. (Inagaki et al., Abstract)
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over DeMonner et al. (US 2023/0091719) in view of Barham et al. (US 2012/0159454).
With respect to Claim 8, all the limitations of Claim 1 have been addressed above; and DeMonner et al. do not disclose:
wherein a second computing devices includes an automated system to analyze the program code and add corresponding lines to the program code including trace markers.
However, Barham et al. disclose:
wherein a second computing devices includes an automated system to analyze the program code and add corresponding lines to the program code including trace markers. (remote instrumentation VM running on a remote physical or virtual machine that executes trace processing logic (analyze the code) and wherein the instrumentation VM provides can dynamically add/enable probes or instrumentation/monitoring points (trace markers) (automated system to analyze the code and add corresponding lines to the code) in the production VM that allow the instrumentation VM to log information about the production VM, Paragraphs 10-11)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Barham et al. into the teaching of DeMonner et al. to include wherein a second computing devices includes an automated system to analyze the program code and add corresponding lines to the program code including trace markers in order to log information about the production/target virtual machine (VM) without affecting the production/target VM's performance. (Barham et al., Paragraph 11)
Claims 9 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over DeMonner et al. (US 2023/0091719) in view of Dinn (US 2012/0311552).
With respect to Claim 9, all the limitations of Claim 1 have been addressed above; and DeMonner et al. further disclose:
the execution path is drawn automatically. (a call graph (execution path) may be constructed (drawn) from the recording to aid visualization (automatically), Paragraph 11;
DeMonner et al. do not disclose:
wherein a portion of the trace to optimize is determined autonomously
However, Dinn discloses:
wherein a portion of the trace to optimize is determined autonomously (performing analysis on the application code (portion of the trace) and performing optimization on the application code autonomously, Paragraphs 43-44)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Dinn into the teaching of DeMonner et al. to include wherein a portion of the trace to optimize is determined autonomously in order to perform optimization of application code without the need of user intervention/input.
With respect to Claim 10, all the limitations of Claim 9 have been addressed above; and DeMonner et al. further disclose:
wherein the execution path of each function includes its parent functions and all the functions that are linked to the parent functions. (the call graph disclosed herein encompasses a history and relationships (through parenting and sequencing/timing information) of all calls in an operation, both synchronous and asynchronous. As such, a call graph for an operation contains the information to construct every call stack which existed at every instant during that operation, Paragraph 32)
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over DeMonner et al. (US 2023/0091719) in view of Cattan et al. (US 10,481,964).
With respect to Claim 11, all the limitations of Claim 1 have been addressed above; and DeMonner et al. do not disclose:
wherein to analyze the program code and insert the first and second trace markers swizzling is utilized.
However, Cattan et al. disclose:
wherein to analyze the program code and insert the first and second trace markers swizzling is utilized. (Monitoring the SDK activity (analyzing the code) may involve hooking system calls, such as by means of instrumentation, “swizzling”, or any other hooking mechanisms, (inserting first/second trace markers) to replace the original code with a new code that checks which SDK has made the call based on the call stack and then invoking the original system call, Column 10, lines 20-28)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Cattan et al. into the teaching of DeMonner et al. to include wherein to analyze the program code and insert the first and second trace markers swizzling is utilized in order to help monitor activity in real-time by using hooking mechanisms to replace original code with a new code that checks which code has made the call based on a call stack and then invoking the original system call. (Cattan et al., Column 10, lines 20-28)
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over DeMonner et al. (US 2023/0091719) in view of Kevin Arhelger et al. (“Use of profilers for studying Java dynamic optimizations”, 2009).
With respect to Claim 12, all the limitations of Claim 1 have been addressed above; and DeMonner et al. do not disclose:
wherein to analyze the program code and insert the first and second trace markers bytecode injections are utilized.
However, Kevin Arhelger et al. disclose:
wherein to analyze the program code and insert the first and second trace markers bytecode injections are utilized. (utilizing bytecode injection which involves a profiler injecting a small piece of code at the beginning and end of the method (analyze the code and insert first/second trace markers), 2.6 Profilers, Page 6, Paragraph 3, lines 4-8)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Kevin Arhelger et al. into the teaching of DeMonner et al. to include wherein to analyze the program code and insert the first and second trace markers bytecode injections are utilized in order to record the time at the beginning and end of the method and also count how many times a method is called. (Kevin Arhelger et al., 2.6 Profilers, Page 6, Paragraph 3, lines 4-8)
Response to Arguments
Applicant’s arguments, see Pages 7-14, filed December 15, 2025, with respect to §101 rejection of claims 1-13 have been fully considered and are persuasive. The §101 rejection of claims 1-13 has been withdrawn.
Applicant’s arguments, see Pages 15-16, filed December 15, 2025, with respect to §101 rejection of claims 14-20 have been fully considered and are persuasive. The §101 rejection of claims 14-20 has been withdrawn.
Applicant's arguments filed December 15, 2025 have been fully considered but they are not persuasive.
In the Remarks Applicant argues:
In the non-Final Office Action mailed September 16, 2025, the drawings were objected to as being of insufficient quality and for lacking certain reference numbers. On November 10, 2025, a set of replacement drawings were filed by the applicant in which certain features were enlarged for better quality and contained the missing reference numbers.
Examiner’s Response:
As can be seen in the updated objection to the drawings, the replacement drawings submitted November 10, 2025 continue to lack sufficient quality. Specifically, Figures 1, 7A-B and 8A-C are hard to see and read due to the black background. It is recommended that the black background be removed to better visualize the figures.
In the Remarks Applicant argues:
Objections have been made in the wording of Claims 1-3, 15 and 18-20. In order to overcome those objections, the wording of the noted claims have been revised as suggested.
Examiner’s Response:
As can be seen in the updated objections to the claims above, some of the Examiner’s previous objections have been corrected while others have not been corrected and new objections have been introduced by the amendments.
In the Remarks Applicant argues:
Claims 1-13 have been rejected because in Claims 1 ,7, 11 and 12 lack sufficient basis for the limitation "the trace markers". In order to overcome that rejection, Claims 1,7,11 and 12 have been amended to include a basis for the noted limitation.
Examiner’s Response:
In light of the amendments to “the trace markers” in claims 1, 7, 11 and 12, the previous rejection under 35 U.S.C. 112(b) has been withdrawn. However, new rejections under 35 U.S.C. 112(a) and 112(b) have been introduced in light of the amendments.
In the Remarks Applicant argues:
In the invention, the visible mapping is independent from source code context. It is derived solely from trace data. DeMonner's program is functionally dependent on source code availability.
DeMonner records execution but the method of visualization in the post-recording stage relies on mapping trace frames back to specific source code artifacts. DeMonner states that the UI displays frames "along with their associated source code". Specifically, the window titles depict the "associated source code reference (e.g., file path and line number)".
DeMonner does not render the trace data itself as the primary visual; it uses the trace data as an index to retrieve and display snippets from the source code. If the source code files are unavailable, moved, or obfuscated in the post-recording stage, DeMonner's method of "displaying... source code" fails. It cannot generate the required "visual mapping".
The "Standalone Artifact" aspect of the invention transforms the code during the recording stage (via marker injection) to embed the necessary context (identity, scheduling origin) into the trace binary itself. An analyst can review the "Execution Path," identify "scheduling" bottlenecks, and see "lambda" identities without possessing the original source code files. This decouples the performance analysis from the source code repository, a capability DeMonner does not teach.
Accordingly, none of the claims 1-2, 6, 13-14, 18 and 20 are anticipated by DeMonner.
Examiner’s Response:
The Examiner respectfully disagrees. The Examiner would first like to note that the specification does not appear to support the amendment of “derived solely”. It would be appreciated if the Applicant provide where in the specification explicit support for “derived solely” can be found. Even so, it is the Examiner’s position that DeMonner discloses the Applicant’s amendment to claim 1 of “a continuous execution path is drawn on the trace recording for each function that is executed, creating a visual mapping derived solely from trace data of all executed functions.” Specifically, DeMonner discloses that “a call graph 180 may be constructed (derived solely) from the recording to aid visualization” (see Paragraph 11). A recording includes trace and application data embodied as one or more frames corresponding to invocations of code and associated values as captured during code execution (see Abstract). Therefore, the visualization (visual mapping) is “derived solely” from the recordings which include trace and application data.
The Examiner would also like to note that the entire UI disclosed in DeMonner is not being equated to the “visual mapping” but the “call graph”. The Examiner would also like to note that the term “derived solely from trace data” does not necessarily preclude the inclusion of “associated source code”. Trace data can reasonably include relevant source code with file paths or line numbers. The Applicant does not further limit what is included or excluded in “trace data” in the claim language.
Further, in response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., decouples the performance analysis from the source code repository) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
In the Remarks Applicant argues:
With regard to Claims 3, 4, 5, 7 -13, each of those claims are dependent upon claim 1 and the combination of those claims, with DeMonner and the various secondary references cited by the Examiner, do not teach a continuous execution path drawn on the trace recording for each function that is executed, creating a visual mapping derived solely from trace data of all executed functions.
With regard to Claims 15-20, each of those claims are dependent upon claim 14 and the combination of those claims, with DeMonner and the various secondary references cited by the Examiner do not teach a continuous execution path drawn on the trace recording for each function that is executed, creating a visual mapping derived solely from trace data of all executed functions.
Accordingly, none of the Claims 3, 4, 5, 7 -13, 15-20 are unpatentable over the combination of with DeMonner and any of the secondary references cited by the Examiner.
Examiner’s Response:
The Examiner respectfully disagrees. Please see response to arguments above with respect to claim 1.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LANNY N UNG whose telephone number is (571)270-7708. The examiner can normally be reached Mon-Thurs 6am-4pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bradley Teets can be reached at 571-272-3338. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/LANNY N UNG/Examiner, Art Unit 2197
Prosecution Insights