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 action is in response to response filed on 2/12/2026.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-4, 9-10, 12-13, 18, 22 and 25 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Garrett et al. (US 2015/0052406 A1).
As per claim 1 (Amended), Mola teaches the invention as claimed including, “A method, comprising:
executing an application in a computing environment;
periodically storing active states of the computing environment during the executing by storing, in a plurality of containers, , wherein the stored active states are loaded, in the plurality of containers, in a memory of the computing environment;”
Garrett et al. teaches a tracing and debugging system that takes a snapshot of an application in response to an event and may continue executing the program after the snapshot is captured. The snapshot (loaded into a container) may be stored (in memory) and retrieved later in a debugging tool. The snapshot (container) may contain a subset of the state of the application, such as call stacks, portions of source code, the values of local and global variables, and various metadata (loaded into container) (0002). Also see 0018. When conditions are satisfied, the monitoring agent may cause the application to pause, then collect the snapshot data (0022). Also see 0024. The performance measurement system may monitor an application on a periodic basis and may be a platform on which snapshots of the program state may be taken (0026-0027). Also see 0044-0045 and 0050.
“generating a linear interface depicting a media file comprising the stored active states of the computing environment, wherein respective segments of the media file correspond to respective stored active states;
presenting, for display on a user device, the linear interface; and
in response to receiving, via the linear interface, a selection of a segment of the media file:
identifying a respective stored active state of the application from a particular container in the plurality of containers; and
replacing executing of the application in the computing environment with execution of the respective stored active state from the particular container.”
Garrett et al. teaches a timeline may present both performance data and snapshot instances. The bottom portion of the time line includes snapshot indicators. Each of the snapshot indicators (media file) may represent a single snapshot (0111). A user may be able to select various elements (media file) of the timeline to view underlying data. A selected snapshot (media file) may cause the user interface to be populated as illustrated. The selected snapshot may represent a specific snapshot (container) that the user wishes to view and the selection may cause the snapshot (container) to be retrieved from storage and displayed in the user interface (0112-0113). Snapshots may be viewed in a debugging user interface, which may also serve as part of a real time debugger. Such embodiments may view the stored snapshots as instances of the real time debugger that are recalled from the point the snapshots were taken (0023).
As per claim 2, Garrett et al. teaches, “The method of claim 1, further comprising saving the stored active states of the computing environment in a non-volatile storage medium.”
Garrett et al. teaches a tracing and debugging system that takes a snapshot of an application in response to an event and may continue executing the program after the snapshot is captured. The snapshot (container) may be stored and retrieved later in a debugging tool. The snapshot (container) may contain a subset of the state of the application, such as call stacks, portions of source code, the values of local and global variables, and various metadata (0002). Also see figures 1 and 2 (246).
As per claim 3 (Amended), Garrett et al. further teaches, “The method of claim 2, further comprising saving the stored active states periodically.”
Garrett et al. teaches a tracing and debugging system that takes a snapshot of an application in response to an event and may continue executing the program after the snapshot is captured. The snapshot (container) may be stored and retrieved later in a debugging tool. The snapshot (container) may contain a subset of the state of the application, such as call stacks, portions of source code, the values of local and global variables, and various metadata (0002). Also see 0018. When conditions are satisfied, the monitoring agent may cause the application to pause, then collect the snapshot data (0022). Also see 0024. The performance measurement system may monitor an application on a periodic basis and may be a platform on which snapshots of the program state may be taken (0026-0027). Also see 0044-0045 and 0050.
As per claim 4, Garrett et al. further teaches, “The method of claim 2, wherein further comprising saving the stored active states responsive to a user input.”
A user may be able to create or modify as snapshot definition for deploying future snapshots (0031). After a snapshot is defined, the snapshot may be deployed to collect data while an application executes (0032). Also see 0044.
As per claim 9, Garrett et al. further teaches, “The method of claim 1, wherein the linear interface allows a user to terminate a process associated with the application.”
Garrett et al. teaches a timeline may present both performance data and snapshot instances. The bottom portion of the time line includes snapshot indicators. Each of the snapshot indicators may represent a single snapshot (0111). A user may be able to select various elements of the timeline to view underlying data. A selected snapshot may cause the user interface to be populated as illustrated. The selected snapshot may represent a specific snapshot that the user wishes to view and the selection may cause the snapshot to be retrieved from storage and displayed in the user interface (0112-0113). Snapshots may be viewed in a debugging user interface, which may also serve as part of a real time debugger. Such embodiments may view the stored snapshots as instances of the real time debugger that are recalled from the point the snapshots were taken (0023). Also see figure 4. The examiner states when a user selects a new snapshot the old one presented in the timeline would be terminated to display the new one.
As per claim 10, Garrett et al. further teaches, “The method of claim 1, wherein the linear interface presents contents of one or more registers of the computing environment.”
Garrette et al. teaches data collected through profiling includes register contents (0034). A timeline presents both performance data and snapshot data (0111).
As per claims 12-13, 18, 22 and 25, claims 12-13 18, 22 and 25 contain similar limitations to claims 1-2 and 9 and are therefore rejected for similar reasons.
Claims 8, 17 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Garrett et al. (US 2015/0052406) as applied to claim 1, 12 and 18 above and further in view of Bruestle et al. (US 2023/0269082 A1).
As per claim 8, Garrett et al. further teaches, “The method of claim 1, wherein the periodic storing occurs for each clock cycle of the computing environment.”
A snapshot may occur as an application executes, and may collect various program state at the designated events (0018). When conditions are satisfied, the monitoring agent may cause the application to pause, then collect the snapshot data, and cause the application to resume execution (0021). The performance measurement system may monitor an application on a periodic basis and may be a platform on which snapshots of the program state be taken.
However, Garrette et al. does not explicitly appear to teach, “for each clock cycle of the computing environment”.
Bruestle et al. teaches an execution trace may be a snapshot of the full state of the machine at each clock cycle of computation.
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Garrett et al. with Bruestle et al. because both teach taking a snapshot of a state of an application. Garrette et al. teaches taking a snapshot at a designated event. Bruestle et al. teaches taking a snapshot at each clock cycle of computation. It would have been obvious for the event of Garrett et al. to be a clock cycle, this is nothing more than a design choice and would have been obvious to try.
Claims 17 and 21, contains similar limitations to claim 8 and is therefore rejected for the same reasons.
Claims 11 and 23-24 are rejected under 35 U.S.C. 103 as being unpatentable over Garrett et al. (US 2015/0052406) applied to claims 1 and 18 above, further in view of Takeuchi et al. (US 2023/0396502 A1).
As per claim 11, Garrett et al. further teaches, “The method of claim 1, wherein the storing is performed by a sidecar container.”
Garrett et al. teaches a tracing and debugging system that takes a snapshot of an application in response to an event and may continue executing the program after the snapshot is captured. The snapshot (container) may be stored and retrieved later in a debugging tool. The snapshot (container) may contain a subset of the state of the application, such as call stacks, portions of source code, the values of local and global variables, and various metadata (0002). Also see figures 1 and 2 (246).
Takeuchi et al. teaches a monitoring manager that deploys a sidecar that outputs (saves), at the monitoring interval as a log, the value of the metric for the monitoring target (0207).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Garrett et al. with Takeuchi et al. because both teach monitoring the execution of an application. Garrett et al. teaches the generation of a snapshot that saves the state of an application. Takeuchi et al. teaches the use of a sidecar to gather a data. The use of a sidecar for monitoring is well known to one of ordinary skill in the art and would have been obvious to try.
As per claims 23-24, they contain limitations similar to claim 11 and are therefore rejected for similar reasons.
Claims 26-28 are rejected under 35 U.S.C. 103 as being unpatentable over Garrett et al. (US 2015/0052406) applied to claims 1, 12 and 18 above, further in view of Mola et al. (US Patent 10,565,087 B2).
As per claim 26, Garrett et al. further teaches, “The non-volatile computer-readable medium of claim 18, wherein the respective stored active state is paused at a particular moment of execution of the application in the particular container, and wherein the non-volatile computer-readable”
Garrett et al. teaches a tracing and debugging system that takes a snapshot of an application in response to an event and may continue executing the program after the snapshot is captured. The snapshot (container) may be stored and retrieved later in a debugging tool. The snapshot (container) may contain a subset of the state of the application, such as call stacks, portions of source code, the values of local and global variables, and various metadata (0002). Also see 0018. When conditions are satisfied, the monitoring agent may cause the application to pause, then collect the snapshot data (0022). Also see 0024. The performance measurement system may monitor an application on a periodic basis and may be a platform on which snapshots of the program state may be taken (0026-0027). Also see 0044-0045 and 0050.
Garrett et al. teaches a timeline may present both performance data and snapshot instances. The bottom portion of the time line includes snapshot indicators. Each of the snapshot indicators may represent a single snapshot (0111). A user may be able to select various elements of the timeline to view underlying data. A selected snapshot may cause the user interface to be populated as illustrated. The selected snapshot may represent a specific snapshot that the user wishes to view and the selection may cause the snapshot to be retrieved from storage and displayed in the user interface (0112-0113). Snapshots may be viewed in a debugging user interface, which may also serve as part of a real time debugger. Such embodiments may view the stored snapshots as instances of the real time debugger that are recalled from the point the snapshots were taken (0023).
However, Garrett et al. does not explicitly appear to teach, “medium further comprises instructions that are executable by the processing device for causing the processing device to replace execution of the application in the computing environment with execution of the respective stored active state from the particular container by: executing the respective stored active state in the computing environment starting at the particular moment of execution.”
Mola teaches a record component that is usable to trace execution of an application and store trace data (periodically storing) in in trace files (column 5, lines 65- column 6 lines 1-10). Also see column 7, lines 10-15. A trace file includes a plurality of trace data streams. Each trace data stream includes a plurality of data packets storing trace data that is usable by the replay component to reproduce execution of its corresponding executable entity, by supplying appropriate recorded state data to executable code of the executable code of the executable entity at appropriate times (column 7, lines 62 – column 8, lines 1-23.
The trace file includes a key frame at the beginning of each trace data stream (which enables the replace component to begin replace of each trace data stream), as well as additional key frames appearing throughout each trace data stream. Key frames enable the replay component to initiate replay of each trace data stream at various points using sequencing numbers each corresponding with a key frame (column 10, lines 11-45). Data packets include some data packets identifying events that are orderable (linear) across the entities/data streams. Orderable events are represented with a sequencing number that defines the relative order in which the events occurred across the entities relative to each other (column 10, lines 58- column 11, lines 1-9). Also see figure 2. Also see column 11, lines 53- column 12, lines 1-14 and column 12, lines 58-64. Mola further teaches a replay timeline that representing a replay of one of executable entities and its corresponding trace data stream. During replay, the replay component may suspend code execution. This may be due to manual intervention by a user or a software component, due to hitting a defined breakpoint or watchpoint. Replay can also be resumed (column 14, lines 40-51). Replay can also be rolled back (column 17, lines 1-3).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Garrett et al. with Mola et al. because both teach recording the state of the execution of an application. Garrett et al. teaches selecting a snapshot and recreating the snapshot in a real time debugger. However, Garrett et al. does not explicitly appear to teach executing from that state. Mola et al. teaches performing a replay/execution from a selected trace file. Replaying a application from a saved state is well known to one of ordinary skill in the art. This will not only allow Garrett et al. to recreate the state in the real time debugger but now also continue execution to further debug the application from that point and would have been obvious to try.
Claims 27 and 28, contains similar limitations to claim 26 and is therefore rejected for the same reasons.
Response to Arguments
Applicant's arguments filed 2/12/2026 have been fully considered but they are not persuasive.
Regarding 35 U.S.C 102 rejection:
Applicant Argues:
“Applicant respectfully disagrees with the above rejections. For example, as previously argued in the Response to final Office Action filed on January 7, 2026, Garrett is entirely silent as to any mention of containers, which are recited in independent claim 1. In response, the Advisory Action merely stated, on page 3, that "[t]he examiner respectfully disagrees." The Advisory Action does not indicate where Garrett teaches containers or storing active states of a computing environment in containers, as claimed. For at least this reason, Garrett does not anticipate each and every element of independent claim 1, and independent claim 1 is patentable over Garrett.”
The examiner respectfully disagrees. Garret teaches the snapshot (loaded into a container) may be stored (in memory) and retrieved later in a debugging tool. The snapshot (container) may contain a subset of the state of the application, such as call stacks, portions of source code, the values of local and global variables, and various metadata (loaded into container) (0002). Garret further teaches, when conditions are satisfied, the monitoring agent may cause the application to pause, then collect the snapshot data (0022). Therefore, the snapshot is the container. It stores the state information, which is the active state of the system paused at that current time.
Applicant Further Argues:
“The Advisory Action further alleged, on pages 3-4, that Garrett teaches the claimed feature of "periodically storing active states of the computing environment during the executing by creating, in a plurality of containers, a plurality of instances of the computing environment that correspond to the stored active states with execution paused. "In particular, the Advisory Action alleged that Garrett teaches "a tracing and debugging system that takes a snapshot of an application ... The snapshot may be stored and retrieved later in a debugging tool. Therefore, Garrett et al. is teaching a snapshot that is made when execution is paused ... the snapshot of Garrett et al. contains the paused execution state (instance) of the program and meets the current limitation. The specification may state that 'This is crucially distinct from a snapshot, which is merely a collection of data indicative of machine state, and can provide significant performance advantages over snapshots since a state need not be reloaded into the memory 160 to begin execution.' However, none of this is claimed. Th[ere] is no mention of the instance containing respective states already loaded into memory."
Applicant respectfully disagrees. Nevertheless, for the purpose of expediting prosecution, and without conceding to the propriety of the rejections, independent claim 1 is amended to recite "periodically storing active states of the computing environment during the executing by storing, in a plurality of containers, the stored active states with execution paused, wherein the stored active states are loaded, in the plurality of containers, in a memory of the computing environment." Applicant respectfully submits that Garrett's snapshots are entirely different than the claimed stored active states that are stored "in a plurality of containers ... with execution paused," and which are "loaded, in the plurality of containers, in a memory of the computing environment."”
The examiner respectfully disagrees. Applicant argues that Garrett’s snapshots are entirely different that the claimed stored active states that are stored “in a plurality of containers… with execution paused” and which are “loaded, in the plurality of containers, in memory of the computing device. Applicant's arguments fail to comply with 37 CFR 1.111(b) because they amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references. As stated above, Garret teaches the snapshot (container) may be stored (memory) and retrieved later in a debugging tool. The snapshot (container) may contain a subset of the state of the application, such as call stacks, portions of source code, the values of local and global variables, and various metadata (0002). Garret further teaches, when conditions are satisfied, the monitoring agent may cause the application to pause, then collect the snapshot data (0022). Therefore, the snapshot is the container. It stores the state information, which is the active state of the system paused during the current condition. The examiner also states that there is no limit to the condition occurring only once and therefore would enable multiple snapshots to be taken periodically when the condition is met.
Applicant Further Argues:
“Rather than describing "stored active states [that] are loaded ... in a memory of the computing environment," as claimed, Garrett teaches a selection of a specific snapshot (e.g., from user interface) causing "the snapshot to be retrieved from storage and displayed in the user interface 402." See Garrett, paragraph [0113]. Garrett further describes, in paragraph [0030], that "[w]hen viewing a snapshot interface ... the data being displayed may be retrieved from a storage repository for the snapshots as opposed to retrieving data from a live execution environment." Snapshots that are retrieved from storage differ from the claimed stored active states that are loaded in memory.”
The examiner disagrees. The examiner would first like to point out that the applicants argument of “ Rather than describing “stored active states [that] are loaded ... in a memory of the computing environment," as claimed, Garrett teaches a selection of a specific snapshot (e.g., from user interface) causing "the snapshot to be retrieved from storage and displayed in the user interface 402."”. , is unclear. The examiner has never used paragraph 113 of Garrett to teach the above limitations. Paragraph 113 of Garrett was used to teach a completely different limitation involving later steps in the claim. The examiner has shown above in response to previous arguments that Garrett does meet the claimed limitations of "stored active states [that] are loaded ... in a memory of the computing environment,".
Applicant Further Argues:
“Paragraph [0017] of the filed Application describes how "active instances of the computing environment 110 that contain respective states [are] already loaded into memory 160 ... [as] separate containers with execution paused, allowing the system 100 to rapidly switch ... This is crucially distinct from a snapshot, which is merely a collection of data indicative of machine state, and can provide significant performance advantages over snapshots since a state need not be reloaded into the memory 160 to begin execution." It is therefore clear that the snapshots taught by Garrett are distinct from the active states stored in containers and loaded in memory that are recited in claim 1. For at least these reasons, claim 1 is patentable over Garrett.””
The examiner disagrees. Again the examiner states, Garret teaches the snapshot (loaded into a container) may be stored (in memory) and retrieved later in a debugging tool. The snapshot (container) may contain a subset of the state of the application, such as call stacks, portions of source code, the values of local and global variables, and various metadata (0002). Garret further teaches, when conditions are satisfied, the monitoring agent may cause the application to pause, then collect the snapshot data (0022). Therefore, the snapshot is the container. It stores the state information, which is the active state of the system paused at that current time. Garrette et al. further teaches, that a user is able to select a snapshot which causes the user interface to be populated. The selected snapshot represents a specific snapshot that the user wished to view and the selection may cause the snapshot to be retrieved from storage and displayed in the user interface (0112-0113). Therefore, the examiner states when the user selects a snapshot the system changes the execution to display what is contained in the snapshot. The timeline of Garrette et al. will allow a user to change the execution when selecting different snapshots. The display will change from populating execution information from one snapshot (paused active state) to population execution information from another selected snapshot. This meets the limitation of “replacing execution of the application in the computing environment with execution of the respective stored active state from the particular container”.
For these reasons the current rejection stands.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MARK A GOORAY whose telephone number is (571)270-7805. The examiner can normally be reached Monday - Friday 10:00am - 6:00pm.
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, Lewis Bullock can be reached at 571-272-3759. 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.
/MARK A GOORAY/ Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/ Supervisory Patent Examiner, Art Unit 2199