DETAILED ACTION
This Office action is in response to the amendment filed on February 23, 2026.
Claims 1-16 are pending.
Claims 1-2, 4-10, and 12-16 are amended.
The objections to the drawings are withdrawn in view of Applicant’s amendments to the
drawings.
The objections to Claims 2, 4-6, 8-9, 12-14, and 16 are withdrawn in view of Applicant’s amendments to the claims.
Most, but not all, of the 35 USC § 112(b) rejections are withdrawn in view of Applicant’s amendments to the claims. The maintained 35 USC § 112(b) rejection is provided in the Claim Rejections - 35 USC § 112 section provided herein.
The 35 USC § 101 rejections to Claims 1 and 9 are withdrawn in view of Applicant’s amendments to the claims.
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 .
Response to Amendment
Claim Interpretation Under 35 USC § 112(f)
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f):
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f). The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f). The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) because the claim limitations use a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitations are:
“a collection unit configured to […]” and “an analysis unit configured to […]” in Claims 1-8.
Because these claim limitations are being interpreted under 35 U.S.C. 112(f) they are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have these limitations interpreted under 35 U.S.C. 112(f) applicant may: (1) amend the claim limitation(s) to avoid them being interpreted under 35 U.S.C. 112(f) (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitations recite sufficient structure to perform the claimed function so as to avoid them being interpreted under 35 U.S.C. 112(f).
Claim Objections
Claims 2 and 10 are objected to because of the following informalities:
Claims 2 and 10, in line 5 and lines 5-6 respectively, recite “execution of software.” It should read -- execution of the software --.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
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.
Claims 1-8 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention.
Claim limitations “a collection unit configured to […]” and “an analysis unit configured to […]” in Claims 1-8 invoke 35 U.S.C. 112(f). However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. Applicant’s disclosure is devoid of any structures that perform the functions in the claims. The specification discloses in paragraph [0047] that the collection unit may be implemented in a kernel and the analysis unit may be implemented in user space; however, a kernel and user space is not sufficient structure. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b).
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f);
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
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 and 9 are rejected under 35 U.S.C. 103 as being unpatentable over US 9,898,385 (hereinafter “O’Dowd”) in view of US 2021/0303441 (hereinafter “Hazra”), US 2019/0138345 (hereinafter “Singh”), and US 8,826,240 (hereinafter “Lachwani”).
As per Claim 1, O’Dowd discloses:
An apparatus (col. 78 lines 42-44, “Additionally, the skilled artisan will recognize that any of the above-described methods can be carried out using any appropriate apparatus (emphasis added).”) for extracting and analyzing runtime software execution information, comprising:
a processor (col. 70 lines 55-57, “The computer system 1402 includes one or more processing units (CPU) 1406, which may include a processor, such as a microprocessor.”); and a memory (col. 70 lines 59-63, “The computer system 1402 further includes memory 1410, such as random access memory (RAM) for temporary storage of information, a read only memory (ROM) for permanent storage of information, and a mass storage device 1404 […].”) having instructions stored thereon, which, when executed by the processor (col. 73 lines 30-33, “In some embodiments, a computer system includes at least one memory and one or more processors configured to implement the method of any preceding paragraph.”), cause the processor to perform:
a collection unit configured to collect execution-related data […] by tracing, at a kernel level, a function of an operating system on which the software is executed or tracing access to data by the software (col. 62 lines 45-47, “In an embodiment, the trace data logger 207 is configured to collect trace data generated from the execution of the target program 214 (emphasis added).”; col. 65 lines 36-47, “In an embodiment, the operating system is modified (for example, its kernel is modified [at a kernel level]) to record as trace data those actions performed by the operating system on behalf of the target program [execution-related data] that the target program does not have access to, such as (i) calls to operating system services (for example, APIs), (ii) changes performed by the operating system in target program's memory (for example, in response to an operating system service or API), including recording one or more pre-write values, (iii) operating system services performed on behalf of the target computer program [functions of an operating system on which software is executed], (iv) task switching, and the like (emphasis added).”); and
an analysis unit configured to analyze the execution-related data […] to generate required information (Figure 13; col. 62 lines 66-67 to col. 63 lines 1-2, “In an embodiment, the debugger 210 is configured to decode and process the trace data in order to present the replay and/or reconstruction of the events leading up to the crash or the stoppage of the target program (emphasis added).”; col. 69 lines 17-24, “In an embodiment, the display area 1322 also includes various data for presenting a replay or a reconstruction of the execution of the target program, for example, executed commands, inputs/outputs, variable values/changes, register values/changes, memory values/changes, stack trace, breakpoints, source code, break dots to indicate where breakpoints may be placed, and the like (emphasis added).”) [Examiner’s Remarks: Note that O’Dowd discloses the debugger (analysis unit) processing and decoding (analyzing) the trace data (execution-related data in conjunction with data referenced during execution of the software) to replay and reconstruct the events leading up to the target program crash. O’Dowd also discloses that the display for presenting the reconstruction of the events includes various kinds of data. One of ordinary skill in the art would readily comprehend that, to reconstruct the events, the debugger would have to generate required information about the events from the trace data such as the various data included in the display.].
O’Dowd discloses “a collection unit configured to collect execution-related data […] by tracing, at a kernel level, a function of an operating system on which the software is executed or tracing access to data by the software,” but does not explicitly disclose:
a collection unit configured to collect execution-related data generated transiently during execution of software and unavailable after termination of the software by tracing, at a kernel level, a function of an operating system on which the software is executed or tracing access to data by the software.
However, Hazra discloses:
[data] generated transiently during execution of software and unavailable after termination of the software (paragraph [0040], “When the data processing application 202 obtains and/or generates the data variables, the data processing application 202 may temporarily store the data variables in a non-persistent memory space of a machine (e.g., a computer server) allocated to the data processing application 202 (e.g., the random access memory (RAM) of the machine running the data processing application 202). The storing of the data variables in the non-persistent memory space is temporary because the data variables may become unavailable, such as when the data processing application 202 is terminated, when the machine running the data processing application 202 is powered down, or when the data processing application 202 cleans the memory space (e.g., deleting the data variables) after processing the request (emphasis added).”).
O’Dowd is within the same field of endeavor as the claimed invention regarding software data tracing and instrumentation. Hazra is also within the same field of endeavor as the claimed invention regarding the collection of transiently generated data.
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 Hazra into the teaching of O’Dowd to include “a collection unit configured to collect execution-related data generated transiently during execution of software and unavailable after termination of the software by tracing, at a kernel level, a function of an operating system on which the software is executed or tracing access to data by the software.” The modification would be obvious because one of ordinary skill in the art would be motivated to collect data generated during execution of software and unavailable after termination of the software in order to effectively “diagnose the performance of the software application, to track the processing of the requests, etc” (Hazra, paragraph [0040]).
The combination of O’Dowd and Hazra discloses ”an analysis unit configured to analyze the execution-related data […] to generate required information,” but does not explicitly disclose:
an analysis unit configured to analyze the execution-related data in conjunction with software artifact metadata referenced during execution of the software, to generate required information […].
However, Singh discloses:
analyze the [data] in conjunction with software artifact metadata referenced during execution of the software, to generate [information] (paragraph [0053], “The extracted metadata may include operation metadata in the form of or based on run-time artifacts generated by the one or more services 435a-n as the one or more services 435a-n process (i.e., execute) a job or a workflow involving a sequence of multiple jobs on data stored in the computing cluster (emphasis added).”; paragraph [0054], “As further described with respect to FIG. 4B, the step of indexing and storing the metadata may include or be associated with, at step 506, processing [analyzing] the extracted metadata to identify entities (e.g., files, directories, tables, scripts, script executions, query templates, query executions, job templates, job executions, etc.) involved in the run-time processing of data (i.e., execution of jobs and workflows) in the distributed computing cluster 135 and identifying entity relationships (e.g., data flow, parent-child, logical-physical, instance of, control flow, etc.) (emphasis added).”; paragraph [0057], “The example process 500 continues at step 508 with generating data lineage information based on at least some of the identified entities (and associated entity properties) and the identified relationships between entities (emphasis added).”).
Singh is within the same field of endeavor as the claimed invention regarding the analysis of runtime artifact metadata.
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 Singh into the combined teachings of O’Dowd and Hazra to include “an analysis unit configured to analyze the execution-related data in conjunction with software artifact metadata referenced during execution of the software, to generate required information […].” The modification would be obvious because one of ordinary skill in the art would be motivated to utilize a system that analyzes artifact metadata referenced during execution of software in order to effectively enable automatic collection, visualization, and utilization of data lineage based on the analyzed metadata which can be used to optimize the system and give users effective insight into large amounts of data quickly (Singh, paragraphs [0003, 0017, & 0018]).
The combination of O’Dowd, Hazra, and Singh discloses “an analysis unit configured to analyze the execution-related data in conjunction with software artifact metadata referenced during execution of the software, to generate required information […],” but does not explicitly disclose:
an analysis unit configured to analyze the execution-related data in conjunction with software artifact metadata referenced during execution of the software, to generate required information including identification of a software component and a corresponding version actually executed by the software at runtime.
However, Lachwani discloses:
[information] including identification of a software component and a corresponding version actually executed by the software at runtime (Figure 4; col. 8 lines 53-60, “The interface 400 may include a summary section 402, describing characteristics of the host device 114 or other aspects of the remote control test environment. For example, as shown in FIG. 4, the summary section 402 may include information for a device type of the host device 114, an OS and OS version for the OS running on the host device, one or more particular apps or other processes currently executing on the host device (e.g., apps under validation), and so forth (emphasis added).”).
Lachwani is within the same field of endeavor as the claimed invention regarding the identification of an executed software component and its corresponding version.
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 Lachwani into the combined teachings of O’Dowd, Hazra, and Singh to include “an analysis unit configured to analyze the execution-related data in conjunction with software artifact metadata referenced during execution of the software, to generate required information including identification of a software component and a corresponding version actually executed by the software at runtime.” The modification would be obvious because one of ordinary skill in the art would be motivated to include information identifying a software component and its corresponding version in order to effectively ensure the correct component is identified as being executed by the software since components with the same name can be distinguished by their versions (Lachwani, col. 8 lines 53-60).
Claim 9 is a method claim corresponding to apparatus Claim 1 and is rejected for the same reasons as given in the rejection of that claim.
Claims 2-4 and 10-12 are rejected under 35 U.S.C. 103 as being unpatentable over O’Dowd in view of Hazra, Singh, and Lachwani as applied to Claims 1 and 9 above, and further in view of US 2006/0036405 (hereinafter “Byrd”).
As per Claim 2, the rejection of Claim 1 is incorporated; and O’Dowd discloses “wherein, when an instrumentation event is triggered by instrumenting a system call or a kernel function in a kernel (col. 60 lines 18-21, “In an embodiment, the compiler is configured to generate instrumentation based on different components, functions, events, or the like identified in the source code of a target program (emphasis added).”; col. 8 lines 46-53, “In an embodiment, the system uses instrumentation in the target program and in the operating system to generate the trace information needed to implement an improved time traveling debugger backend (which may be referred to as “improved backend.”) Trace information generated by the instrumentation can be logged in the memory of the CPU running the computer program until it can be retrieved and interpreted by the debugger (emphasis added).”), the collection unit collects basic information related to execution of a process and software-execution-related data including memory, a system call, and a function related to software execution at a time of execution of software (col. 65 lines 36-47, “In an embodiment, the operating system is modified (for example, its kernel is modified) to record as trace data those actions performed by the operating system on behalf of the target program [execution-related data] that the target program does not have access to, such as (i) calls to operating system services (for example, APIs), (ii) changes performed by the operating system in target program's memory (for example, in response to an operating system service or API), including recording one or more pre-write values, (iii) operating system services performed on behalf of the target computer program [system calls], (iv) task switching, and the like (emphasis added).”; col. 75 lines 60-63, “The plurality of instrumentation instructions can be further configured to record trace data associated with a plurality of function entries and exits for a plurality of functions of the computer program (emphasis added).”),” but the combination of O’Dowd, Hazra, Singh, and Lachwani does not explicitly disclose:
software-execution-related data including a file; and
transfers the basic information and the software-execution-related data to the analysis unit.
However, Byrd discloses:
software-execution-related data including a file (paragraph [0056], “From the file I/O module 204, the monitoring module 216 collects trace data relating to current execution of processes 214 as well as historical operation of processes 214 (emphasis added).”; paragraph [0057], “Trace data collected from the file I/O module 204 may include information such as file name, file directory structure, file size, file owner/creator, file access rights, file creation date, file modification date, file type, file access timestamp, what type of file operation was performed (read, write, update), and the like (emphasis added).”); and
transfers the basic information and the software-execution-related data to the analysis unit (paragraph [0094], “The monitoring module 216 provides the trace data 310 to an analysis module 218 which analyzes the trace data 310 to discover resources affiliated with a business process (emphasis added).”) [Examiner’s Remarks: Note that Byrd discloses a monitoring module (collection unit) providing trace data (software-execution-related data) to an analysis module. One of ordinary skill in the art would readily comprehend that the monitoring module providing the trace data to the analysis module includes transferring the trace data.].
Byrd is also within the same field of endeavor as the claimed invention regarding software data tracing.
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 Byrd into the combined teachings of O’Dowd, Hazra, Singh, and Lachwani to include “software-execution-related data including a file; and transfers the basic information and the software-execution-related data to the analysis unit.” The modification would be obvious because one of ordinary skill in the art would be motivated to collect software-execution-related files to extract more kinds of data during software execution and transfer the collected data to an analysis unit for data integrity and to reduce the analysis unit’s workload so it doesn’t have to retrieve the collected data.
As per Claim 3, the rejection of Claim 2 is incorporated; and O’Dowd further discloses:
wherein the basic information includes at least one of an event occurrence time, a process ID, a thread ID, a process name, a process execution path, parent process information, namespace information, or container information, or a combination thereof (col. 75 lines 66-67 to col. 76 lines 1-4, “The plurality of instrumentation instructions can be further configured to record a plurality of timestamps [event occurrence time] in the trace data, the plurality of timestamps configured to record a time of function entry and a time of function exit of a function of the plurality of functions of the computer program (emphasis added).”).
As per Claim 4, the rejection of Claim 2 is incorporated; and O’Dowd discloses “wherein the analysis unit performs analysis thereon using at least one of decoding, parsing, or filtering, or a combination thereof depending on a format of the basic information and the software-execution-related data, thereby generating desired information (col. 62 lines 66-67 to col. 63 lines 1-2, “In an embodiment, the debugger 210 is configured to decode and process the trace data in order to present the replay and/or reconstruction of the events leading up to the crash or the stoppage of the target program (emphasis added).”; col. 76 lines 29-35, “Reconstructing the state of the target computer system at the particular time can further include starting with a last basic block being executed before halting execution of the at least one task, decoding the trace data in a reverse order of execution of the at least one task, the decoding including determining memory values stored in the memory […] (emphasis added).”; col. 66 lines 18-20, “The events are decoded in reverse time order 616 starting from the halting condition 618, so as to make the most relevant information available to the programmer first (emphasis added).”) [Examiner’s Remarks: Note that O’Dowd discloses the debugger (analysis unit) decoding the trace data to reconstruct the events of the target program execution and that reconstruction includes decoding the trace data in reverse order of execution. One of ordinary skill in the art would readily comprehend that the decoding is based on a format of the data (basic information and software-execution-related data) which is the reverse order of execution in the trace data, so the most relevant (desired) information is made available (generated) first.],” but the combination of O’Dowd, Hazra, Singh, and Lachwani does not explicitly disclose:
the analysis unit receives the basic information and the software-execution-related data from the collection unit.
However, Byrd discloses:
the analysis unit receives the basic information and the software-execution-related data from the collection unit (paragraph [0094], “The monitoring module 216 provides the trace data 310 to an analysis module 218 which analyzes the trace data 310 to discover resources affiliated with a business process (emphasis added).”).
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 Byrd into the combined teachings of O’Dowd, Hazra, Singh, and Lachwani to include “the analysis unit receives the basic information and the software-execution-related data from the collection unit.” The modification would be obvious because one of ordinary skill in the art would be motivated to collect software-execution-related files to extract more kinds of data during software execution and transfer the collected data to an analysis unit for data integrity and to reduce the analysis unit’s workload so it doesn’t have to retrieve the collected data.
Claims 10-12 are method claims corresponding to apparatus Claims 2-4 and are rejected for the same reasons as given in the rejections of those claims.
Claims 5-8 and 13-16 are rejected under 35 U.S.C. 103 as being unpatentable over O’Dowd in view of Hazra, Singh, Lachwani, and Byrd as applied to Claims 4 and 12 above, and further in view of US 12,282,553 (hereinafter “Long”).
As per Claim 5, the rejection of Claim 4 is incorporated; and O’Dowd discloses “the software being executed (col. 62 lines 45-47, “In an embodiment, the trace data logger 207 is configured to collect trace data generated from the execution of the target program 214 (emphasis added).”),” but the combination of O’Dowd, Hazra, Singh, Lachwani, and Byrd does not explicitly disclose:
wherein, in order to identify the software component included in the software being executed, the analysis unit uses a software artifact referred to by the software being executed.
However, Long discloses:
wherein, in order to identify the software component included in the [software build], the analysis unit uses a software artifact referred to by the [software build] (col. 11 lines 53-57, “Build artifact analysis unit 86 may extract one or more software components, e.g., object names, method names, instructions included within methods, constants, text files, and/or meta data, from a build artifact resulting from the software build process of the source code (emphasis added).”) [Examiner’s Remarks: Note that Long discloses an analysis unit extracting software components from a build artifact resulting from a software build process of source code. One of ordinary skill in the art would readily comprehend that the analysis unit is using the build artifact (software artifact) referred to by the software to identify the software components included in the software build in order to extract them.].
Long is within the same field of endeavor as the claimed invention regarding the identification of software components through software artifacts.
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 Long into the combined teachings of O’Dowd, Hazra, Singh, Lachwani, and Byrd to include “wherein, in order to identify the software component included in the software being executed, the analysis unit uses a software artifact referred to by the software being executed.” The modification would be obvious because one of ordinary skill in the art would be motivated to use a software artifact to identify software components included in a software execution to better track/trace the components using artifact metadata.
As per Claim 6, the rejection of Claim 5 is incorporated; and the combination of O’Dowd, Hazra, Singh, Lachwani, and Byrd does not explicitly disclose:
wherein the software artifact is in one of forms including source code, an object file, a Java class file, a Java Archive (JAR) file, an executable file, or a container.
However, Long discloses:
wherein the software artifact is in one of forms including source code, an object file, a Java class file, a Java Archive (JAR) file, an executable file, or a container (col. 4 lines 60-67, “For example, the build artifacts may include container images, distribution packages, binaries (e.g., class files, library files such as dynamic link library (DLL) or shared library (SO) files, and executable files such as WAR, JAR, or EXE files), source code files for interpreted languages (e.g., JavaScript, Python, JSP, ASPX), and associated metadata and resource files that are typically text files (e.g., XML, YAML, etc.) (emphasis added).”).
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 Long into the combined teachings of O’Dowd, Hazra, Singh, Lachwani, and Byrd to include “wherein the software artifact is in one of forms including source code, an object file, a Java class file, a Java Archive (JAR) file, an executable file, or a container.” The modification would be obvious because one of ordinary skill in the art would be motivated to use a software artifact to identify software components included in a software execution to better track/trace the components using artifact metadata.
As per Claim 7, the rejection of Claim 5 is incorporated; and the combination of O’Dowd, Hazra, Singh, Lachwani, and Byrd does not explicitly disclose:
wherein the software artifact includes at least one software component or package and at least one piece of artifact metadata including information about the software artifact.
However, Long discloses:
wherein the software artifact includes at least one software component or package and at least one piece of artifact metadata including information about the software artifact (col. 4 lines 60-67, “For example, the build artifacts may include container images, distribution packages, binaries (e.g., class files, library files such as dynamic link library (DLL) or shared library (SO) files, and executable files such as WAR, JAR, or EXE files), source code files for interpreted languages (e.g., JavaScript, Python, JSP, ASPX), and associated metadata and resource files that are typically text files (e.g., XML, YAML, etc.) (emphasis added).”).
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 Long into the combined teachings of O’Dowd, Hazra, Singh, Lachwani, and Byrd to include “wherein the software artifact includes at least one software component or package and at least one piece of artifact metadata including information about the software artifact.” The modification would be obvious because one of ordinary skill in the art would be motivated to use a software artifact to identify software components included in a software execution to better track/trace the components using artifact metadata.
As per Claim 8, the rejection of Claim 7 is incorporated; and the combination of O’Dowd, Hazra, Singh, Lachwani, and Byrd does not explicitly disclose:
wherein the analysis unit acquires component information from the software artifact or extracts and analyzes metadata including the component information.
However, Long discloses:
wherein the analysis unit acquires component information from the software artifact or extracts and analyzes metadata including the component information (Figure 5: 130; col. 11 lines 53-57, “Build artifact analysis unit 86 may extract one or more software components, e.g., object names, method names, instructions included within methods, constants, text files, and/or meta data, from a build artifact resulting from the software build process of the source code (emphasis added).”) [Examiner’s Remarks: Note that Long discloses an analysis unit extracting software components from a build artifact. One of ordinary skill in the art would readily comprehend that the analysis unit acquired component information from the build artifact by extracting it.].
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 Long into the combined teachings of O’Dowd, Hazra, Singh, Lachwani, and Byrd to include “wherein the analysis unit acquires component information from the software artifact or extracts and analyzes metadata including the component information.” The modification would be obvious because one of ordinary skill in the art would be motivated to use a software artifact to identify software components included in a software execution to better track/trace the components using artifact metadata.
Claims 13-16 are method claims corresponding to apparatus Claims 5-8 and are rejected for the same reasons as given in the rejections of those claims.
Response to Arguments
Applicant’s arguments filed on February 23, 2026 have been fully considered, but they are not
persuasive.
In the Remarks, Applicant’s arguments under CLAIM REJECTIONS -- 35 U.S.C. § 101 are moot because amended Claims 1 and 9 overcome the 35 USC § 101 rejection.
In the Remarks, Applicant argues:
O'Dowd is directed to a debugger that replays or reconstructs execution events leading to a program crash. O'Dowd discloses an analysis based on post-execution trace logs, reconstruction of execution flows, memory states, and variable changes.
In contrast, the presently claimed embodiment expressly does not replay or reconstruct execution events, relies on transient execution-related data that exists only during runtime, and correlates such runtime data with software artifact metadata referenced during execution to identify which software components and versions are actually executed. This feature is not disclosed in O'Dowd.
Accordingly, O'Dowd cannot properly be relied upon for disclosing the above combination of features.
Examiner’s response:
Applicant’s arguments with respect to Claims 1 and 9 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
In the Remarks, Applicant argues:
The Office action further relies on Long to supply the limitation of using a software artifact to identify software components. However, Long operates in a fundamentally different technical context since Long is directed to build-time analysis.
Specifically, Long analyzes build artifacts generated during a software build process to identify components included in a software build, and validate build integrity and supply-chain security. The software artifact in Long is a build-time artifact, and analyzed independently of actual execution.
In contrast, amended claim 1 recites software artifact metadata that is referenced during execution, not during build, correlated with kernel-level runtime execution-related data, and used to identify software components and corresponding versions actually executed at runtime. This runtime-focused, execution-dependent correlation is neither taught nor suggested by Long.
Examiner’s response:
In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). Specifically, the combination of O’Dowd, Hazra, Singh, Lachwani, Byrd, and Long discloses the claim limitation of “wherein, in order to identify the software component included in the software being executed, the analysis unit uses a software artifact referred to by the software being executed.” An excerpt from the 35 USC § 103 rejection of Claim 5 provided herein is provided below to highlight this point:
<<>> + <<>> + <<>> + <<>> + <<>> + <<>> + <<>> + <<>>
As per Claim 5, the rejection of Claim 4 is incorporated; and O’Dowd discloses “the software being executed (col. 62 lines 45-47, “In an embodiment, the trace data logger 207 is configured to collect trace data generated from the execution of the target program 214 (emphasis added).”),” but the combination of O’Dowd, Hazra, Singh, Lachwani, and Byrd does not explicitly disclose:
wherein, in order to identify the software component included in the software being executed, the analysis unit uses a software artifact referred to by the software being executed.
However, Long discloses:
wherein, in order to identify the software component included in the [software build], the analysis unit uses a software artifact referred to by the [software build] (col. 11 lines 53-57, “Build artifact analysis unit 86 may extract one or more software components, e.g., object names, method names, instructions included within methods, constants, text files, and/or meta data, from a build artifact resulting from the software build process of the source code (emphasis added).”) [Examiner’s Remarks: Note that Long discloses an analysis unit extracting software components from a build artifact resulting from a software build process of source code. One of ordinary skill in the art would readily comprehend that the analysis unit is using the build artifact (software artifact) referred to by the software to identify the software components included in the software build in order to extract them.].
Long is within the same field of endeavor as the claimed invention regarding the identification of software components through software artifacts.
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 Long into the combined teachings of O’Dowd, Hazra, Singh, Lachwani, and Byrd to include “wherein, in order to identify the software component included in the software being executed, the analysis unit uses a software artifact referred to by the software being executed.” The modification would be obvious because one of ordinary skill in the art would be motivated to use a software artifact to identify software components included in a software execution to better track/trace the components using artifact metadata.
<<>> + <<>> + <<>> + <<>> + <<>> + <<>> + <<>> + <<>>
Moreover, the software artifact metadata that is referenced during execution, correlated with kernel-level runtime execution-related data, and used to identify software components and corresponding versions actually executed at runtime as recited in amended claim 1 is taught by the combination of O’Dowd, Hazra, Singh, Lachwani, and Byrd as shown in the 35 USC § 103 rejection of Claim 1 provided herein (pages 7-13) which is incorporated in the rejection of Claim 5 provided herein.
In the Remarks, Applicant argues:
As such, there is no motivation to combine Long with O'Dowd. Specifically, O'Dowd is directed to post-execution debugging and reconstruction of execution events leading to a program failure, while Long is directed to static, build-time analysis of build artifacts to identify components included in a software build. O'Dowd neither recognizes nor addresses the problem of identifying software components and versions actually executed at runtime, and therefore provides no motivation to incorporate Long's build-time artifact analysis. That is, O'Dowd already achieves its debugging objective without identifying software components or versions. Therefore, since Long's teachings do not contribute to O'Dowd's debugging objectives, a person of ordinary skill in the art would have no reason to incorporate Long's build-time artifact analysis. Any such combination would be based on impermissible hindsight.
Examiner’s response:
In response to applicant’s argument that there is no teaching, suggestion, or motivation to combine the references, the examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007). In this case, a person of ordinary skill in the art would be motivated to combine the teaching of Long into the combined teachings of O’Dowd, Hazra, Singh, Lachwani, and Byrd in order to identify software components included in a software execution to better track and trace components using artifact metadata. Specifically, this is helpful within O’Dowd’s reconstruction of execution events in order to effectively trace and reconstruct events linked to identified components executed by the target program and allow users to identify components while debugging.
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 Feven H. Huruy whose telephone number is (571) 272-3826. The examiner can normally be reached Mon-Fri. 7:30am-3:45pm.
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, Wei Mui can be reached at (571) 272-3708. 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.
/F.H.H./Examiner, Art Unit 2191 /WEI Y MUI/Supervisory Patent Examiner, Art Unit 2191
Prosecution Insights