DETAILED ACTION
Claims 1, 11, 12, 18, and 19 are amended. Claims 1-20 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.
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.
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 07/29/2026 has been entered.
Claim Objections
Claim 16 is objected to because of the following informalities:
Claim 16: “of” (line 4) should have been –of—.
Appropriate corrections are required. Applicant is advised to review the entire claims for further needed corrections.
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-6, 9-16, 19, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Kuesel et al. (US 2013/0185704 A1; from IDS filed on 03/03/2025; hereinafter “Kuesel”) in view of Young, III et al. (US 2015/0277971 A1; hereinafter “Young”) and Huang et al. (US 2023/0115334 A1; hereinafter “Huang”).
With respect to claim 1, Kuesel teaches: A method, comprising:
at least in part via a processor (see e.g. Kuesel, Fig. 1B: “Computer Processor 192”) of a computing device (see e.g. Kuesel, Fig. 1B: “Node 190”; and paragraph 33: “nodes 190 contain a computer processors 192”) during runtime of a particular software component (see e.g. Kuesel, paragraph 39: “At runtime, i.e., after the executable code is assigned to a particular processor”), activating a linker component (see e.g. Kuesel, Fig. 1B: “Linker 196”; and paragraph 39: “linker 196 may be used for programs that are dynamically linked to libraries… At runtime, i.e., after the executable code is assigned to a particular processor, the linker 196 resolves the references and brings into memory the required libraries”) responsive at least in part to a call to a particular function (see e.g. Kuesel, Fig. 2: “230”, “232”, “234”, “236”; and paragraph 52) specified by the particular software component (see e.g. Kuesel, paragraph 55: “Once the executable code 228 is assigned to a processor, the linker resolves the references 230, 232, 234, and 236… during the execution of the executable code 228, the linker uses the references 230, 232, 234, and 236 to locate the associated library and load that library into memory. The references are resolved by ensuring the processor has the information necessary to locate the associated libraries 246 in memory”);
determining, at least in part via execution of the linker component, one or more aspects (see e.g. Kuesel, paragraph 56: “architecture type”) of a current execution environment (see e.g. Kuesel, paragraph 56: “the linker may use the ID register to determine the architecture type of the processor”);
selecting a first particular implementation of the particular function among a plurality of implementations of the particular function (see e.g. Kuesel, paragraph 39: “ensure that the correct optimized code is executed”; and paragraph 56: “selectively choose the libraries 246 to bring into memory, thereby leaving the other libraries in storage”) based at least in part on the one or more aspects of the current execution environment (see e.g. Kuesel, paragraph 39: “linker 196 may also determine the type of the processor 192 to ensure that the correct optimized code is executed by the processor 192”; paragraph 56: “linker may use the ID register to determine the architecture type of the processor. With this knowledge, the linker can selectively choose the libraries 246 to bring into memory, thereby leaving the other libraries in storage (i.e., a hard drive). For example, if the linker determines that processor is processor 2, the linker moves only the user_sub_proc2 library 240 and the lib_sub_proc2 library 244 into main memory”; and paragraph 70: “linker 196 may also identify the processor's architecture implementation and dynamically link the executable to the library which contains the optimized version associated with the architecture implementation”);
executing the first particular implementation of the particular function (see e.g. Kuesel, paragraph 72: “At step 430, the assigned processor 192 begins to run the executable code. Once the processor 192 executes object code associated with the resolved reference”; and Fig. 4: “Execute The Optimized Code 430”);
responsive at least in part to a subsequent call to the particular function (see e.g. Kuesel, paragraph 55: “resolves the references 230, 232, 234, and 236”) specified by the particular software component (see e.g. Kuesel, paragraph 55: “Once the executable code 228 is assigned to a processor, the linker resolves the references 230, 232, 234, and 236. In this embodiment, the linker is a dynamic linker that allows the system to postpone resolving the references 230, 232, 234, and 236 until the executable code 228 is assigned for execution. Before or during the execution of the executable code 228, the linker uses the references 230, 232, 234, and 236 to locate the associated library and load that library into memory. The references are resolved by ensuring the processor has the information necessary to locate the associated libraries 246 in memory”),
selecting, at least in part via the subsequent execution of the linker component, a second particular implementation of the particular function (see e.g. Kuesel, paragraph 39: “linker 196 may also determine the type of the processor 192 to ensure that the correct optimized code is executed by the processor 192”; and paragraph 56: “the linker can selectively choose the libraries 246 to bring into memory, thereby leaving the other libraries in storage”), different from the first particular implementation, among the plurality of implementations of the particular function (see e.g. Kuesel, paragraph 52: “reference 230 to user subroutine for processor 1 links to the user_sub_proc1 library 238 which contains the executable code associated with user subroutine 204 that is optimized to run on processor 1. The reference 232 to user subroutine for processor 2 links to the user_sub_proc2 library 240. The references 234 and 236 to library subroutines for processor 1 and processor 2 link to lib_sub_proc 1 242 and lib_sub_proc2 244, respectively”; and paragraphs 5, 17)
executing the second particular implementation of the particular function (see e.g. Kuesel, paragraph 72: “At step 430, the assigned processor 192 begins to run the executable code. Once the processor 192 executes object code associated with the resolved reference”; and Fig. 4: “Execute The Optimized Code 430”).
Kuesel discloses a linker 196 that determines an architecture type (i.e. an aspect) of an execution environment and selects particular libraries implementing particular routines/functions for execution based on the determined architecture type.
However, Kuesel does not but Young teaches:
detecting, …, a change in the one or more aspects of the current execution environment (see e.g. Young, paragraph 43: “detects an altered need for resources in an executing application”; and paragraph 47: “altered need may include an executing application having an increased need for the processor 102. For example, in response to a user, the executing application may begin consuming more processor 102 cycles than before. The configuration module 120 may detect the increased processor cycles used by the application and may determine that the application has an increased need to use the processor 102”);
based at least in part on the detected change in the one or more aspects of the current execution environment (see e.g. Young, paragraph 55: “In response to the configuration module 120 detecting an altered need for a resource, the configuration module 120 may load one or more configuration parameters”; paragraph 52: “configuration parameters may include settings and/or any other values or states that may alter or affect execution of the application”; paragraph 58: “configuration parameters may configured processor affinity for the application. For example, a configuration parameters may instruct an operating system to execute the application on a first of four processors. In another embodiment, the configuration may alter a core configuration for a processor. For example, the processor 102 may include four cores. In response to the application using one process, the configuration parameters may instruct the processor 102 to combine more than one core to increase the performance of the resulting core, and the application”; and paragraph 59); and
Kuesel and Young are analogous art because they are in the same field of endeavor: optimizing resource utilization within a computing environment. 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 Kuesel with the teachings of Young. The motivation/suggestion would be to increase the flexibility of the optimization mechanism by adapting to changes in capabilities and execution performance of the computing environment (see e.g. Young, paragraphs 4-6).
Furthermore, even though Kuesel discloses a linker 196 that determines aspects of an execution environment, Kuesel does not explicitly disclose the linker 196 detecting “changes” to the execution environment.
However, Huang teaches:
at least in part via subsequent execution of the linker component (see e.g. Huang, paragraph 72: “initiating a path-change detection of a macro 104… a macro path-check option of the linker 406 is checked, at block 1004. If macro path-check option is not switched ON, for example, via the initiating command (block 502), via an environment variable, or any other setting that the linker 406 can check, the path change detection is terminated, at block 1006. Alternatively, if the setting is switch ON, a record from the macro information 412 is read for further analysis, at block 1008”)
Kuesel and Huang are analogous art because they are in the same field of endeavor: utilizing a linker component to manage aspects of an execution environment. 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 Kuesel with the teachings of Huang. The motivation/suggestion would be to prevent any potential errors that might arise due to changes in the execution environment after linking; thus increasing the overall robustness of the system.
With respect to claim 2, Kuesel as modified teaches: The method of claim 1, wherein the selecting the second particular implementation of the particular function among the plurality of implementations of the particular function is further based at least in part on one or more specified policy parameters (see e.g. Kuesel, paragraph 49: “based on the processor's ID, determine the architecture implementation (and type) of the processor. The selection code 210 then instructs the processor to execute the correct option 214, 220. If the processor is processor 1, then the executable code contained within option 214 is executed while the executable code contained within option 220 is not”).
With respect to claim 3, Kuesel as modified teaches: The method of claim 2, further comprising:
returning a result of the second particular implementation of the particular function (see e.g. Kuesel, paragraph 28: “Upon receiving the job, the multi-nodal system 170 executes the request and then returns the result”; and paragraph 44: “use the printf function (i.e., a subroutine) to display information”); and
continuing to execute the particular software component at least in part utilizing the processor of the computing device (see e.g. Kuesel, paragraph 56: “if the processor reaches reference 230 or 236 while running the executable code 228, it can fetch the executable code found in library 240 or 244 from main memory and continue to execute the thread”).
With respect to claim 4, Kuesel as modified teaches: The method of claim 3, further comprising, responsive at least in part to the second selecting the particular implementation of the particular function (see e.g. Kuesel, paragraph 53: “linker may identify the assigned processor's architecture implementation and parse through the one or more libraries represented by the generic reference to find the library (or portion of a library) that contains the version of the subroutine that corresponds to that architecture implementation”), storing a particular address corresponding to the selected second particular implementation of the particular function in a first table (see e.g. Kuesel, paragraph 39: “linker 196 resolves the references and brings into memory the required libraries”; paragraph 53: “linker may load only that relevant library into memory… Then the linker may resolve the reference by inserting the memory address to the relevant library in memory”; paragraph 55: “the linker uses the references 230, 232, 234, and 236 to locate the associated library and load that library into memory. The references are resolved by ensuring the processor has the information necessary to locate the associated libraries 246 in memory”; and paragraph 36: “one or more memory devices having blocks of memory associated with physical addresses, such as random access memory (RAM), read only memory (ROM), flash memory or other types of volatile and/or non-volatile memory”).
Since Kuesel discloses inserting memory address for the selected routines/functions in the memory in order to enable the processor to access the routines/functions for execution (see e.g. Kuesel, paragraphs 53, 55) and utilizing hardware memory blocks for storage (see e.g. Kuesel, paragraphs 30, 36), Kuesel inherently discloses storing the memory addresses in the memory tables provided by the corresponding memory hardware.
With respect to claim 5, Kuesel as modified teaches: The method of claim 4, further comprising, responsive at least in part to the subsequent call to the particular function during runtime of the particular software component, executing the selected second particular implementation of the particular function based at least in part on the particular address stored in the first table (see e.g. Kuesel, paragraph 55: “linker is a dynamic linker that allows the system to postpone resolving the references 230, 232, 234, and 236 until the executable code 228 is assigned for execution. Before or during the execution of the executable code 228, the linker uses the references 230, 232, 234, and 236 to locate the associated library and load that library into memory”; and paragraph 56: “linker may also resolve the references by changing the references 230, 236 to these libraries within the executable code 228 to point to the memory address of where the libraries are currently stored in memory. Thus, if the processor reaches reference 230 or 236 while running the executable code 228, it can fetch the executable code found in library 240 or 244 from main memory and continue to execute the thread”).
With respect to claim 6, Kuesel as modified teaches: The method of claim 3,
Kuesel does not but Young teaches:
wherein detecting the change in the one or more aspects of the current execution environment comprises determining, at least in part via a subsequent execution of the linker component, the one or more specified policy parameters (see e.g. Young, paragraph 55: “In response to the configuration module 120 detecting an altered need for a resource, the configuration module 120 may load one or more configuration parameters”; paragraph 52: “Settings or configuration parameters, as described herein, may include any and all application settings, operating system settings, driver settings, module settings, hardware settings, virtual settings, or other, or the like. Therefore, in certain embodiments, configuration parameters may include settings and/or any other values or states that may alter or affect execution of the application”).
Kuesel and Young are analogous art because they are in the same field of endeavor: optimizing resource utilization within a computing environment. 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 Kuesel with the teachings of Young. The motivation/suggestion would be to increase the flexibility of the optimization mechanism by adapting to changes in capabilities and execution performance of the computing environment (see e.g. Young, paragraphs 4-6).
With respect to claim 9, Kuesel as modified teaches: The method of claim 2, wherein the one or more aspects of the current execution environment comprise one or more aspects pertaining to available processing resources (see e.g. Kuesel, paragraph 56: “determine the architecture type of the processor… determines that processor is processor 2”; and paragraphs 17-18), memory resources or communication resources, or a combination thereof, and/or wherein the one or more specified policy parameters comprise one or more parameters pertaining to power efficiency, security, privacy or quality of service, or a combination thereof.
With respect to claim 10, Kuesel as modified teaches: The method of claim 2, wherein the plurality of implementations of the particular function are directed to be utilized advantageously in a respective plurality of particular execution environments and/or in connection with particular policy parameters (see e.g. Kuesel, paragraph 39: “To preserve memory space and to reduce the size of the executables, the executable code may contain references to code that is stored in one or more libraries. At runtime, i.e., after the executable code is assigned to a particular processor, the linker 196 resolves the references and brings into memory the required libraries. The linker 196 may also determine the type of the processor 192 to ensure that the correct optimized code is executed by the processor 192”; paragraph 56; and paragraph 57: “Advantageously, dynamically linking may reduce the amount of executable code that is brought into memory 194”).
With respect to claims 11-16, 19, and 20: Claims 11-16, 19, and 20 are directed to an apparatus comprising a processor of a computing device to implement active functions corresponding to the method disclosed in claims 1-6, 9, and 10, respectively; please see the rejections directed to claims 1-6, 9, and 10 above which also cover the limitations recited in claims 11-16, 19, and 20. Note that, Kuesel also discloses an apparatus 190 comprising a computer processor 192 to implement the method disclosed in claims 1-6, 9, and 10 (see e.g. Kuesel, Fig. 1B; paragraphs 33-35).
Claims 7, 8, 17, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Kuesel in view of Young and Huang as applied to claims 1 and 11 above, and further in view of Farnham (US 2021/0135983 A1).
With respect to claim 7, Kuesel as modified teaches: The method of claim 3, … wherein the detecting the change in the one or more aspects of the current execution environment and/or the selecting the second particular implementation of the particular function (see e.g. Kuesel, paragraph 56: “selectively choose the libraries 246 to bring into memory, thereby leaving the other libraries in storage”)
Kuesel does not but Farnham teaches:
wherein the computing device comprises an IoT-type device (see e.g. Farnham, paragraph 120: “different loT devices 616”) and
is performed at least in part via an edge-type computing device (see e.g. Farnham, paragraph 118: “microservice application provides more options for determining which functions of the applications (implemented as microservices) are performed on edge local resources”) coupled to the IoT-type device (see e.g. Farnham, paragraph 120: “The physical network layer 610, comprises edge processing nodes 614, IoT network gateways/routers 612, and various different loT devices 616”; paragraph 121: “Each edge processing device 614 may be used by one or more computational tasks or applications which are distributed over a plurality of processing devices, in the form of a microservice architecture comprising a plurality of microservice instances hosted on the edge processing devices 614”; and Fig. 1).
Kuesel and Farnham are analogous art because they are in the same field of endeavor: determining function implementation execution based on aspects of a computing environment, such as computing environment architecture. 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 Kuesel with the teachings of Farnham. The motivation/suggestion would be to provide a highly reliable, low latency network for the computing environment; thus improving the overall resource utilization (see e.g. Farnham, paragraph 11).
With respect to claim 8, Kuesel teaches: The method of claim 7, wherein the executing the second particular implementation of the particular function comprises executing the second particular implementation of the particular function (see e.g. Kuesel, paragraph 72: “At step 430, the assigned processor 192 begins to run the executable code. Once the processor 192 executes object code associated with the resolved reference”; and Fig. 4: “Execute The Optimized Code 430”),
Kuesel does not but Farnham teaches:
at least in part, at the edge-type computing device (see e.g. Farnham, paragraph 118: “microservice application provides more options for determining which functions of the applications (implemented as microservices) are performed on edge local resources”) and/or at a cloud-based computing device in communication with the IoT-type device (see e.g. Farnham, paragraph 118: “microservice application provides more options for determining which functions of the applications (implemented as microservices) are… performed on cloud resources”).
Kuesel and Farnham are analogous art because they are in the same field of endeavor: determining function implementation execution based on aspects of a computing environment, such as computing environment architecture. 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 Kuesel with the teachings of Farnham. The motivation/suggestion would be to provide a highly reliable, low latency network for the computing environment; thus improving the overall resource utilization (see e.g. Farnham, paragraph 11).
With respect to claims 17 and 18: Claims 17 and 18 are directed to an apparatus comprising a processor of a computing device to implement active functions corresponding to the method disclosed in claims 7 and 8, respectively; please see the rejections directed to claims 7 and 8 above which also cover the limitations recited in claims 17 and 18.
Response to Arguments
Applicant's arguments filed 07/29/2026 have been fully considered but they are not persuasive. In detail:
(i) Regarding claim 1, Applicant argues that Kuesel fails to teach the limitations “selecting, at least in part via the subsequent execution of the linker component, a second particular implementation of the particular function different from the first particular implementation, among the plurality of implementations of the particular function based at least in part on the detected change in the one or more aspects of the current execution environment” because the selection disclosed by Kuesel is done at library-level as opposed to the function-level selection as recited in the claim (Remarks, pages 10-12).
However, note that Kuesel discloses function code being optimized for different processors of a parallel computing system (see Kuesel, paragraph 5: “Source code (i.e., text written using the format and syntax of a programming language) may be compiled such that is optimized to execute on a particular processor. For example, the processor may have a particular functional unit that the executable code can use advantageously”; and paragraph 17: “Parallel computing systems typically include a plurality of compute nodes that contain one or more computer processors”). That is, different implementations of the same function are provided for different processors of the parallel computing system.
Kuesel further discloses the linker 196 component resolving particular implementations of the functions based on processors, such as determining which “user subroutine” to use based on processor 1 or processor 2, or which “library subroutine” to use based on processor 1 or processor 2 (see e.g. Kuesel, paragraph 55: “Once the executable code 228 is assigned to a processor, the linker resolves the references 230, 232, 234, and 236… during the execution of the executable code 228, the linker uses the references 230, 232, 234, and 236 to locate the associated library and load that library into memory. The references are resolved by ensuring the processor has the information necessary to locate the associated libraries 246 in memory”; and Fig. 3). Note that, this resolution process is also implemented dynamically (see Kuesel, paragraph 55: “linker is a dynamic linker that allows the system to postpone resolving the references 230, 232, 234, and 236 until the executable code 228 is assigned for execution”)
Accordingly, the linker 196 picks “user_sub_proc1 230” as the particular implementation of “user subroutine” to invoke if the “user subroutine” call is associated with processor 1 of the parallel computing system, and, in a subsequent execution of the linker 196 if the same “user subroutine” call is associated with processor 2, the linker 196 picks “user_sub_proc2 232”.
That is, at each execution of the linker 192 as part of the dynamic linking, invocations of the same functions (e.g. user subroutine) are resolved to different references based on the processors. Note that, these subroutines are different implementations of the same function based on how they are optimized for different processors (see Kuesel, paragraph 5).
Consequently, Kuesel teaches the limitations “selecting, at least in part via the subsequent execution of the linker component, a second particular implementation of the particular function different from the first particular implementation, among the plurality of implementations of the particular function based at least in part on the detected change in the one or more aspects of the current execution environment” as recited in claim 1, and the Examiner maintains the rejection directed to claim 1. For more details, please see the rejection directed to claim 1 above.
CONCLUSION
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Strihagen (US 2022/0147374 A1) discloses a runtime linker 216 that performs linking based on detecting changes (see paragraph 75).
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
Prosecution Insights