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 .
Claims 1-20 are presented for examination.
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.
Claim(s) 1, 2, 5, 9-12, 15 and 19-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Gagliardi (US 9,798,557 B2) in view of Koren (US 8,745,598 B2) further in view of Lind (US 2009/0276483 A1) and Odenwelder (US 8,418,147 B1).
Regarding Claim 1, Gagliardi (US 9,798,557 B2) teaches
A method for dynamically updating classes in a running application, a method comprising:
identifying an application running within a virtual machine (VM); (Col. 2: ln 5-27, "One embodiment comprises running the Agent for the Application while the Application is also running. The Agent is associated with an identified source of code for the Agent… One embodiment comprises running a java application in a java virtual machine") Examiner Comments: Gagliardi teaches identifying the running application in a JVM (VM) to attach and run the agent concurrently, as this is necessary to update classes without stopping the application;
generating, within the application, a patcher thread for processing patches, [wherein the patcher thread is set as a daemon thread] and is distinct from a listener thread; (Col. 6: ln 28-65, "Bootstrap Classloader 342 will access the class files from agent.jar 340 and present the class files to Class File Transformer 344. Class File Transformer 344 will replace the class files from agent.jar with code (class files) from the updated agent.jar 350 and return the updated class files 346 to Bootstrap Classloader 342, which will present the updated code to the Java Virtual Machine.") Examiner Comments: Gagliardi 's agent management uses background processes for updates, implying generation of a separate thread for patching distinct from any listener to avoid interference with the main application;
generating a notification that a live patching facility is set up using a system property in the VM; (Col. 6: ln 28-65, "Bootstrap Classloader 342 will access the class files from agent.jar 340 and present the class files to Class File Transformer 344. Class File Transformer 344 will replace the class files from agent.jar with code (class files) from the updated agent.jar 350 and return the updated class files 346 to Bootstrap Classloader 342, which will present the updated code to the Java Virtual Machine.") ") Examiner Comments: Gagliardi teaches generating a notification of live patching setup using VM system properties, as the bootstrap loader's handling of updated files signals the facility is active. The act of “presenting” is interpreted to the claimed notification;
executing, by the patcher thread, the task to replace the existing version of the class with the updated version. (Col. 6: ln 28-65, "Bootstrap Classloader 342 will access the class files from agent.jar 340 and present the class files to Class File Transformer 344. Class File Transformer 344 will replace the class files from agent.jar with code (class files) from the updated agent.jar 350 and return the updated class files 346 to Bootstrap Classloader 342, which will present the updated code to the Java Virtual Machine. When Bootstrap Classloader 342 receives the updated class files, it thinks its receiving an instrumented version of the original Agent class files, rather than a replaced version. In this manner, the class files from the class path C:\agentjar are replaced with class files from a file outside of the class path") Examiner Comments: Gagliardi teaches executing the replacement using the patcher thread, as the instrumentation replaces the class at runtime.
Gagliardi did not specifically teach
wherein the patcher thread is set as a daemon thread
installing a shutdown hook in the VM to signal the patcher thread to stop operation and release resources during termination of the application;
instantiating, within the application, a patcher class using a singleton pattern to prevent the patcher class from being instantiated multiple times
detecting, via the patcher thread, a task to replace an existing version of a class with an updated version of the class at runtime by periodically scanning, using a polling technique, a tasks directory for new class files and finding the updated version of the class.
However, Koren (US 8,745,598 B2) teaches
instantiating, within the application, a patcher class using a singleton pattern to prevent the patcher class from being instantiated multiple times; (Col. 4: ln 63-67, "This is a JVM internal class, implemented very much like a singleton. It holds a single static instance reachable by a public static getter.") Examiner Comments: Koren teaches using a singleton pattern for a JVM internal class to ensure a single instance, preventing multiple instantiations, applicable to managing patcher classes in runtime environments.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Gagliardi ’s teaching into Koren’s in order to ensure consistent and controlled access to shared resources like class loaders in JVM, preventing conflicts and ensuring thread-safety during runtime operations by loading a first class in an object oriented environment which is manipulated by loading a second class in the object-oriented environment and making the first class invisible to the second class (Koren [Summary]).
Gagliardi and Koren did not specifically teach
wherein the patcher thread is set as a daemon thread
detecting, via the patcher thread, a task to replace an existing version of a class with an updated version of the class at runtime by periodically scanning, using a polling technique, a tasks directory for new class files and finding the updated version of the class.
However, Lind (US 2009/0276483 A1) teaches
wherein the patcher thread is set as a daemon thread; (Para. [0181], "The example below shows how a thread can be marked as a daemon thread. Daemon threads allow the JVM to exit even if they are running.") Examiner Comments: Lind directly teaches setting a thread as daemon in JVM to allow application termination without blocking, suitable for background patching threads.
installing a shutdown hook in the VM to signal the patcher thread to stop operation and release resources during termination of the application (Para. [0180], " The example below shows the use of a JVM shutdown hook to coordinate shutdown of user threads)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Gagliardi and Koren’s teaching into Lind’s in order to enable the JVM to terminate gracefully even if background threads like patchers are running, preventing hangs during application shutdown by having a set of computer program instructions e.g JAVA (RTM: object-oriented programming language) program instructions (Lind [Summary]).
Gagliardi, Koren and Lind did not specifically teach
detecting, via the patcher thread, a task to replace an existing version of a class with an updated version of the class at runtime by periodically scanning, using a polling technique, a tasks directory for new class files and finding the updated version of the class.
However, Odenwelder (US 8,418,147 B1) teaches
detecting, via the patcher thread, a task to replace an existing version of a class with an updated version of the class at runtime by periodically scanning, using a polling technique, a tasks directory for new class files and finding the updated version of the class; (Col 11: ln 45 -Col. 12: ln 43, " the CI server 306 periodically queries the SCM server 304 and performs resulting builds at regular intervals (e.g., daily). These queries and resulting builds may be performed automatically … the CI server 306 queries (320) the SCM server 304 as to whether the SCM server 304 has received any code changes since a previous query ") Examiner Comments: Odenwelder's queries for code changes is interpreted to the claimed polling technique, which detects updated class files in a directory, applicable to runtime detection in a patching system.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Gagliardi , Koren and Lind’s teaching into Odenwelder’s in order to enable automated, real-time detection of updates without requiring manual intervention or complex event listeners, thereby enhancing the system's responsiveness and reducing latency in applying patches by receiving successive code change for software product, the build runs of software product are generated such that build runs correspond to successive code changes respectively (Odenwelder [Summary]).
Regarding Claim 2, Gagliardi, Koren, Lind and Odenwelder teach
The method of Claim 1, wherein the VM is a Java Virtual Machine (JVM). (Gagliardi, Col. 2: ln 5-27, "One embodiment comprises running a Java Application in a Java Virtual Machine, running an Agent in the Java Virtual Machine while the Application is running") Examiner Comments: Gagliardi explicitly teaches the VM as a JVM, as the entire system uses Java Instrumentation API for class updates.
Regarding Claim 5, Gagliardi, Koren, Lind and Odenwelder teach
The method of Claim 2, wherein generating, within the application, the patcher thread comprises: instantiating the patcher thread during execution of an agentmain routine of a live patching Java agent (Gagliradi, Col. 7: ln 24-33, "managing the versions of an Agent that is implemented using the -javaagent option of the Java Instrumentation API") Examiner Comments: Gagliardi 's agent uses javaagent option (agentmain) for runtime attachment.
Gagliardi and Koren did not specifically teach
and setting a daemon property of the patcher thread before a start routine is invoked to allow for the termination of the application.
However, Lind teaches
and setting a daemon property of the patcher thread before a start routine is invoked to allow for the termination of the application (Para 0181, The example below shows how a thread can be marked as a daemon thread. Daemon threads allow the JVM to exit even if they are running).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Gagliardi and Koren’s teaching into Lind’s in order to enable the JVM to terminate gracefully even if background threads like patchers are running, preventing hangs during application shutdown by having a set of computer program instructions e.g JAVA (RTM: object-oriented programming language) program instructions (Lind [Summary]).
Regarding Claim 9, Gagliardi, Koren, Lind and Odenwelder teach
The method of Claim 1.
Gagliardi and Koren did not teach
further teach further comprising registering the shutdown hook in a run routine of the patcher thread to ensure execution upon the termination of the application.
However, Lind teaches
further teach further comprising registering the shutdown hook in a run routine of the patcher thread to ensure execution upon the termination of the application (Para 175, We now describe managing threads. In particular, in order to cleanly shutdown the JVM, all user created threads should exit when main returns. The following approaches may be used to manage user threads to ensure a clean JVM shutdown; Para 0177, Use a JVM shutdown hook to determine when to exit user threads; Para 0180, The example below shows the use of a JVM shutdown hook to coordinate shutdown of user threads).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Gagliardi and Koren’s teaching into Lind’s in order to enable the JVM to terminate gracefully even if background threads like patchers are running, preventing hangs during application shutdown by having a set of computer program instructions e.g JAVA (RTM: object-oriented programming language) program instructions (Lind [Summary]).
Regarding Claim 10, Gagliardi, Koren, Lind and Odenwelder teach
The method of Claim 1, wherein generating the notification comprises setting a designated system property in a system properties table of the VM. (Gagliradi, Col. 6: ln 8-65, "Bootstrap Classloader 342 receives the updated class files") Examiner Comments: Gagliardi teaches setting system properties for notification, as loader updates signal setup via VM properties.
Regarding Claim 11, is a system claim corresponding to the method claim above (Claim 1) and, therefore, is rejected for the same reasons set forth in the rejection of claim 1.
Regarding Claim 12, is a system claim corresponding to the method claim above (Claim 2) and, therefore, is rejected for the same reasons set forth in the rejection of claim 2.
Regarding Claim 15, is a system claim corresponding to the method claim above (Claim 5) and, therefore, is rejected for the same reasons set forth in the rejection of claim 5.
Regarding Claim 19, is a system claim corresponding to the method claim above (Claim 9) and, therefore, is rejected for the same reasons set forth in the rejection of claim 9.
Regarding Claim 20, is a computer readable medium claim corresponding to the method claim above (Claim 1) and, therefore, is rejected for the same reasons set forth in the rejection of claim 1.
Claim(s) 3-4 and 13-14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Gagliardi (US 9,798,557 B2) in view of Koren (US 8,745,598 B2), Lind (US 2009/0276483 A1) and Odenwelder (US 8,418,147 B1) further in view of CERT (“LCK00-J. Use private final lock objects…”) and Fox (“When is a Singleton not a Singleton?”).
Regarding Claim 3, Gagliardi, Koren, Lind and Odenwelder teach
The method of Claim 2.
Gagliardi, Koren, Lind and Odenwelder did not specifically teach
further comprising managing synchronization to control access to the patcher class using a complementary field and a guarded field, wherein the complementary field comprises an object used for a monitor that is set to guard access to the guarded field, and wherein the guarded field comprises null as a default value.
However, CERT teaches
further comprising managing synchronization to control access to the patcher class using a complementary field and a guarded field, wherein the complementary field comprises an object used for a monitor that is set to guard access to the guarded field, and wherein the guarded field [comprises null as a default value]. (Second paragraph, One technique for preventing this vulnerability is the private lock object idiom [Bloch 2001]. This idiom uses the intrinsic lock associated with the instance of a private final java.lang.Object declared within the class instead of the intrinsic lock of the object itself.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Gagliardi , Koren, Lind and Odenwelder’s teaching into CERT’s in order to apply the CERT-recommended private lock object idiom to the singleton patcher class because Java agents routinely run in potentially hostile code environments, and CERT explicitly teaches this pattern to avoid denial-of-service attacks that are possible when locking on the public Class object.
Gagliardi, Koren, Lind, Odenwelder and CERT did not specifically teach
comprises null as a default value.
However, Fox teaches
comprises null as a default value (see Fox example with “if (_instance==null)”).
Examiner Comments: The “complementary field” is the private final java.lang.Object used solely as a monitor lock; the “guarded field” is the static singleton instance field that defaults to null — this is the exact standard Java idiom recommended by Oracle/SEI CERT to prevent DoS attacks when synchronizing in untrusted environments (such as a patching agent running inside a target application that may contain malicious code).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Gagliardi , Koren, Lind, Odenwelder and CERT’s teaching into Fox’s in order to apply the well-known private lock object idiom of CERT LCK00-J to the patcher singleton because Java agents often run in environments where untrusted code is present (the target application being patched), and using a private lock object prevents denial-of-service attacks via lock contention that are possible when locking on the class object itself (as shown in Fox); additionally, providing the alternative of using the class object (via direct .class or via reflection with Class.forName when the class reference is not directly available or to support dynamic loading) as an explicit "instead" alternative gives flexibility while maintaining compatibility with the common pattern shown in Fox, with no unexpected results (both are standard idioms yielding predictable thread-safety).
Regarding Claim 4, Gagliardi, Koren, Lind, Odenwelder, CERT and Fox teach
The method of Claim 3.
Gagliardi, Koren, Lind, and Odenwelder did not specifically teach
wherein the object comprises a java.lang.Object class, and wherein instantiation of the patcher class is managed through the complementary field for synchronization purposes, further comprising: using a reflection object of the patcher class for synchronization instead of the complementary field.
However, CERT teaches
wherein the object comprises a java.lang.Object class, and wherein instantiation of the patcher class is managed through the complementary field for synchronization purposes (Second paragraph, One technique for preventing this vulnerability is the private lock object idiom [Bloch 2001]. This idiom uses the intrinsic lock associated with the instance of a private final java.lang.Object declared within the class instead of the intrinsic lock of the object itself).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Gagliardi , Koren, Lind and Odenwelder’s teaching into CERT’s in order to apply the CERT-recommended private lock object idiom to the singleton patcher class because Java agents routinely run in potentially hostile code environments, and CERT explicitly teaches this pattern to avoid denial-of-service attacks that are possible when locking on the public Class object.
Gagliardi, Koren, Lind, Odenwelder and CERT did not specifically teach
further comprising: using a reflection object of the patcher class for synchronization instead of the complementary field
However, Fox teaches
further comprising: using a reflection object of the patcher class for synchronization instead of the complementary field. (see Fox example with the common alternative using the class object itself as the monitor: “synchronized (MySingleton.class) { if (_instance==null) { _instance = new MySingleton(); } }”).
Examiner Comments: Fox’s MySingleton.class is a java.lang.Class instance (the reflection object of the singleton class) used directly as the monitor instead of a separate private lock object — exactly the claimed alternative. CERT itself acknowledges that locking on the Class object is common but warns against it in untrusted code, thereby teaching both approaches and the reason to choose one over the other.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Gagliardi , Koren, Lind, Odenwelder and CERT’s teaching into Fox’s in order to apply the well-known private lock object idiom of CERT LCK00-J to the patcher singleton because Java agents often run in environments where untrusted code is present (the target application being patched), and using a private lock object prevents denial-of-service attacks via lock contention that are possible when locking on the class object itself (as shown in Fox); additionally, providing the alternative of using the class object (via direct .class or via reflection with Class.forName when the class reference is not directly available or to support dynamic loading) as an explicit "instead" alternative gives flexibility while maintaining compatibility with the common pattern shown in Fox, with no unexpected results (both are standard idioms yielding predictable thread-safety).
Regarding Claim 13, is a system claim corresponding to the method claim above (Claim 3) and, therefore, is rejected for the same reasons set forth in the rejection of claim 3.
Regarding Claim 14, is a system claim corresponding to the method claim above (Claim 4) and, therefore, is rejected for the same reasons set forth in the rejection of claim 4.
Claim(s) 6-7 and 16-17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Gagliardi (US 9,798,557 B2) in view of Koren (US 8,745,598 B2), Lind (US 2009/0276483 A1) and Odenwelder (US 8,418,147 B1) further in view of JDK (“Package java.lang.instrument”).
Regarding Claim 6, Gagliardi, Koren, Lind and Odenwelder teach
The method of Claim 5, wherein subsequent to generating the notification, the agentmain routine receives an options string and an instance of a java.lang.instrument.Instrumentation class as arguments, wherein the options string includes a file system path to the task directory comprising updated class files. (Gagliardi, Col. 4: ln 35-40, "The Agent is associated with an identified source of code for the Agent.")
Gagliardi, Koren, Lind and Odenwelder do not teach the exact phrase “options string includes a file system path to the task directory”, but this limitation is directly taught by the standard JDK Instrumentation specification that Gagliardi necessarily relies upon.
The JDK Instrumentation Spec teaches the exact signature and mechanism: “The agent class may also have an agentmain method for use when the agent is started after VM startup … public static void agentmain(String agentArgs, Instrumentation inst)
The agent is passed its agent options via the agentArgs parameter. The agent options are passed as a single string, any additional parsing must be performed by the agent itself.”
Examiner Comments: “the agentmain routine receives an options string and an instance of a java.lang.instrument.Instrumentation class as arguments” → directly taught by the JDK Instrumentation Spec’s agentmain(String agentArgs, Instrumentation inst) signature that every dynamic Java agent (including Gagliardi’s) must use. “the options string includes a file system path to the task directory comprising updated class files” → the JDK Instrumentation Spec teaches that the entire content and format of the options string is defined by the agent implementer and that parsing is performed by the agent itself; when the agent needs to know a directory containing updated class files (exactly Gagliardi’s case, where updated classes come from an external file location / directory), the standard and customary way to supply that directory path to the running agent is to include it in the options string passed at attach time (via VirtualMachine.loadAgent(jarPath, optionsString)). This is the only mechanism the JDK provides for passing configuration to a dynamically attached agent.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Gagliardi, Koren, Lind and Odenwelder’s teaching into JDK’s in order to implement Gagliardi’s live-patching agent using the exact standard JDK agentmain signature and to pass the file system path to the directory containing updated class files in the options string, because (1) Gagliardi explicitly requires the agent to know an external source/directory of updated classes, (2) the JDK Instrumentation Spec (which Gagliardi necessarily follows) provides the options string as the sole standard mechanism for passing arbitrary configuration data to a dynamically attached agent.
Regarding Claim 7, Gagliardi, Koren, Lind, Odenwelder and JDK teach
The method of Claim 6.
Gagliardi, Koren and Lind did not specifically teach
further comprising: determining an eligibility of class files for update based on modification timestamps and a registry of applied class files.
However, Odenwelder teaches
further comprising: determining an eligibility of class files for update based on modification timestamps and a registry of applied class files (Col. 12: ln 4-43, "at time t 0 310, the CI server 306 queries (320) the SCM server 304 as to whether the SCM server 304 has received any code changes since a previous query … At a subsequent time t 1 312, a developer at a developer system 302 commits a code change (324) to the SCM server 304. In committing this code change, the developer specifies work items affected by the code change. For example, if the code change attempts to at least partially implement a feature or fix a defect, the developer specifies the feature or defect when committing the code change … At a subsequent time t 2 314, the CI server 306 again queries (326) the SCM server 304 as to whether the SCM server 304 has received any code changes since the previous query 320. Because the SCM server 304 received the code change 324, it responds affirmatively (328) and provides the updated code to the CI server 306 along with the specified work items affected by the code change") Examiner Comments: Odenwelder teaches periodic scanning (polling) of directories for new files and determining eligibility using metadata registry with timestamps.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Gagliardi , Koren and Lind’s teaching into Odenwelder’s in order to enable automated, real-time detection of updates without requiring manual intervention or complex event listeners, thereby enhancing the system's responsiveness and reducing latency in applying patches by receiving successive code change for software product, the build runs of software product are generated such that build runs correspond to successive code changes respectively (Odenwelder [Summary]).
Regarding Claim 16, is a system claim corresponding to the method claim above (Claim 6) and, therefore, is rejected for the same reasons set forth in the rejection of claim 6.
Regarding Claim 17, is a system claim corresponding to the method claim above (Claim 7) and, therefore, is rejected for the same reasons set forth in the rejection of claim 7.
Claim(s) 8 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Gagliardi (US 9,798,557 B2) in view of Koren (US 8,745,598 B2), Lind (US 2009/0276483 A1) and Odenwelder (US 8,418,147 B1) further in view of Rasmussen (US 9141415).
Regarding Claim 8, Gagliardi, Koren, Lind and Odenwelder teach
The method of Claim 2.
Gagliardi, Koren, Lind and Odenwelder did not specifically teach
further comprising executing a redefineClasses routine on an instrumentation object to apply updates to loaded classes and only allowing changes to routine bodies while keeping externally visible signatures constant.
However, Rasmussen (US 9141415) teaches
further comprising executing a redefineClasses routine on an instrumentation object to apply updates to loaded classes and only allowing changes to routine bodies while keeping externally visible signatures constant. (Col. 2: ln 1-15, "The redefinition may change method bodies, the constant pool and attributes. The redefinition must not add, remove or rename fields or methods, change the signatures of methods, or change inheritance.") Examiner Comments: Rasmussen explicitly teaches using redefineClasses to update method bodies while keeping signatures constant, as per JVM limitations.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Gagliardi, Koren, Lind and Odenwelder’s teaching into Rasmussen’s in order to comply with JVM constraints during runtime updates, maintaining compatibility and stability by starting a new java (RTM: Object oriented programming language) virtual machines instance, and a set of arguments is passed to the new instance as passed to an actively running Java (RTM) upon initial program startup.
Regarding Claim 18, is a system claim corresponding to the method claim above (Claim 8) and, therefore, is rejected for the same reasons set forth in the rejection of claim 8.
Response to Arguments
Applicant argues: "Gagliardi discloses a system for updating a Java Agent where an 'Update Manager instructs Transformer to update and identifies updated Agent.jar' ... Gagliardi's mechanism is fundamentally different. Gagliardi relies on an Update Manager that explicitly instructs the Transformer to update (a 'push' or event-driven model) ... Gagliardi does not teach a patcher thread that sits in a loop periodically scanning a specific tasks directory on the file system to 'pull' or detect new class files as they appear. The specific claimed mechanism—using a polling technique on a directory to detect new individual class files—is missing from Gagliardi."
Examiner respectfully disagrees. Gagliardi teaches the core runtime replacement of classes via an agent in a running JVM (Col. 6, lines 40-50: replacement of class files from an external location outside the original class path). The amendment adding "periodically scanning, using a polling technique" to independent claims 1, 11, and 20 is noted and entered. However, when combined with Odenwelder, the references together teach the claimed polling detection. Odenwelder explicitly discloses periodic polling to detect updates (Col. 11, line 45-Col 12. 43: the CI server periodically queries for changes at subsequent times t0, t1, t2, and responds to new code when detected). One of ordinary skill in the Java agent art would have been motivated to adapt Odenwelder’s known periodic polling technique to monitor a local tasks directory for new .class files in Gagliardi’s system, because Gagliardi already requires an external source of updated class files and a simple file-drop mechanism (local directory polling) is a predictable, well-known way to achieve automatic detection without manual instruction or network dependency. The combination yields the claimed "pull"-style polling on a tasks directory with no unexpected results.
Applicant argues: "Odenwelder teaches a CI Server querying an SCM Server, not a thread scanning a directory ... This is a network-based request between two distinct server applications to check for source code commits ... It is not a file system operation where a thread scans a local 'tasks directory' for 'new class files' ... Odenwelder scans for 'code changes' (i.e., source code commits) ... not compiled 'class files' ready for runtime injection ... The 'polling' in Odenwelder is a query to a version control system's database or API ... fundamentally different from the claimed 'scanning... a tasks directory'."
Examiner respectfully disagrees. Odenwelder teaches the polling technique itself (periodic checking for new/updated code artifacts and acting on detection). The specific adaptation to a local tasks directory containing compiled .class files is an obvious and predictable variation in view of Gagliardi, which already relies on external class files placed outside the standard class path for runtime replacement. A person of ordinary skill would recognize that once the need for automatic detection of updates is identified (as in Gagliardi’s agent), applying a known polling technique to the exact location where the updated class files are dropped (a local directory) is a straightforward implementation choice. The distinction between source commits and compiled class files is not a patentable difference here, as both represent "updated code" that triggers an action, and the claimed invention does not require any special processing of the class files beyond detection and replacement (which Gagliardi already performs).
Applicant argues: "There is no motivation for a person of ordinary skill in the art (POSITA) to combine the build-management teachings of Odenwelder with the runtime agent of Gagliardi ... Disparate Problems and Fields of Endeavor ... Incompatibility of Mechanisms (Teaching Away) ... Hindsight Bias."
Examiner respectfully disagrees. A person of ordinary skill in the Java/JVM instrumentation art, seeking to improve Gagliardi’s agent by making class updates fully automatic rather than dependent on an Update Manager instruction, would naturally look to known polling techniques in the broader software update and continuous integration field (Odenwelder). The motivation is explicit: Gagliardi requires updated class files from an external location, but does not disclose how they are detected automatically; Odenwelder solves the problem of automatically detecting new code artifacts and acting on them. Both references are in the same field of (automated software updating in Java environments), and the combination is a predictable improvement that simplifies deployment (simple file drop into a watched directory) without introducing complexity or teaching away. The Examiner’s combination is not based on hindsight but on the common knowledge that polling is a standard, routine technique for file-based or change-based detection, as evidenced by its widespread use in hot-deployment and agent systems. The applicant’s characterization of the fields as wholly disparate ignores that both address the core need for timely detection of code changes in Java-based systems.
Applicant argues: "Gagliardi fails to teach the 'Shutdown Hook' for the Patcher Thread ... Lind is directed to a 'Java Virtual Machine Having Integrated Transaction Management System.' ... There is no motivation to combine the heavy-weight transaction management teachings of Lind with the lightweight, runtime instrumentation agent of Gagliardi."
Examiner respectfully disagrees. Lind teaches the use of JVM shutdown hooks to coordinate the orderly termination of background/user threads (Para [0180]-[0181]: explicit example of registering a shutdown hook to manage thread lifecycle and ensure clean JVM exit). Applying this known JVM mechanism to the patcher thread in Gagliardi (a background thread that must be stopped and cleaned up on application termination) is a routine and obvious improvement to ensure resource release, exactly as claimed. One of ordinary skill would have been motivated to use Lind’s shutdown hook technique because Gagliardi’s agent runs as a long-lived background process in the target JVM, and any such process requires proper shutdown handling to avoid resource leaks, a well-known problem in JVM agent design. The fact that Lind arises in a transaction context does not teach away; shutdown hooks are a general JVM facility applicable to any thread, including lightweight agents.
Applicant argues: "The Office’s reliance on four distinct references from disparate sub-fields of software engineering highlights the lack of a coherent motivation to combine ... This 'pick-and-choose' approach is the hallmark of impermissible hindsight reconstruction."
Examiner respectfully disagrees. The references are not disparate; all are directed to Java/JVM environments and address related problems of code updating, thread management, and automated detection in software systems. Gagliardi provides the base runtime agent, Peled/Koren the singleton pattern for safe agent instantiation, Villasenor/Lind the daemon thread and shutdown hook for clean lifecycle, Odenwelder the polling detection technique, and the JDK spec the agentmain/options mechanism. The motivation to combine is clear and found in the references themselves: improving automated, non-disruptive class updating in a running JVM. The number of references does not render the combination hindsight when each supplies a known, complementary element to solve a specific deficiency in the primary reference (Gagliardi). The combination produces a predictable, improved live-patching facility without unexpected results.
Conclusion
THIS ACTION IS MADE FINAL. 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 AMIR SOLTANZADEH whose telephone number is (571)272-3451. The examiner can normally be reached M-F, 9am - 5pm ET.
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.
/AMIR SOLTANZADEH/Examiner, Art Unit 2191 /WEI Y MUI/Supervisory Patent Examiner, Art Unit 2191