DETAILED ACTION
Claims 1, 2, and 15-17 are amended. Claims 3 and 4 are cancelled. Claims 21 and 22 are new. Claims 1, 2, and 5-22 are pending in the application.
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 .
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.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 09/10/2025 has been entered.
Examiner’s Notes
The Examiner cites particular sections in the references as applied to the claims below for the convenience of the applicant(s). Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant(s) fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner.
Claim Rejections - 35 USC § 112(a)
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 21 and 22 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 21 recites “the interposing dynamic linking method does not maintain any information about the original methods” in lines 1-2. However, the original disclosure does not provide support for “not maintain any information about the original methods”. Specifically, the original disclosure, including paragraph [0036] as pointed out by the Applicant, identifies at least the original method names being maintained by the dynamic linking method (e.g. original method “FOO” has a corresponding interposing method named “FOO” as identified by the dynamic linking method).
As such, these limitations fail to comply with the written description requirement by introducing subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 22 recites “the interposing dynamic linking method does not maintain any information about the original methods” in lines 1-2. However, the original disclosure does not provide support for “not maintain any information about the original methods”. Specifically, the original disclosure, including paragraph [0036] as pointed out by the Applicant, identifies at least the original method names being maintained by the dynamic linking method (e.g. original method “FOO” has a corresponding interposing method named “FOO” as identified by the dynamic linking method).
As such, these limitations fail to comply with the written description requirement by introducing subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim Rejections - 35 USC § 112(b)
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.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 21 and 22 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 21 recites “the interposing dynamic linking method does not maintain any information about the original methods” in lines 1-2. This is a negative limitation that attempts to define the invention in terms of what it is not (i.e. what is not being maintained by the dynamic linking method) rather than what it is (i.e. what is actually being maintained by the dynamic linking method). As such, these limitations render the claim indefinite. See MPEP §2173.05(i).
For the following analysis, the Examiner will consider any dynamic linking method including any information that is different than any information maintained by an original method as being analogous to “the interposing dynamic linking method does not maintain any information about the original methods”.
Claim 22 recites “the interposing dynamic linking method does not maintain any information about the original methods” in lines 1-2. This is a negative limitation that attempts to define the invention in terms of what it is not (i.e. what is not being maintained by the dynamic linking method) rather than what it is (i.e. what is actually being maintained by the dynamic linking method). As such, these limitations render the claim indefinite. See MPEP §2173.05(i).
For the following analysis, the Examiner will consider any dynamic linking method including any information that is different than any information maintained by an original method as being analogous to “the interposing dynamic linking method does not maintain any information about the original methods”.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1, 2, 7, 8, and 10-18 are rejected under 35 U.S.C. 103 as being unpatentable over Mikkelsen et al. (US 2007/0006202 A1; hereinafter Mikkelsen) in view of Clark et al. (US 2015/0156202 A1; hereinafter Clark).
With respect to claim 1, Mikkelsen teaches: A method for controlling operation of a computer that stores a library of original methods (see e.g. Mikkelsen, paragraph 16: “original dll”; and paragraph 1: “dlls or shared libraries typically contain a collection of functions”), which have respective method names (see e.g. Mikkelsen, paragraph 16: “dll with the same function names”; and Fig. 15: “Name”) and are for dynamic loading by a software application running on the computer (see e.g. Mikkelsen, paragraph 1: “use of dynamically loadable libraries (herein "dlls") as a vehicle to build new software from existing software”), the method comprising:
loading, to respective first addresses (see e.g. Mikkelsen, paragraph 1: “reference the functions that are available in one or more dlls/libraries”) in a memory of the computer (see e.g. Mikkelsen, paragraph 27: “present teachings is implemented using a Windows operating system by Microsoft Corporation running on a personal computer”), one or more interposing methods (see e.g. Mikkelsen, paragraph 16: “The router 200, therefore, is also a dll with the same function names as the functions of the original and new dlls… router 200 is interposed between the application and the original and new dlls 102, 202”; paragraph 1: “dlls or shared libraries typically contain a collection of functions”; and Fig. 2: “Router 200”) having respective ones of the method names (see e.g. Mikkelsen, paragraph 16: “The router 200, therefore, is also a dll with the same function names”; and paragraph 21: “the router 200 contains a function with the same name”);
identifying a second address in the memory (see e.g. Mikkelsen, paragraph 2: “references a function in a dll is built, it creates a symbol in the object code that directs the retrieval of the relevant dll and function within the dll”; and paragraph 16: “find and reference only the original dll 102 having an original name and location”) of an original dynamic linking method (see e.g. Mikkelsen, Fig. 2: “API 104”; paragraph 2: “API 104, therefore, governs the interaction of the application 100 with the dll 102. When an application or other software module that references a function in a dll is built, it creates a symbol in the object code that directs the retrieval of the relevant dll and function within the dll”) that is associated with the library (see e.g. Mikkelsen, Fig. 2: “Library 1 102”, paragraph 2: “When an application or other software module that references a function in a dll is built, it creates a symbol in the object code that directs the retrieval of the relevant dll and function within the dll”; and paragraph 16: “uses the original 104 API to administer communication between the application 100 and the original dll 102”) and is configured to dynamically link dynamic libraries to the software application (see e.g. Mikkelsen, paragraph 2: “API 104, therefore, governs the interaction of the application 100 with the dll 102. When an application or other software module that references a function in a dll is built, it creates a symbol in the object code that directs the retrieval of the relevant dll and function within the dll. At run time, the application must have the dll available to it. The application contains code that directs a search for the dll and also points to a location of the dll so the application can retrieve the function based upon the embedded symbol for execution in the application context”; and paragraph 16: “uses the original 104 API to administer communication between the application 100 and the original dll 102… application 100 is written to find and reference only the original dll 102 having an original name and location”);
intercepting, by an interposing dynamic linking method (see e.g. Mikkelsen, paragraph 16: “router functions”) configured to dynamically link dynamic libraries to the software application (see e.g. Mikkelsen, paragraph 16: “router functions provide administration and access to the functions of the original dll 102… router 200 functions intercept all calls from the application 100 to the original dll and determines which one of the dlls having the original API 104 is the relevant library for the specific function… router 200 then calls the function on the relevant library passing it all of the appropriate parameters”), a request from the software application (see e.g. Mikkelsen, paragraph 16: “router 200 functions intercept all calls from the application 100”; and paragraph 21: “application 100 makes a call to the ibdev function”), the request specifying one of the method names (see e.g. Mikkelsen, paragraph 16: “calls from the application 100 to the original dll”; and paragraph 21: “ application 100 makes a call to the ibdev function… ibdev function is called in a first access to a device or interface”; and paragraph 33: “function call names 1501”);
comparing the specified method name, by the interposing dynamic linking method (see e.g. Mikkelsen, paragraph 16: “router functions provide administration and access to the functions of the original dll 102 and the new dll 202”; and paragraph 17: “router enable flag 302 may be set by the user to a logic true to indicate to the system that the user wants to use the multiple dll capability”), to the method names of the interposing methods (see e.g. Mikkelsen, paragraph 17: “the router enable flag is true… If the contents of the dll having the original name are the same as the contents of the router 200”; and paragraph 21: “application 100 makes a call to the ibdev function… the router 200 contains a function with the same name… The application 100 calls the ibdev function and if the router is enabled, initiates the router ibdev function”); and
directing the software application, by the interposing dynamic linking method (see e.g. Mikkelsen, paragraph 16: “router functions provide administration and access to the functions of the original dll 102 and the new dll 202”), based on the comparing (see e.g. Mikkelsen, paragraph 16: “router 200 functions intercept all calls from the application 100 to the original dll and determines which one of the dlls having the original API 104 is the relevant library for the specific function… The router 200 then calls the function on the relevant library”; and paragraph 21: “original dll 102 contains the ibdev function, the router 200 contains a function with the same name… application 100 calls the ibdev function and if the router is enabled, initiates the router ibdev function”), such that:
provided one of the interposing methods has the specified method name (see e.g. paragraph 17: “the router enable flag is true… If the contents of the dll having the original name are the same as the contents of the router 200”; and paragraph 21: “application 100 makes a call to the ibdev function… the router 200 contains a function with the same name”), the software application is directed to one of the first addresses so as to run the interposing method having the specified method name (see e.g. Mikkelsen, paragraph 21: “application 100 calls the ibdev function and if the router is enabled, initiates the router ibdev function… The router 200 then calls the ibdev function in the relevant underlying dll and passing to it all of the parameters it received from the application 100”),
Mikkelsen discloses directing an application 100 to an original dll 102 via a router dll 200 based on matching function names (e.g. “ibdev” function of the dll 102 to “ibdev” function of the router 200) (see Mikkelsen, paragraphs 16, 21). Mikkelsen further discloses comparing contents of the router 200 (which includes the router’s functions and names) to the contents of the original dll 102 (see Mikkelsen, paragraph 17) and generating an error (e.g. an exception) when a function from the original dll is not available at the router 200 (see Mikkelsen, paragraphs 33-34; Fig. 15).
However, Mikkelsen does not explicitly disclose directing the application 100 to the original dll 102 when the function names do not match (e.g. when the function is not yet available at the router).
On the other hand, Clark teaches:
but when none of the interposing methods has the specified method name (see e.g. Clark, paragraph 22: “interposer library may follow a list of function names”; paragraph 39: “identify a subset of the function calls. The subset may be function calls that should be intercepted by the interposer library”; and paragraph 46: “comparison of calls is based on the name of the executable”), the software application is directed to the second address so as to run the original dynamic linking method to run the original method having the specified method name (see e.g. Clark, paragraph 19: “when a library function call is attempted by the process, the interposer library is checked first. If a version of the function call exists in the interposer library, the version of the function call in the interposer library is invoked first instead of or just before any version in any other library”; and paragraph 39: “identify a subset of the function calls. The subset may be function calls that should be intercepted by the interposer library”).
Clark discloses an interposer library that maintains a list of function names which identifies functions to be intercepted by the interposer library. Since Clark discloses “If a version of the function call exists in the interposer library, the version of the function call in the interposer library is invoked first instead of or just before any version in any other library” and “subset may be function calls that should be intercepted by the interposer library”, Clark inherently discloses directing the function call to the original library when the version of the function call does not exist in the interposer library as such a call would not be in the subset of functions and should not be intercepted.
Mikkelsen and Clark analogous art because they are in the same field of endeavor: intercepting function/method calls by an interposing library and redirecting the intercepted calls to other libraries. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Mikkelsen with the teachings of Clark. The motivation/suggestion would be to improve exception handling process of Mikkelsen by gracefully managing potential error conditions that might arise when a function name that is not part of the router 200 is invoked by the application 100 (see e.g. Mikkelsen, paragraphs 33-34).
With respect to claim 2, Mikkelsen as modified teaches: The method according to claim 1, and further comprising loading, from a storage device, the interposing methods prior to loading the library of original methods (see e.g. Mikkelsen, paragraph 1: “dynamically loadable libraries (herein "dlls")”; paragraph 16: “router 200, therefore, is also a dll… router 200 functions intercept all calls from the application 100 to the original dll”; and paragraph 17: “determines if the dll having the original name exists 303. If it does, the process identifies 304 and evaluates 305 the dll with the original name. If the contents of the dll having the original name are the same as the contents of the router 200”).
Since Mikkelsen discloses both the router 200 and the original library being dynamically loadable such that the router 200 intercepts all the calls directed to the original dll (see e.g. Mikkelsen, paragraphs 1, 16) and checking if the original dll exists in comparison to the router 200 (see e.g. Mikkelsen, paragraph 17), it would have been obvious to one of ordinary skill in the art to load the router 200 before loading the original dll. The motivation/suggestion for such a modification would be to improve reliability by ensuring that the router 200 will always be available to intercept all the calls directed to the original dll.
With respect to claim 7, Mikkelsen as modified teaches: The method according to claim 1, and further comprising loading, from a storage device, a system library (see e.g. Mikkelsen, paragraph 1: “dynamically loadable libraries (herein "dlls")… operating system environment”) comprising the original dynamic linking method prior to loading the library of original methods (see e.g. Mikkelsen, paragraph 16: “router 200, therefore, is also a dll… router 200 functions intercept all calls from the application 100 to the original dll”; and paragraph 17: “determines if the dll having the original name exists 303. If it does, the process identifies 304 and evaluates 305 the dll with the original name. If the contents of the dll having the original name are the same as the contents of the router 200”).
Since Mikkelsen discloses both the router 200 and the original library being dynamically loadable such that the router 200 intercepts all the calls directed to the original dll (see e.g. Mikkelsen, paragraphs 1, 16) and checking if the original dll exists in comparison to the router 200 (see e.g. Mikkelsen, paragraph 17), it would have been obvious to one of ordinary skill in the art to load the router 200 before loading the original dll. The motivation/suggestion for such a modification would be to improve reliability by ensuring that the router 200 will always be available to intercept all the calls directed to the original dll.
With respect to claim 8, Mikkelsen as modified teaches: The method according to claim 7, wherein identifying the second address comprises computing an offset of the original dynamic linking method in the system library on the storage device (see e.g. Mikkelsen, paragraph 22: “The router ibfind function then determines 710 if the libud 514 refers to a device or an interface. In a specific embodiment, the range of values for libud's 514 that reference an interface are offset by some number, 256 as an example… N is equal to 256”), identifying, in the memory, a base address for the loaded system library (see e.g. Mikkelsen, paragraph 22: “the libud's 514 that reference a device… index in the interface session table 510”), and adding the offset to the base address (see e.g. Mikkelsen, paragraph 22: “the range of values for libud's 514 that reference an interface are offset by some number, 256 as an example, relative to the libud's 514 that reference a device… The devud 503 is set 730 equal to N plus the index in the interface session table 510 and is returned to the application 100 as the devud 503. In a specific embodiment N is equal to 256”).
With respect to claim 10, Mikkelsen as modified teaches: The method according to claim 1, wherein running the interposing method comprises calling, with one or more parameters (see e.g. Mikkelsen, paragraph 16: “all of the appropriate parameters that were passed to the router 200”), the original method having the identical original method name (see e.g. Mikkelsen, paragraph 16: “router 200, therefore, is also a dll with the same function names as the functions of the original and new dlls wherein the router functions provide administration and access to the functions of the original dll 102 and the new dll 202… The router 200 functions intercept all calls from the application 100 to the original dll and determines which one of the dlls having the original API 104 is the relevant library for the specific function… The router 200 then calls the function on the relevant library passing it all of the appropriate parameters that were passed to the router 200”), receiving a result from the called original method (see e.g. Mikkelsen, paragraph 22: “The router 200 receives the returned library unit descriptor 514 and stores it in the appropriate router session structure 512 within the router 200”; and paragraph 36: “router 200 calls the function in more than one of the dll's and provide a selection or combining mechanism to provide the final result”), and performing an operation on the received result (see e.g. Mikkelsen, paragraph 22: “stores it in the appropriate router session structure 512 within the router 200. A pointer to the router session structure 512 that contains the library unit descriptor 514 is a session pointer 513. The router 200 stores the session pointer 513 in the device session table 508. An index of the entry of the session pointer 513 in the device session table is the devud 503 and identifies a location of the session pointer in the device session table 508. The router 200 returns the devud 503 to the application 100”; and paragraph 36: “a selection or combining mechanism to provide the final result. For example, the results could be the average, statistical median, statistical mode (vote with the most common result), minimum or maximum. An application area for the embodiment where the function is called in more than one dll is to provide a fault tolerant software application where different developers or vendors have written the dll code. In this application, an extension to the mechanism could provide error conditions based on the results. For example, if there are 3 dlls, and they each return a different answer, this could cause the generation of an error”).
With respect to claim 11, Mikkelsen as modified teaches: The method according to claim 10, wherein the operation comprises profiling the original method (see e.g. Mikkelsen, paragraph 21: “The ibdev function for the underlying dll returns the library unit descriptor 514 given to it. The library unit descriptor 514 is a unique number stored in the device/interface session table 518/520 within the underlying dll 102 or 202 that provides reference to the specific device under control. The router 200 receives the returned library unit descriptor 514 and stores it in the appropriate router session structure 512 within the router 200”).
With respect to claim 12, Mikkelsen as modified teaches: The method according to claim 10, wherein the operation comprises debugging the original method (see e.g. Mikkelsen, paragraph 28: “As the two dlls are used with a single application, upgrades may become available for one or both of the dlls 102, 202. It is desirable to take advantage of dll upgrades because bug fixes”).
With respect to claim 13, Mikkelsen as modified teaches: The method according to claim 10, wherein the operation comprises instrumenting the original method (see e.g. Mikkelsen, paragraph 36: “a selection or combining mechanism to provide the final result. For example, the results could be the average, statistical median, statistical mode (vote with the most common result), minimum or maximum… an extension to the mechanism could provide error conditions based on the results”).
With respect to claim 14, Mikkelsen as modified teaches: The method according to claim 10, wherein the operation comprises adding functionality to the original method (see e.g. Mikkelsen, paragraph 28: “One or more of the upgrades may also update the API of one of the dlls… the first dll 102 as being updated with first additional entry points 1208, illustrated as "D" and "E". FIG. 12 also shows the second dll 202 as being updated with a second additional entry point 1210, illustrated as "F". The router 200 is able to administer access to the first and second dlls 102, 202 if an updated router API 1212 contains all of the call interfaces 1206, 1208, and 1210 from the first and second APIs 1202, 1204 and has function calls with the capability to administer the calls made by the application”; and Fig. 12).
With respect to claim 15: Claim 15 is directed to an apparatus comprising a memory storing program instructions and a processor configured to implement active functions corresponding to the method recited in claim 1; please see the rejection directed to claim 1 above which also covers the limitations recited in claim 15. Note that, Mikkelsen also discloses a system comprising a processor and a storage device configured to implement active functions (see e.g. Mikkelsen, claim 12) corresponding to the method disclosed in claim 1.
With respect to claim 16: Claim 16 is directed to a computer software product for controlling operation of a computer comprising a non-transitory computer-readable medium, in which program instructions are stored, which, when read by a computer, cause the computer to implement active functions corresponding to the method recited in claim 1; please see the rejection directed to claim 1 above which also covers the limitations recited in claim 16. Note that, Mikkelsen also discloses a storage device comprising instructions to cause a computing system to implement active functions (see e.g. Mikkelsen, claim 12) corresponding to the method disclosed in claim 1.
With respect to claim 17, Mikkelsen as modified teaches: The method according to claim 1, further comprising loading an interposing library (see e.g. Mikkelsen, Fig. 2: “Router 200”; paragraph 16: “router 200, therefore, is also a dll”), which includes the interposing dynamic linking method (see e.g. Mikkelsen, paragraph 16: “router 200, therefore, is also a dll… router functions”) and the interposing methods (see e.g. Mikkelsen, paragraph 16: “router 200, therefore, is also a dll with the same function names as the functions of the original and new dlls”), to the memory prior to launching the software application (see e.g. Mikkelsen, paragraph 1: “dynamically loadable libraries (herein "dlls")”; paragraph 16: “router 200, therefore, is also a dll… router 200 functions intercept all calls from the application 100 to the original dll”; and paragraph 17: “determines if the dll having the original name exists 303. If it does, the process identifies 304 and evaluates 305 the dll with the original name. If the contents of the dll having the original name are the same as the contents of the router 200”).
Since Mikkelsen discloses both the router 200 and the original library being dynamically loadable such that the router 200 intercepts all the calls from the application 100 directed to the original dll (see e.g. Mikkelsen, paragraphs 1, 16) and checking if the original dll exists in comparison to the router 200 (see e.g. Mikkelsen, paragraph 17), it would have been obvious to one of ordinary skill in the art to load the router 200 before launching the application 100. The motivation/suggestion for such a modification would be to improve reliability by ensuring that the router 200 will always be available to intercept all the calls coming from the application 100.
With respect to claim 18, Mikkelsen as modified teaches: The method according to claim 17, further comprising loading a system library (see e.g. Mikkelsen, paragraph 1: “dynamically loadable libraries (herein "dlls")… operating system environment”), which includes the original dynamic linking method (see e.g. Mikkelsen, paragraph 16: “original dll 102”; and paragraph 1: “dlls or shared libraries typically contain a collection of functions”), to the memory after loading the interposing library (see e.g. Mikkelsen, paragraph 1: “dynamically loadable libraries (herein "dlls")”; paragraph 16: “router 200, therefore, is also a dll… router 200 functions intercept all calls from the application 100 to the original dll”) and prior to launching the software application (see e.g. Mikkelsen, paragraph 16: “router 200 functions intercept all calls from the application 100 to the original dll”; and paragraph 17: “determines if the dll having the original name exists 303. If it does, the process identifies 304 and evaluates 305 the dll with the original name. If the contents of the dll having the original name are the same as the contents of the router 200”).
Since Mikkelsen discloses both the router 200 and the original library being dynamically loadable such that the router 200 intercepts all the calls from the application 100 directed to the original dll (see e.g. Mikkelsen, paragraphs 1, 16) and checking if the original dll exists in comparison to the router 200 (see e.g. Mikkelsen, paragraph 17), it would have been obvious to one of ordinary skill in the art to load the router 200 before launching the application 100. The motivation/suggestion for such a modification would be to improve reliability by ensuring that the router 200 will always be available to intercept all the calls coming from the application 100.
Claims 5, 6, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Mikkelsen in view of Clark as applied to claim 1 above, and further in view of Evans et al. (US 9,898,615 B1; hereinafter Evans).
With respect to claim 5, Mikkelsen as modified teaches: The method according to claim 1,
Mikkelsen does not but Evans teaches:
wherein the library comprises an Executable and Linkable Format (ELF) library (see e.g. Evans, column 6, lines 39-42: “the linker library contains functions of interest for library lookup. In an action 504, the executable and linkable format (ELF) file for the function of interest is parsed”).
Mikkelsen and Evans are analogous art because they are in the same field of endeavor: managing application executions associated with dynamically linked libraries. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Mikkelsen with the teachings of Evans. The motivation/suggestion would be to improve extensibility, flexibility and cross-platform compatibility for the dlls.
With respect to claim 6, Mikkelsen as modified teaches: The method according to claim 1,
Mikkelsen does not but Evans teaches:
wherein the intercepted request comprises a dlsym( ) call (see e.g. Evans, column 5, lines 28-30: “an injected library 114 may intercept dlopen( ) and dlsym ( ), and block the use of these, preventing the look up of addresses of functions 110”).
Mikkelsen and Evans are analogous art because they are in the same field of endeavor: managing application executions associated with dynamically linked libraries. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Mikkelsen with the teachings of Evans. The motivation/suggestion would be to improve cross-platform compatibility .
With respect to claim 20, Mikkelsen as modified teaches: The method according to claim 1,
Mikkelsen does not but Evans teaches:
wherein the original dynamic linking method and the interposing dynamic linking method are respective instances of dlsym() (see e.g. Evans, column 5, lines 28-30: “an injected library 114 may intercept dlopen( ) and dlsym ( ), and block the use of these, preventing the look up of addresses of functions 110”).
Mikkelsen and Evans are analogous art because they are in the same field of endeavor: managing application executions associated with dynamically linked libraries. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Mikkelsen with the teachings of Evans. The motivation/suggestion would be to improve cross-platform compatibility .
Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Mikkelsen in view of Clark as applied to claim 17 above, and further in view of Greenfield (US 2020/0117483 A1).
With respect to claim 19, Mikkelsen as modified teaches: The method according to claim 17,
Mikkelsen does not but Greenfield teaches:
wherein loading the interposing library comprises loading the interposing library using an ld_preload() call (see e.g. Greenfield, paragraph 29: “use Dynamic Linking to intercept and modify accesses by an executable to the file system. Such a mechanism includes LD_PRELOAD in Linux-based systems”).
Mikkelsen and Greenfield are analogous art because they are in the same field of endeavor: managing application executions associated with dynamically linked libraries and call interception. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Mikkelsen with the teachings of Greenfield. The motivation/suggestion would be to improve cross-platform compatibility .
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Mikkelsen in view of Clark as applied to claim 1 above, and further in view of Renema, II (US 9,348,488 B1; hereinafter Renema) and Evans.
With respect to claim 9, Mikkelsen as modified teaches: The method according to claim 7,
Mikkelsen does not but Renema teaches:
wherein the system library comprises libsdl.so (see e.g. Renema, column 81, lines 13-14: “Copy library and header files to allow use with MinGW compilers and linkers” and lines 22-23: “cp -p SDL.lib /c/mingw/lib/libSDL.a”), and
Mikkelsen and Renema are analogous art because they are in the same field of endeavor: managing application executions associated with dynamically linked libraries. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Mikkelsen with the teachings of Renema. The motivation/suggestion would be to improve cross-platform compatibility .
Furthermore, Mikkelsen does not but Evans teaches:
wherein the original dynamic linking method comprises dlsym( ) (see e.g. Evans, column 5, lines 28-30: “an injected library 114 may intercept dlopen( ) and dlsym ( ), and block the use of these, preventing the look up of addresses of functions 110”).
Mikkelsen and Evans are analogous art because they are in the same field of endeavor: managing application executions associated with dynamically linked libraries. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Mikkelsen with the teachings of Evans. The motivation/suggestion would be to improve cross-platform compatibility .
Response to Arguments
Applicant's arguments filed 09/10/2025 have been fully considered but they are not persuasive. In detail:
(i) Regarding Applicant’s arguments (a) and (b) with respect to claim 1 (Remarks, page 11), note that the router 200 is a dynamically linked library that provides both routing functions (i.e. linking methods) and router’s version of the original dll functions (i.e. interposing methods), such as ibdev, ibfind, etc.
Specifically, router 200 provides administration and access functions to the functions to the original dll 102 (see e.g. Mikkelsen, paragraph 16: “router functions provide administration and access to the functions of the original dll 102”). Such administration and access functions of the router 200 are analogous to the claimed “interposing dynamic linking method”.
The router 200 also provides router’s version of the functions provided by the original dll, such as a router’s “ibdev” function corresponding to the “ibdev” function of the original dll (see e.g. Mikkelsen, paragraph 16: “The router 200, therefore, is also a dll with the same function names as the functions of the original and new dlls”; paragraph 21: “original dll 102 contains the ibdev function, the router 200 contains a function with the same name… calls the ibdev function and if the router is enabled, initiates the router ibdev function”). Such router functions corresponding to the original dll functions (e.g. “ibdev” function of the router) are analogous to the claimed “interposing methods”.
As such, Mikkelsen teaches the limitations “interposing dynamic linking method” and “interposing methods” as recited in claim 1. For more details, please see the rejection directed to claim 1 above.
(ii) Regarding Applicant’s arguments (c) (Remarks, page 11), note that Mikkelsen discloses an API 104 which enables application 100 to interact with the original dll 102 at runtime (see e.g. Mikkelsen, paragraph 2: “API 104, therefore, governs the interaction of the application 100 with the dll 102. When an application or other software module that references a function in a dll is built, it creates a symbol in the object code that directs the retrieval of the relevant dll and function within the dll. At run time, the application must have the dll available to it. The application contains code that directs a search for the dll and also points to a location of the dll so the application can retrieve the function based upon the embedded symbol for execution in the application context”; and paragraph 16: “uses the original 104 API to administer communication between the application 100 and the original dll 102… application 100 is written to find and reference only the original dll 102 having an original name and location”).
That is, the API 104 acts as a dynamic linker between the application and the original dll 102, providing communication functions (i.e. dynamic linking methods) that enables the application 100 to utilize the original dll 102.
As such, Mikkelsen teaches the limitation “an original dynamic linking method… configured to dynamically link dynamic libraries to the software application” as recited in claim 1. For more details, please see the rejection directed to claim 1 above.
(iii) Regarding Applicant’s arguments (d) (Remarks, page 11), in view of the above discussion (i), note that Mikkelsen discloses application 100 invoking a specific dll 102 function, such as “ibdev” of the dll 102, which specifies a particular method name the application is invoking (e.g. “ibdev”). This invocation is intercepted by the router 200 and a corresponding router function is invoked instead (e.g. the router’s version of the “ibdev”) (see e.g. Mikkelsen, paragraph 21: “application 100 makes a call to the ibdev function… the router 200 contains a function with the same name… The application 100 calls the ibdev function and if the router is enabled, initiates the router ibdev function”).
As such, the method name provided with the function invocation of the application 100 is compared to the method name provided by the router 200.
Additionally, Mikkelsen also discloses certain cases, such as an updated router, that might not have the function invoked by the application yet which results in an error (see e.g. Mikkelsen, paragraphs 33-34). Thus, Mikkelsen further identifies comparing the method name provided with the application’s function invocation to the method names provided by the router.
Therefore, Mikkelsen teaches the limitation “comparing the specified method name, by the interposing dynamic linking method, to the method names of the interposing methods” as recited in claim 1. For more details, please see the rejection directed to claim 1 above.
(iv) Regarding Applicant’s arguments (e) (Remarks, pages 11-12), in view of the above discussions (i)-(iii), note that router 200 receives the function call from the application 100 and, based on the name of the function invoked by the application 100, initiates its corresponding function (see e.g. Mikkelsen, paragraph 16: “router 200 functions intercept all calls from the application 100 to the original dll and determines which one of the dlls having the original API 104 is the relevant library for the specific function… The router 200 then calls the function on the relevant library”; and paragraph 21: “original dll 102 contains the ibdev function, the router 200 contains a function with the same name… application 100 calls the ibdev function and if the router is enabled, initiates the router ibdev function”).
That is, when the router is enabled, the router’s version of the function is executed; i.e. the application 100 is directed to the router’s version of the function, such as the router’s “ibdev”.
As such, Mikkelsen teaches the limitation “provided one of the interposing methods has the specified method name, the software application is directed to one of the first addresses so as to run the interposing method having the specified method name” as recited in claim 1. For more details, please see the rejection directed to claim 1 above.
(v) Regarding Applicant’s arguments (f) (Remarks, page 12), note that the router 200, when enabled, always compares/evaluates function names corresponding to the application’s function calls. For example, for “ibdev” function, router 200 does not execute “ibfind” but executes its corresponding “ibdev” function. Furthermore, as discussed above in item (iii), router 200 also identifies missing functions and throws an exception in certain cases, such as a router update.
According, enabling the router 200 means names of the functions invoked by the application 100 are going to be compared to the function names provided by the router 200.
Consequently, Mikkelsen teaches the limitation “comparing the specified method name, by the interposing dynamic linking method, to the method names of the interposing methods” as recited in claim 1. For more details, please see the rejection directed to claim 1 above.
Applicant’s arguments with respect to the limitation “when none of the interposing methods has the specified method name, the software application is directed to the second address so as to run the original dynamic linking method to run the original method having the specified method name” recited in claim 1 (Remarks, page 12), and the similar limitations recited in claims 15 and 16, 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.
Allowable Subject Matter
Claims 21 and 22 would be allowable if rewritten to overcome the rejection(s) under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), 1st paragraph and 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), 2nd paragraph, set forth in this Office action and to include all of the limitations of the base claim and any intervening claims.
CONCLUSION
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
DeMonner et al. (US 2022/0019517 A1) discloses a dynamic library replacement technique to replace original functions or methods of application libraries based on analysis (e.g., comparative performance) of traces captured by a client library, and to determine either to replace the original method or to use the client library functions for improving performance (see paragraph 11; Fig. 5).
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Umut Onat whose telephone number is (571)270-1735. The examiner can normally be reached M-Th 9:00-7:30.
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, Kevin L Young can be reached on (571) 270-3180. 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.
/UMUT ONAT/Primary Examiner, Art Unit 2194