DETAILED ACTION
Claims 1-8 and 11-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.
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Amendments to the abstract, paragraph [0092], and paragraph [0100] of the disclosure are fully considered and are satisfactory to overcome the objections directed to the specification in the previous Office Action.
Amendments to claim 7 are fully considered and are satisfactory to overcome the objections directed to the claims in the previous Office Action.
Amendments to claim 11 are fully considered and are satisfactory to overcome the rejections under 35 U.S.C. §112(b) directed to claims 11-20 in the previous Office Action.
Amendments to claims 1 and 11 are fully considered and are satisfactory to overcome the rejections under 35 U.S.C. §101 directed to claims 1-20 in the previous Office Action.
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”).
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… 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 a second particular implementation 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”)
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).
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 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 06/27/2025 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 a first particular implementation of the particular function among a plurality of implementations of the particular function” and “selecting a second particular implementation of the particular function” 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 19-22).
However, note that the library disclosed by Kuesel refers to a library of subroutines/functions, such as a printf function (see e.g. Kuesel, paragraph 44: “library subroutine 206 represents calls in the source code 202 to subroutines that are found in standard or customized libraries. For example, the C programming language includes a standard library--stdio.h--that permits a user to use the printf function (i.e., a subroutine) to display information”), and the selection of the library is a selection of particular function implementations provided within the selected library (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”).
Consequently, Kuesel teaches the limitations “selecting a first particular implementation of the particular function among a plurality of implementations of the particular function” and “selecting a second particular implementation of the particular function” 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.
(ii) With respect to Applicant’s arguments regarding the rejections under 35 U.S.C. §103 directed to claim 7 (see Remarks, pages 22-24), the Examiner notes that the motivation/suggestion for modifying Kuesel with the teachings of Farnham would be to provide a highly reliable, low latency network for the computing environment; thus improving the overall resource utilization. This motivation/suggestion is based on the teachings of Farnham (see e.g. Farnham, paragraph 11: “ Service meshes have historically been supported by high reliability, low latency networks. However, in some circumstances it may be advantageous to implement service meshes on dynamic networks which may experience changes in network performance. For example, a service mesh may be hosted on networks comprising both cloud resources, which are dynamically scalable in a cost effective manner, and local edge resources communicating via local network connections which may offer higher bandwidth and lower latency performance”) which is provided both in this and previous Office Actions.
As such, the Examiner maintains the rejections directed to claim 7. For more details, please see the corresponding rejection above.
Applicant’s arguments with respect to the limitations “detecting a change in the one or more aspects of the current execution environment” and “based at least in part on the detected change in the one or more aspects of the current execution environment” recited in claim 1, and the similar limitations recited in claim 11, 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.
CONCLUSION
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Badic et al. (US 2020/0229206 A1; hereinafter Badic) discloses determining an updated processing offload configuration and selecting an updated processing function for the updated processing offload configuration in (see paragraph 742).
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
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