DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response to the RCE filed on 31 December 2025, for application number 17/932,872. Claims 1-5, 7, 10, 12-20, and 22-25 have been considered. Claims 1, 15, and 20 are independent claims. Claims 1, 10, 15, 19, and 20 are amended. Claims 8, 9, 11, and 21 are cancelled. Claims 22-25 are new.
This action is made Non-Final.
Response to Remarks
Claim Rejections – 35 U.S.C. 103
Applicant’s prior art arguments have been fully considered but they are not persuasive.
Applicant argues that the cited references do not teach the newly amended claims which specify the runtime sate of the component to be serviced. Examiner respectfully disagrees. Oesterreicher teaches operations currently being performed by the component to be serviced, as further detailed below.
The foregoing applies to all independent claims and their dependent claims.
Prior Art
Listed herein below are the prior art references relied upon in this Office Action:
Lu et al. (US Patent Application Publication US 20230061270 A1), referred to as Lu herein.
Ye et al. (Chinese Patent Application Publication CN 108427571 A), referred to as Ye herein.
Oesterreicher (US 2004/0197073 A1) hereinafter known as Oesterreicher.
Claim Rejections - 35 USC § 103
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 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-5, 7, 10-13, 15-17, and 19-24 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lu in view of Oesterreicher.
Regarding independent claim 1, Lu discloses “A system comprising:
a processing system (Lu, at ¶ [0005], a processor.); and
memory coupled to the processing system, the memory comprising computer executable instructions that, when executed by the processing system, perform operations comprising (id. at ¶¶ [0005]-[0006], a memory and a computer readable storage medium.):
loading a replacement component for a user mode process (Examiner notes that a dynamic link library (DLL) of Lu corresponds to a component. id. at ¶ [0030], updating a DLL reloading description file with information of the updated DLL.), the user mode process comprising a component to be serviced and dependent components of the component to be serviced (id. at ¶ [0029], a DLL ancestor table is also updated to record the dependency relationships among different DLLs.);
validating software dependencies of the replacement component are satisfied (id. at ¶ [0029], a DLL dependency table is used to store calling relationships between applications and DLLs, during the application runtime when a runtime environment resolves a DLL, if the runtime environment detects that a program referenced the DLL the DLL dependency table is updated to record the program and DLLs dependency relationship for either explicit DLL referencing or implicit DLL referencing.);
...
suspending the component to be serviced and the dependent components, ... (id. at ¶ [0030], updating a DLL reload status table to include the DLL and set the reloading status to false, next, the method includes identifying all program modules and DLLs that depend on the updated DLL.);
updating the dependent components to reference the replacement component (id. at ¶ [0030], reassigning an application program interface (API) address for a current version of the dynamic library to an API address of the updated version of the dynamic library for each program module that depends on the DLL.);
...
executing the replacement component based on the runtime state of the component to be serviced, wherein executing the replacement component comprises resuming the dependent components components; and ... (id. at ¶ [0036], the DLL dynamic reload routine reloads the updated DLL and obtains the beginning address of the updated DLL. After obtaining the beginning address of the updated DLL, the DLL dynamic reload routine calls a DLL resolve routine for each program module identified.).”
Lu does not explicitly teach but Oesterreicher teaches:
creating a snapshot of a runtime state of the component to be serviced wherein the runtime state of the component to be serviced comprises at least one of: calls sent by the component to be serviced; calls received by the component to be serviced; or operations currently being performed by the component to be serviced (Oesterreicher: Fig. 6 and ¶[0028] and ¶[0076]; Oesterreicher teaches copying value of fields from Object A to Object B. Fig. 4A and ¶[0027], ¶[0033], ¶[0038], and ¶[0058] teaches the object oriented runtime environment which performs operations.)
..., wherein the suspending prevents the component to be serviced and the dependent components from performing operations that alter the runtime state of the component to be serviced or a runtime state of the dependent components (Oesterreicher: Fig. 6 and ¶[0028] and ¶[0075]-¶[0076]; Oesterreicher teaches locking Object A, which prevents it from changing.)
copying the snapshot to the replacement component by applying the runtime state of the component to be serviced to the replacement component and (Oesterreicher: Fig. 6 and ¶[0028] and ¶[0076]; Oesterreicher teaches copying value of fields from Object A to Object B.)
... causing the replacement component to execute the at least one of: the class sent by the component to be serviced; the calls received by the component to be serviced; or the operations currently being performed by the component to be serviced. (Oesterreicher: Fig. 6 and ¶[0076]; Oesterreicher teaches restoring services in project B.)
Lu and Oesterreicher are in the same field of endeavor as the present invention, as the references are directed to maintaining service to component dependencies when updating the component. It would have been obvious, before the effective filing date of the claimed invention, to a person of ordinary skill in the art, to combine loading a replacement, validating dependencies, suspending the component, and updating a component as taught in Lu with further creating and transferring a snapshot of the runtime state from the first component to the replacement as taught in Oesterreicher. As such, it would have been obvious to one of ordinary skill in the art to modify the teachings of Lu to include teachings of Oesterreicher, because the combination would allow updating the system without interrupting the functionality, as suggested by Oesterreicher: ¶[0064].
Regarding claim 2, Lu in view of Oesterreicher teaches all the limitation of independent claim 1. Lu further teaches “wherein loading the replacement component comprises: allocating memory for the replacement component; and initializing the replacement component, the initializing providing an initial value to a variable used by the replacement component (Lu, at ¶¶ [0037]-[0038], DLL resolve routine re-calculates the function entry point address and variable address based on the beginning address of the new version of the updated DLL, the DLL resolve routine updates the corresponding record of the function entry point address and variable address of the updated DLL in the writable static area of the DLL which depends on the updated DLL to contain the function entry point address and variable address of the new version of the updated DLL.).”
Regarding claim 3, Lu in view of Oesterreicher teaches all the limitation of independent claim 1. Lu further teaches “wherein: the user mode process further comprises a component that is not dependent on the component to be serviced; and suspending the component to be serviced and the dependent components comprises suspending the component to be serviced and the dependent components without suspending the component that is not dependent on the component to be serviced (Lu, at Figs. 4 and 5, DLL_B’s reload status is false indicates the dynamic library is currently being updated and therefore the DLL should not be reloaded, and Fig. 5 shows some dependent DLLs related to the DLL_B and some DLLs not dependent on the DLL_B, and if the import table of the updated DLL includes a DLL that is in the DLL dependency table which as a reload status of false, the DLL resolve routine calls the DLL dynamic reload routine to trigger reloading the identified DLL, as illustrated in FIG. 6.).”
Regarding claim 4, Lu in view of Oesterreicher teaches all the limitation of independent claim 1. Lu further teaches “wherein validating the software dependencies of the replacement component comprises: identifying direct software dependencies of the replacement component; and identifying transitive software dependencies of the replacement component (Lu, at ¶ [0039], a multiple DLL dynamic reload routine is configured to identify the DLLs to be updated and to identify each DLL that depends, both directly and indirectly, on the DLLS to be updated.).”
Regarding claim 5, Lu in view of Oesterreicher teaches all the limitation of independent claim 1 and its dependent claim 4. Lu further teaches “wherein validating the software dependencies of the replacement component further comprises: determining that the dependent components are satisfied by the replacement component by identifying direct software dependencies and transitive software dependencies of the dependent components (Lu, at ¶ [0029], if the runtime environment detects that a program referenced the DLL, the DLL dependency table is updated to record the program and DLLs dependency relationship for either explicit DLL referencing or implicit DLL referencing.).”
Regarding claim 7, Lu in view of Oesterreicher teaches all the limitation of independent claim 1. Lu further teaches “wherein the snapshot represents a saved copy of a current memory state of the component to be serviced (Oesterreicher: Fig. 6 and ¶[0028] and ¶[0076]; Oesterreicher teaches copying value of fields from Object A to Object B.)
Regarding claim 10, Lu in view of Oesterreicher teaches the system of Claim 1. Oesterreicher further teaches “wherein applying the runtime state of the component to be serviced to the replacement component comprises scheduling execution of at least one of: the calls sent by the component to be serviced; the calls received by the component to be serviced; or the operations currently being performed by the component to be serviced (Oesterreicher: Fig. 6 and ¶[0076]; Oesterreicher teaches restoring services in project B.)
Regarding claim 12, Lu in view of Oesterreicher teaches all the limitation of independent claim 1. Lu further teaches “wherein updating the dependent components comprises replacing a reference to the component to be serviced with a reference to the replacement component (Lu, at ¶ [0037], the DLL resolve routine updates the corresponding record of the function entry point address and variable address of the updated DLL in the writable static area of the DLL which depends on the updated DLL to contain the function entry point address and variable address of the new version of the updated DLL.).”
Regarding claim 13, Lu in view of Oesterreicher teaches all the limitation of independent claim 1 and its dependent claim 12. Lu further teaches “wherein a reference to the component to be serviced corresponds to at least one of: a name of the component to be serviced; or a file path of the component to be serviced (Lu, at ¶ [0030], teaches the information of the updated DLL includes a directory and name of the updated DLL.).”
Regarding independent claim 15, Lu discloses “A method comprising:
loading, … a first software component for use by a process in the memory (Examiner notes that a dynamic link library (DLL) of Lu corresponds to a software component. Lu, at ¶ [0030], updating a DLL reloading description file with information of the updated DLL.), the memory comprising a second software component (id. at ¶ [0038], old version of the DLL.), a software component dependent on the second software component (id. at ¶ [0029], a DLL ancestor table is also updated to record the dependency relationships among different DLLs.), and a software component that is not dependent on the second software component (id. at Fig. 5, depicts some dependent DLLs (DLL_A, DLL_C, and DLL_D) related to the DLL_B and some DLLs (DLL_E, DLL_F, and DLL_G) are not dependent on the DLL_B);
determining a runtime state of the second software component ... (Lu, at ¶ [0038], the DLL resolve routine copies the imported function entry point address and variable address from the old version of the updated DLL.);
suspending the second software component and the software component dependent on the second software component... (id. at ¶ [0030], updating a DLL reload status table to include the DLL and set the reloading status to false, then identifying all program modules and DLLs that depend on the updated DLL, and initiating a reloading of the dynamic libraries having a false reload status as described at ¶ [0032].), wherein the software component that is not dependent on the second component remains functional when the second software component and the software component dependent on the second software component are suspended (id. at ¶ [0035]-[0036], when a DLL dynamic reload routine is used to dynamically update an existing DLL with an updated DLL, the DLL dynamic reload routine begins by identifying all program module that depend on the DLL by checking the DLL dependency table, but as depicted at Fig. 5, some DLLs does not affected by the DLL dynamic reload routine.);
modifying the software component dependent on the second software component to be a software component dependent on the first software component (id. at ¶ [0038], the DLL resolve routine is further configured to check the DLL dependency table for any DLLs in the import table of the updated DLL. If the import table of the updated DLL includes a DLL that is in the DLL dependency table which as a reload status of false, the DLL resolve routine calls the DLL dynamic reload routine to trigger reloading the identified DLL.);
applying the runtime state of the second software component to the first software component (id. at ¶ [0038], the DLL resolve routine re-calculate the function entry point address and variable address based on the beginning address of the DLL and updates the corresponding record in the writable static area of the new version of the updated DLL.); and
executing the first software component and the software component dependent on the first software component based on the runtime state of the second software component ... . (id. at ¶ [0018], a dynamic library to be reloaded without requiring a restart of the running applications that depend on the updated dynamic libraries, and dynamically updating a dynamic library include the ability to update a dynamic library without requiring halting execution of program modules that depend on the dynamic library as described at ¶ [0040].).” Even though Lu does not explicitly teach loading the first software component “into memory,”, Lu discloses the dynamic library is loaded into the memory by the system (Lu, at ¶ [0002]), and to update a dynamic library or a dynamic link library (DLL), it should be loaded into the memory as one of ordinary skill well acknowledged.
Accordingly, it would have been obvious to one of ordinary skill in the art at the filing date of this application to modify Lu’s method with loading a new version of DLL into memory as indicated by Lu because it enables a dynamic library to by updated and reloaded without requiring a restart of the running applications that depend on the updated dynamic libraries (Lu, at ¶ [0018]).
Lu does not explicitly teach but Oesterreicher teaches:
..., wherein the runtime state of the second software component comprises at least one of: calls sent by the second software component to be serviced; calls received by the second softtare component to be serviced; or operations currently being performed by the second software component (Oesterreicher: Fig. 6 and ¶[0028] and ¶[0076]; Oesterreicher teaches copying value of fields from Object A to Object B. Fig. 4A and ¶[0027], ¶[0033], ¶[0038], and ¶[0058] teaches the object oriented runtime environment which performs operations.)
..., wherein the suspending prevents second software component and the software component dependent on the second software component from performing operations that alter a runtime state of the second software component or a runtime state of the software component dependent on the second software component, and (Oesterreicher: Fig. 6 and ¶[0028] and ¶[0075]-¶[0076]; Oesterreicher teaches locking Object A, which prevents it from changing.)
... wherein executing the first software component comprises: causing the replacement component to execute the at least one of: the class sent by the component to be serviced; the calls received by the component to be serviced; or the operations currently being performed by the component to be serviced. (Oesterreicher: Fig. 6 and ¶[0076]; Oesterreicher teaches restoring services in project B.)
Lu and Oesterreicher are in the same field of endeavor as the present invention, as the references are directed to maintaining service to component dependencies when updating the component. It would have been obvious, before the effective filing date of the claimed invention, to a person of ordinary skill in the art, to combine loading a replacement, validating dependencies, suspending the component, and updating a component as taught in Lu with further preventing any changes to the suspended component as taught in Oesterreicher. As such, it would have been obvious to one of ordinary skill in the art to modify the teachings of Lu to include teachings of Oesterreicher, because the combination would allow updating the system without interrupting the functionality, as suggested by Oesterreicher: ¶[0064].
Regarding claim 16, Lu in view of Oesterreicher teaches all the limitation of independent claim 15. Lu further teaches “wherein the first software component is a first dynamic link library and the second software component is a second dynamic link library (Lu, at ¶ [0038], new version of the updated DLL and old version of the DLL.).”
Claim 17 is directed towards a method equivalent to a system found in claim 12, and is therefore similarly rejected.
Regarding claim 19, Lu in view of Oesterreicher teaches all the limitation of independent claim 15. Lu further teaches “wherein executing the first software component and the software component dependent on the first software component comprises:
causing the software component dependent on the first software component to resume from being suspended (Lu, at ¶ [0040], the ability to update a dynamic library without requiring halting execution of program modules that depend on the dynamic library.).”
Independent claim 20 is directed towards a device equivalent to a method found in claim 15, and is therefore similarly rejected.
Regarding claim 21, Lu in view of Oesterreicher teaches all the limitation of independent claim 15. Lu further teaches “wherein the runtime state of the second software comprises at least one of: calls sent or received by the second software; and operations being performed by the second software (Lu, at Fig. 5 and ¶ [0028] and ¶[0035], calling relationships between applications and DLLs are tracked during runtime and a DLL dynamic reloading signal is used to initiate a dynamic update to a new version of an existing DLL, the dynamic update of the DLL includes re-assigning the DLL addresses for all running processes which are using the DLL.).”
Regarding claim 22, Lu in view of Oesterreicher teaches all the limitation of independent claim 20. Oesterreicher further teaches “wherein loading the first software comprises initializing the first software by providing an initial value to a variable used by the first software.” (Oesterreicher: Fig. 4A and ¶[0059]; Oesterreicher teaches an object containing fields and data.)
Regarding claim 23, Lu in view of Oesterreicher teaches all the limitation of independent claim 20. Lu further teaches “the operations further comprising: upon loading the first software, validating software dependencies of the first software by identifying at least one of: direct software dependencies of the first software; or transitive software dependencies of the first software.” (Lu. at ¶ [0029], a DLL dependency table is used to store calling relationships between applications and DLLs, during the application runtime when a runtime environment resolves a DLL, if the runtime environment detects that a program referenced the DLL the DLL dependency table is updated to record the program and DLLs dependency relationship for either explicit DLL referencing or implicit DLL referencing.)
Regarding claim 24, Lu in view of Oesterreicher teaches all the limitation of independent claim 20. Oesterreicher further teaches “wherein determining the runtime state of the second software comprises creating and saving a snapshot of the runtime state of the second software.” (Oesterreicher: Fig. 6 and ¶[0028] and ¶[0076]; Oesterreicher teaches copying value of fields from Object A to Object B. Fig. 4A and ¶[0027], ¶[0033], ¶[0038], and ¶[0058] teaches the object oriented runtime environment which performs operations.)
Claim(s) 14 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over , Lu in view of Oesterreicher in view of Ye.
Regarding claim 14, Lu in view of Oesterreicher teaches all the limitation of independent claim 1. Lu further teaches similar process of updating a DLL reload status table to include the DLL and set the reloading status to false. However, Lu does not explicitly teach “further comprising unloading the component to be serviced, the unloading comprises: deallocating resources previously allocated to the component to be serviced; and removing the component to be serviced from the memory.”
Ye is in the same field of program updating, and provides a dynamic link library updating method (Ye, at Abstract) that the handle of the second dynamic link library is removed from the linear table of the memory image (id. at ¶ [0013]).
Accordingly, it would have been obvious to one of ordinary skill in the art at the filing date of this application to combine Lu’s system with deallocating resources previously allocated to the previous version of DLL and removing the DLL from the memory as taught by Ye because it ensures the uninterrupted operation and integrity of the program (Ye, at ¶ [0056]).
Regarding claim 18, Lu in view of Oesterreicher teaches all the limitation of independent claim 15. Lu further teaches “wherein suspending the second software component and the software component dependent on the second software component comprises: … wherein unloading the second software component does not cause the process to be restarted (id. at ¶ [0018], a dynamic library be terminated … enable the dynamic library to be updated and reloaded without requiring a restart of the running applications.).” However, Lu does not explicitly teach “unloading the second software component from the memory,”
Ye is in the same field of program updating, and provides a dynamic link library updating method (Ye, at Abstract) that the handle of the second dynamic link library is removed from the linear table of the memory image (id. at ¶ [0013]).
Accordingly, it would have been obvious to one of ordinary skill in the art at the filing date of this application to combine Lu’s system with deallocating resources previously allocated to the previous version of DLL and removing the DLL from the memory as taught by Ye because it ensures the uninterrupted operation and integrity of the program (Ye, at ¶ [0056]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALEX OLSHANNIKOV whose telephone number is (571)270-0667. The examiner can normally be reached M-F 9:30-6.
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, Scott Baderman can be reached at 571-272-3644. 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.
/ALEKSEY OLSHANNIKOV/Primary Examiner, Art Unit 2118