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 Request for Continued Examination filed on May 6, 2026.
Claims 1-20 are pending.
Claims 1-4, 6-8, 18 and 20 have been amended.
Response to Amendment
Claim Objections
Claims 1-20 are objected to because of the following informalities:
Claims 1 and 14 recite the limitation "the scheduling relationship" in lines 19 and 13 respectively. 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 scheduling relationship” for the purpose of further examination.
Claims 1 and 14 recite the limitation "the non-deterministic execution chain" in lines 23-24 and 14 respectively. 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 non-deterministic execution chain” for the purpose of further examination.
Claims 1 and 14 recite the limitation "the time delta between the time a function was scheduled and its execution" in lines 20-21 and 16-17 respectively. 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 time delta between a time a function was scheduled and its execution” for the purpose of further examination.
Claim 14 recites “a first computing device” twice in lines 3 and 4.
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.
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 "The Examiner has been unable to find support for or recitation in the specification for “resolve the non-deterministic execution chain”. Further, claims 1 and 14 state “revealing the time delta between the time a function was schedule and its execution. The specification provides support for a “visualization that links the function to the place and the time the function was scheduled” but not a “time delta between the time a function was scheduled and its execution”. Further still, claim 1 states “analysis and visualization independent of further access to the computer database”. The Examiner has been unable to find support for this limitation in the specification. It is requested that the Applicant provide citations in the specification where support for these limitations can be found.
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 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 1-2, 6 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over DeMonner et al. (US 2023/0091719) in view of Allen (US 8,589,893) and in further view of Habak et al. (US 2017/0351546).
With respect to Claim 1, DeMonner et al. disclose:
accessing the program code of a computer database; (compiler accesses the user application written in a compiled and/or interpreted language, Paragraphs 17 and 18, lines 1-15 and 1-34)
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)
before the application runs, using said [one or more second computing devices] computing device to statically insert a first trace marker directly into the program code 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 (before the application runs) can insert callbacks as “hooks” (statically insert first/second trace markers) such that when processing the executable code, the modified compiler may generate code to 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 by a compiler (statically insert), Paragraph 18)
continuing to insert into the program code a plurality of pairs of first trace markers and second trace markers at a beginning and ending of each function within the program code; (invoking/inserting callbacks (trace markers) at method invocation and method return, Paragraph 18; inserting callbacks (trace markers) 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 or more of said second computing devices to create 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 (trace recording) 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 (one or more second computing device), Paragraph 19))
recording the inserted trace markers; (The recording includes trace and application data embodied as one or more frames corresponding to invocations of code (i.e., one or more methods) and associated values (e.g., parameters, exceptions, return values and the like) as captured during code execution (inserted trace markers), Paragraph 9)
drawing continuous colored execution paths on the trace recording for each function that is executed by mapping the scheduling relationship between a parent function and all functions linked to the parent function to resolve the non-deterministic execution chain; (the UI displays the captured recording of code execution in the form of a call graph (continuous execution paths) that illustrates (i.e., visually depicts) the frames as corresponding code of the invoked methods and values of the frames, in context and independent of source code layout., Paragraph 32; 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. (non-deterministic execution chain), Paragraph 32; call graph is inherently displayed in some color such as black)
creating a visual mapping drawn on the trace recording derived from trace data of all executed functions allowing scheduling relationships to be observed, (the UI displays the captured recording of code execution (trace data) in the form of a call graph (visual mapping) that illustrates (i.e., visually depicts) the frames as corresponding code of the invoked methods and values of the frames, in context and independent of source code layout., Paragraph 32; 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)
wherein performance optimization is achieved utilizing a single interaction with the application to generate a trace recording that allows for analysis and visualization independent of further access to the computer database. (a developer may employ the platform to provide capture and analysis of the operations (contextualized as “recordings”) (trace recording/single interaction) to aid in executable code development, debugging, performance tuning, error detection, and/or anomaly capture managed by issue. (performance optimization is achieved)(no disclosure of further access to the computer database), Paragraph 10; a call graph 180 may be constructed from the recording to aid visualization, Paragraph 11)
DeMonner et al. do not disclose:
accessing the program code of a computer database on said first computing device
before the application runs, using said first computing device to statically insert a first trace marker directly into the program code indicating where a given function has begun and a second trace marker indicating where the given function has ended;
revealing the time delta between the time a function was scheduled and its execution;
However, Allen discloses:
accessing the program code of a computer database on said first computing device; (Computer system 22 may include one or more computers (first computing device). Computer system 22 includes an instrumenting compiler 30, an instrumented endpoint 32, a slicing compiler 34, and a production endpoint 35., Column 2, lines 34-37; production endpoint 35 may be used to obtain program source code rather than using a repository 20. Instrumenting compiler 30 retrieves the program definition (program code) from repository 20 or from production endpoint 35, Column 6, lines 1-12)
before the application runs, using said first computing device to statically insert a first trace marker directly into the program code indicating where a given function has begun and a second trace marker indicating where the given function has ended; (see Figure 3; instrumenting compiler (first computing device) inserts tracing logic and callback routines (before the application runs) into the source code at exit and entry points (first/second trace markers) in the program definition (program code), Column 6, lines 1-23)
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 Allen into the teaching of DeMonner et al. to include accessing the program code of a computer database on said first computing device and before the application runs, using said first computing device to statically insert a first trace marker directly into the program code indicating where a given function has begun and a second trace marker indicating where the given function has ended in order to distribute the tracing process (instrumentation and execution) across multiple computing devices so that one computing device is not overloaded.
DeMonner et al. and Allen do not disclose:
revealing the time delta between the time a function was scheduled and its execution;
However, Habak et al. disclose:
revealing the time delta between the time a function was scheduled and its execution; (Execution duration (time delta): Timestamp of each function invocation T_invoke and return T_returnfi, Paragraph 37)
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 Habak et al. into the teaching of DeMonner et al. and Allen to include revealing the time delta between the time a function was scheduled and its execution in order to help create an application profile which can assist in offloading systems. (Habak et al., Paragraph 9)
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 a 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 a 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)
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over DeMonner et al. (US 2023/0091719) in view of Allen (US 8,589,893) in view of Habak et al. (US 2017/0351546) and in further 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., Allen and Habak 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., Allen and Habak 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)
Claims 4-5 are rejected under 35 U.S.C. 103 as being unpatentable over DeMonner et al. (US 2023/0091719) in view of Allen (US 8,589,893) in view of Habak et al. (US 2017/0351546) and in further 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., Allen and Habak et al. do not disclose:
wherein 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 a place in a program code where the Runnable or Callable was added to the thread queue.
However, Sunkara et al. disclose:
wherein 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 a 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., Allen and Habak et al. to include wherein 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 a 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., Allen and Habak 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., Allen and Habak 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)
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over DeMonner et al. (US 2023/0091719) in view of Allen (US 8,589,893) in view of Habak et al. (US 2017/0351546) and in further 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., Allen and Habak 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., Allen and Habak 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)
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over DeMonner et al. (US 2023/0091719) in view of Allen (US 8,589,893) in view of Habak et al. (US 2017/0351546) and in further 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., Allen and Habak et al. do not disclose:
wherein one or more of said 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 one or more of said 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., Allen and Habak et al. to include wherein one or more of said 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 Allen (US 8,589,893) in view of Habak et al. (US 2017/0351546) and in further 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., Allen and Habak et al. further disclose:
the execution path is drawn automatically. (DeMonner et al., a call graph (execution path) may be constructed (drawn) from the recording to aid visualization (automatically), Paragraph 11;
DeMonner et al., Allen and Habak 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., Allen and Habak 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) n view of Allen (US 8,589,893) in view of Habak et al. (US 2017/0351546) and in further 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., Allen and Habak 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., Allen and Habak 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) n view of Allen (US 8,589,893) in view of Habak et al. (US 2017/0351546) and in further 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., Allen and Habak 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., Allen and Habak 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)
Claims 14, 18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over DeMonner et al. (US 2023/0091719) in view of Habak et al. (US 2017/0351546).
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 processor 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)
drawing continuous colored execution paths on the trace recording for each function that is executed by mapping the scheduling relationship between a parent function and all functions linked to the parent function to resolve the non-deterministic execution chain; (the UI displays the captured recording of code execution in the form of a call graph (continuous execution paths) that illustrates (i.e., visually depicts) the frames as corresponding code of the invoked methods and values of the frames, in context and independent of source code layout., Paragraph 32; 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. (non-deterministic execution chain), Paragraph 32)
creating a visual mapping drawn on the trace recording derived from trace data of all executed functions allowing scheduling relationships to be observed, (the UI displays the captured recording of code execution (trace data) in the form of a call graph (visual mapping) that illustrates (i.e., visually depicts) the frames as corresponding code of the invoked methods and values of the frames, in context and independent of source code layout., Paragraph 32; 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)
DeMonner et al. do not disclose:
revealing the time delta between the time a function was scheduled and its execution;
However, Habak et al. disclose:
revealing the time delta between the time a function was scheduled and its execution; (Execution duration (time delta): Timestamp of each function invocation T_invoke and return T_returnfi, Paragraph 37)
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 Habak et al. into the teaching of DeMonner et al. to include revealing the time delta between the time a function was scheduled and its execution in order to help create an application profile which can assist in offloading systems. (Habak et al., Paragraph 9)
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 a 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 one or more parent functions and all functions that are linked to the one or more 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 15 is rejected under 35 U.S.C. 103 as being unpatentable over DeMonner et al. (US 2023/0091719) in view of Habak et al. (US 2017/0351546) and in further view of Wei-Tsung Lin et al. (“Tracing Function Dependencies Across Clouds”, 2018).
With respect to Claim 15, all the limitations of Claim 14 have been addressed above; and DeMonner et al. and Habak 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 of 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. and Habak 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 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over DeMonner et al. (US 2023/0091719) in view of Habak et al. (US 2017/0351546) and in further view of Sunkara et al. (US 2015/0113122).
With respect to Claim 16, all the limitations of Claim 14 have been addressed above; and DeMonner et al. and Habak 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. and Habak 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. and Habak 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. and Habak 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)
Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over DeMonner et al. (US 2023/0091719) in view of Habak et al. (US 2017/0351546) and in further view of Inagaki et al. (US 2004/0123274).
With respect to Claim 19, all the limitations of Claim 14 have been addressed above; and DeMonner et al. and Habak 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. and Habak 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)
Response to Arguments
Applicant’s arguments, see Page 14, filed March 18, 2026, with respect to the objection of claims 1-20 and §112(a) rejection of claims 1-20 have been fully considered and are persuasive. The objection of claims 1-20 and §112(a) rejection of claims 1-20 have been withdrawn.
Applicant's arguments filed March 18, 2026 have been fully considered but they are not persuasive.
In the Remarks, Applicant argues:
The method of the invention and the DeMonner system are designed for different purposes and operate differently. Important differences relate to source-independence and the self-sufficiency of the traces. The invention is designed for performance optimization, particularly for mobile apps (Android SDK examples), and works from a single interaction without requiring historical data.
The invention and the reference employ different ways to obtain visibility into code execution. In the invention, trace markers are loaded directly into the source code before the application runs. The markers tag the start and end of the functions. When the application executes, colored paths are drawn on a trace timeline showing the full execution chain, including across asynchronous threads.
When an application is running and a trace is being recorded, the entire trace can be viewed as a continuous timeline. Individual threads can also each be viewed as continuous timelines. For multiple continuous parallel processes which may affect each other, each process is selected in turn, and the invention will reconstruct and visualize its continuous execution path.
The reference uses a runtime capture infrastructure (a client library plus an agent) that hooks into the running application dynamically. No source code changes are needed. It captures a data set and displays everything as a navigable call graph of stacked windows, each showing the relevant source code snippet for an invoked method. It targets server-side/cloud environments (Ruby/Rails examples) and is more focused on debugging and understanding code behavior than on performance tuning specifically.
The reference is a dynamic configuration system with heuristics and capture filters that can be reloaded at runtime to adjust what gets recorded and at what fidelity. In the invention, the trace markers are placed statically.
Examiner’s Response:
The Examiner respectfully disagrees. 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 (a single interaction without requiring historical data, individual threads can also each be viewed as continuous timelines and multiple continuous parallel processes which may affect each other, each process is selected in turn, and reconstruct and visualize its continuous execution path) 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).
Further, as can be seen in the updated §103 rejection above, it is the Examiner’s position that DeMonner discloses placing trace markers statically as well as dynamically at runtime. Specifically, DeMonner discloses that a compiler and/or runtime environment can insert callbacks as “hooks” such that when processing the executable code, the modified compiler may generate code to provide initial signals passed in the callbacks to the client library, as well as to provide results from the callbacks to the client library (see Paragraph 18). The recitation of a compiler inserting “hooks” means that the “hooks” (trace markers) are inserted statically and/or dynamically at runtime. Thus, there is a “source code change”.
Further, DeMonner states “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.” (see Paragraph 10). Therefore, DeMonner is focused on performance tuning.
In the Remarks, Applicant argues:
The reference uses a distributed architecture with separate capture, analysis/storage (APS), and UI infrastructures across virtual machines. The invention employs a much simpler setup. It uses computing devices for accessing a code database.
The colored paths drawn in the invention connect related functions on a timeline. This allows seeing the scheduling relationships at a glance. On the other hand, the reference shows stacked windows where each frame displays actual source code with highlighted lines where the next method is called. It distinguishes synchronous execution (overlapping windows on the same stack) from asynchronous execution (separate window stacks marked with an "ASYNCHRONOUS" indicator).
Examiner’s Response:
The Examiner respectfully disagrees. The current claim language does not preclude the use or interpretation of “separate capture, analysis/storage (APS), and UI infrastructures across virtual machines”. While the Applicant’s invention may or may not be “a much simpler setup”, the current claim language does not preclude a more “complex” setup. DeMonner’s call graph also has “colored paths drawn” as well as being able to see “scheduling relationships”. Specifically, DeMonner discloses displays the captured recording of code execution in the form of a call graph (continuous execution paths) that illustrates (i.e., visually depicts) the frames as corresponding code of the invoked methods and values of the frames, in context and independent of source code layout and 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. (see Paragraph 32) The call graph is displayed in some color such as black (colored paths drawn).
In the Remarks, Applicant argues:
DeMonner's system fails if the code is obfuscated or inaccessible. The invention can capture complex execution relations and scheduling origins entirely within a binary, without external files.
Asynchronous non-determinism is critical because mobile asynchronous scheduling is often non-deterministic. These execution details cannot be recovered from DeMonner's traces even with the codebase. In the invention, marker injection captures this scheduling "origin" in real-time, providing context that is otherwise lost.
Examiner’s Response:
The Examiner respectfully disagrees. The current claim language makes no mention of “obfuscated or inaccessible” code, capturing “complex execution relations and scheduling origins entirely within a binary, without external files” and/or asynchronous non-determinism. 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., obfuscated or inaccessible code, capturing complex execution relations and scheduling origins entirely within a binary, without external files and/or asynchronous non-determinism) 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:
Claim 1 has been amended to highlight the above noted differences between the method of invention and the reference. It emphasizes that the application uses a first computing device (which may be a general-purpose computer) and one or more second computing devices (which may be phones running mobile applications) and that program code of a computer database is accessed from the first computing device.
Claim 1 now requires that, before the application runs, using the first computing device to statically insert a first trace marker directly into the program code indicating where a given function has begun and a second trace marker indicating where the given function has ended. Claim 1 now requires drawing continuous colored execution paths on the trace recording for each function that is executed by mapping the scheduling relationship between a parent function and all functions linked to the parent function to resolve the non-deterministic execution chain. Claim 1 now requires allowing the scheduling relationships to be observed, revealing the time delta between the time a function was scheduled and its execution. Finally, claim 1 has been amended to require that performance optimization be achieved utilizing a single interaction with the application to generate a trace recording that allows for analysis and visualization independent of further access to the computer database. Claim 14 has been amended to require the step of drawing continuous colored execution paths on the trace recording for each function that is executed by mapping the scheduling relationship between a parent function and all functions linked to the parent function to resolve the non-deterministic execution chain.
Claim 14 has also been amended to require the step of creating a visual mapping drawn on the trace recording derived from trace data of all executed functions allowing scheduling relationships to be observed, revealing the time delta between the time a function was scheduled and its execution.
Examiner’s Response:
Please see the new grounds of rejection in the updated §103 rejection to claims 1 and 14 in light of the amendments filed March 18, 2026.
In the Remarks, Applicant argues:
Claims 2, 6, and 13 are dependent on claim 1 as amended, and are allowable for the same reasons as claim 1. Claims 18 and 20 are dependent on claim 14, as amended, and are allowable for the same reasons as claim 14 as amended.
Examiner’s Response:
Please see response to arguments above with respect to claims 1 and 14.
Conclusion
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 6:30am-3:30pm.
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/ Primary Examiner, Art Unit 2197
Prosecution Insights