Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This action is responding to the amendment filed on 9/18/2025.
Claims 26-50 are pending in the application.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 26-28 and 31-50 are rejected under 35 U.S.C. 103 as being unpatentable over Gao et al. (US20170123773, hereafter Gao) in view of Li et al. (US20190042395, hereafter Li) and Holzle et al. (US5995754, hereafter Holzle).
Per claim 26:
Gao teaches: A first computing device comprising: at least one programmable circuit; and
a memory including instructions to cause the at least one programmable circuit (Gao, see at least [0052] Processing unit 206, main memory 208, and graphics processor 210 are coupled to North Bridge and memory controller hub (NB/MCH) 202. Processing unit 206 may contain one or more processors and may be implemented using one or more heterogeneous processor systems. Processing unit 206 may be a multi-core processor. Graphics processor 210 may be coupled to NB/MCH 202 through an accelerated graphics port (AGP) in certain implementations);
aggregate performance metrics associated with execution of a first function on a second computing device to generate aggregated performance metrics (Gao, see at least [0023] A dynamic profiler is tool for performance analysis of executable code that measures aspects of the execution such as call frequency, time, memory, other metrics made available by the execution environment, or derived metrics calculated from other metrics, and produces profile information for the code; [0005] The profile information identifying a hot portion having a first degree of hotness. … The embodiment obtains, from the remote optimizing compiler, an object code resulting from compiling the pre-processed source code using the set of compiler options, where the object code is optimized according to the profile information, and the set of environment parameter values. The embodiment builds the executable application using the optimized object code; [0024] The profile information identifies various portions or sections of the source code and associates a degree of hotness or coldness to a portion based on the metrics for that portion. If the profiling information uses one threshold metric A, a portion can be hot or cold when the corresponding metric is greater than A or less than or equal to A, respectively. Similarly, if two thresholds A and B are used, a portion can be hot when the corresponding metric is greater than A, normal when the corresponding metric is greater than B and up to A, or cold when the corresponding metric is up to or lower than B; [0066] profile information associated with some or all such portions—such as whether a function is hot or cold with a corresponding degree of the hotness or coldness, and files in which those portions are located; [0068] A user or a system selects one or more portions from visualization 326. In one embodiment, the selection of a portion is based on whether the portion has a degree of hotness that exceeds a threshold degree of hotness the user or system has selected for the selection; [0029]; [0082]; [0080] in response to sending the profile information or the profile-based selections and the set of environment parameters, the OCaaS to select a set of settings, or compiler options (block 512). The OCaaS uses the set of settings to compile the pre-processed source code; Note that the performance profile data including frequency, execution time (e.g. CPU), memory etc. are collected (i.e. aggregated)).
compiling source code that includes the first function based on the aggregate number of times being determined to meet the threshold to generate machine code that is executable by the second computing device (Gao, see at least [0002] Source code in a high-level programming language is compiled to produce object code. The object code is linked to one or more libraries to produce machine code or executable code. The machine code is executed on a data processing system to perform the operations programmed in the source code; [0071], link with optimized object code 334 in the construction of the executable code corresponding to source code 310; [0023] A dynamic profiler is tool for performance analysis of executable code that measures aspects of the execution such as call frequency, time, memory, other metrics made available by the execution environment, or derived metrics calculated from other metrics, and produces profile information for the code; [0005] The profile information identifying a hot portion having a first degree of hotness. … The embodiment obtains, from the remote optimizing compiler, an object code resulting from compiling the pre-processed source code using the set of compiler options, where the object code is optimized according to the profile information, and the set of environment parameter values. The embodiment builds the executable application using the optimized object code; [0024] The profile information identifies various portions or sections of the source code and associates a degree of hotness or coldness to a portion based on the metrics for that portion. If the profiling information uses one threshold metric A, a portion can be hot or cold when the corresponding metric is greater than A or less than or equal to A, respectively. Similarly, if two thresholds A and B are used, a portion can be hot when the corresponding metric is greater than A, normal when the corresponding metric is greater than B and up to A, or cold when the corresponding metric is up to or lower than B; [0066] profile information associated with some or all such portions—such as whether a function is hot or cold with a corresponding degree of the hotness or coldness, and files in which those portions are located; [0068] A user or a system selects one or more portions from visualization 326. In one embodiment, the selection of a portion is based on whether the portion has a degree of hotness that exceeds a threshold degree of hotness the user or system has selected for the selection; [0029]; [0082]; [0080] in response to sending the profile information or the profile-based selections and the set of environment parameters, the OCaaS to select a set of settings, or compiler options (block 512). The OCaaS uses the set of settings to compile the pre-processed source code; Note that the performance profile data including frequency, execution time (e.g. CPU), memory etc. are collected (i.e. aggregated)).
Gao does not explicitly teach the function is a FaaS function. Li teaches a FaaS architecture (Li, see at lerast [0039], the enhanced architecture 100 may leverage the convenience of FaaS (Function as a Service) and several performance tools/architectures as well as a debug format information, such as symbolic databases 116, 126, to offer application developers the ability to tune applications for various architectures). It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to have combined Li’s FaaS functionwith Gao’s compilation to modify Gao’s system to combine the FaaS function, with a reasonable expectation of success, since they are analogous art because they are from the same field of endeavor related to machine code development or optimization. Combining Li’s functionality with that of Gao results in a system that allows to leverage a FaaS function. The modification would be obvious because one having ordinary skill in the art would be motivated to make this combination to “leverage the convenience of FaaS” without managing servers for faster development and deployment (Li, see at lerast [0039], the enhanced architecture 100 may leverage the convenience of FaaS (Function as a Service) and several performance tools/architectures as well as a debug format information, such as symbolic databases 116, 126, to offer application developers the ability to tune applications for various architectures).
Gao and Li do not explicitly teach the performance metrics including a first value indicating a first number of times that a first portion of the first FaaS function was executed and a second value indicating a second number of times that a second portion of the first FaaS function was executed, the aggregated performance metrics including an aggregate number of times that some portion of the first FaaS function was executed; that the threshold to indicate that the first computing device compiling the source code will consume a lower computational cost than at least the second computing device interpreting the source code. Holzle teaches that the performance metrics including a first value indicating a first number of times that a first portion of the first FaaS function was executed and a second value indicating a second number of times that a second portion of the first FaaS function was executed, the aggregated performance metrics including an aggregate number of times that some portion of the first FaaS function was executed; that the threshold to indicate that the first computing device compiling the source code will consume a lower computational cost than at least the second computing device interpreting the source code. (Holzle, see at least fig. 1 and associated texts, Each method in a byte-coded program may be monitored to determine whether compiling the method would be beneficial to the overall execution of the program. In one embodiment, monitoring a method involves tracking the number of times the method is invoked as an interpreted method. When the invocations of the interpreted method reach a level, or threshold, which indicates that the method is likely to recover compilation costs if compiled, then the method is dynamically compiled; fig. 4-8 and associated texts, A determination is made in step 412 as to whether the counter for method M exceeds the threshold. If the counter for method M does not exceed the threshold, then the indication is that it is not necessary to compile method M. Accordingly, process flow moves from step 412 to step 416 in which method M is executed with an interpreter. Alternatively, if the determination in step 412 is that the counter for method M exceeds the threshold, then the implication is that the execution of the overall program may be more efficient if method M were compiled, rather than interpreted; fig. 1 and associated texts, a counter which is used to count the number of times a method is interpreted. Such a counter may be implemented within a method such that the counter is incremented each time the method is interpreted … Frequently executed code 158 may generally be identified as sections of code which contain methods that account for a significant portion of the execution of the program; fig. 3 and associated texts, memory requirements and performance requirements, of a particular system. By way of example, a threshold may be initialized to be in the range of approximately 1000 to 10,000). It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to have combined Holzle’s execution optimization with Gao’s compilation and Li’s FaaS to modify Gao’s system to combine the optimization as taught by Holzle, with a reasonable expectation of success, since they are analogous art because they are from the same field of endeavor related to machine code development or optimization. Combining Holzle’s functionality with that of Gao and Li results in a system that allows cost efficient optimization. The modification would be obvious because one having ordinary skill in the art would be motivated to make this combination to achieve cost efficient execution in code development and distribution (Holzle, see at least fig. 1 and associated texts, Each method in a byte-coded program may be monitored to determine whether compiling the method would be beneficial to the overall execution of the program. In one embodiment, monitoring a method involves tracking the number of times the method is invoked as an interpreted method. When the invocations of the interpreted method reach a level, or threshold, which indicates that the method is likely to recover compilation costs if compiled, then the method is dynamically compiled; fig. 4-8 and associated texts, A determination is made in step 412 as to whether the counter for method M exceeds the threshold. If the counter for method M does not exceed the threshold, then the indication is that it is not necessary to compile method M. Accordingly, process flow moves from step 412 to step 416 in which method M is executed with an interpreter. Alternatively, if the determination in step 412 is that the counter for method M exceeds the threshold, then the implication is that the execution of the overall program may be more efficient if method M were compiled, rather than interpreted; fig. 3 and associated texts, memory requirements and performance requirements, of a particular system. By way of example, a threshold may be initialized to be in the range of approximately 1000 to 10,000).
27. The first computing device of claim 26, wherein the instructions are to cause one or more of the at least one programmable circuit to: identify at least one first performance metric from the performance metrics, the at least one first performance metric being a first number of invocations of the first FaaS function on the second computing device, the first number of invocations based on at least the first value and the second value; identify at least one second performance metric from the performance metrics, the at least one second performance metric being a second number of invocations of the first FaaS function on third computing device; aggregate the at least one first performance metric and the at least one second performance metric to generate the aggregated performance metrics (Gao, see at least [0023] A dynamic profiler is tool for performance analysis of executable code that measures aspects of the execution such as call frequency, time, memory, other metrics made available by the execution environment, or derived metrics calculated from other metrics, and produces profile information for the code; [0005] The profile information identifying a hot portion having a first degree of hotness. … The embodiment obtains, from the remote optimizing compiler, an object code resulting from compiling the pre-processed source code using the set of compiler options, where the object code is optimized according to the profile information, and the set of environment parameter values. The embodiment builds the executable application using the optimized object code; [0024] The profile information identifies various portions or sections of the source code and associates a degree of hotness or coldness to a portion based on the metrics for that portion. If the profiling information uses one threshold metric A, a portion can be hot or cold when the corresponding metric is greater than A or less than or equal to A, respectively. Similarly, if two thresholds A and B are used, a portion can be hot when the corresponding metric is greater than A, normal when the corresponding metric is greater than B and up to A, or cold when the corresponding metric is up to or lower than B; [0066] profile information associated with some or all such portions—such as whether a function is hot or cold with a corresponding degree of the hotness or coldness, and files in which those portions are located; [0068] A user or a system selects one or more portions from visualization 326. In one embodiment, the selection of a portion is based on whether the portion has a degree of hotness that exceeds a threshold degree of hotness the user or system has selected for the selection; [0029]; [0082]; [0080] in response to sending the profile information or the profile-based selections and the set of environment parameters, the OCaaS to select a set of settings, or compiler options (block 512). The OCaaS uses the set of settings to compile the pre-processed source code). [0023] A dynamic profiler is tool for performance analysis of executable code that measures aspects of the execution such as call frequency, time, memory, other metrics made available by the execution environment, or derived metrics calculated from other metrics, and produces profile information for the code; Note that the performance profile data including frequency, execution time (e.g. CPU), memory etc. are collected (i.e. aggregated) from different devices such as processors, memory, interfaces etc., therefore, the hot or cold spots data associated with the different devices are aggregated).
Per claim 28:
Gao teaches: The first computing device of claim 26, wherein the instructions are to cause one or more of the at least one programmable circuit to: determine a number of invocations associated with execution of the first FaaS function based on the aggregate number of times that some portion of the first FaaS function was execute; determine whether the number of invocations meets the threshold to determine whether the aggregated number of times meets the threshold (Gao, see at least [0024] The profile information identifies various portions or sections of the source code and associates a degree of hotness or coldness to a portion based on the metrics for that portion. If the profiling information uses one threshold metric A, a portion can be hot or cold when the corresponding metric is greater than A or less than or equal to A, respectively. Similarly, if two thresholds A and B are used, a portion can be hot when the corresponding metric is greater than A, normal when the corresponding metric is greater than B and up to A, or cold when the corresponding metric is up to or lower than B; [0066] profile information associated with some or all such portions—such as whether a function is hot or cold with a corresponding degree of the hotness or coldness, and files in which those portions are located; [0068] A user or a system selects one or more portions from visualization 326. In one embodiment, the selection of a portion is based on whether the portion has a degree of hotness that exceeds a threshold degree of hotness the user or system has selected for the selection; [0029]; [0082]; [0080] in response to sending the profile information or the profile-based selections and the set of environment parameters, the OCaaS to select a set of settings, or compiler options (block 512). The OCaaS uses the set of settings to compile the pre-processed source code).
Gao and Li do not explicitly teach determining the threshold based on an estimation of computational cost of the at least one programmable circuit to compile the first FaaS function, the estimation based on one or more of a latency or computing resources associated with compilation of the first FaaS function, and wherein the estimation of the computational cost being less than one or more of latency or computing resource consumption associated with interpreting the first FaaS function. Holzle teaches determining the threshold based on an estimation of computational cost of the at least one programmable circuit to compile the first FaaS function, the estimation based on one or more of a latency or computing resources associated with compilation of the first FaaS function, and wherein the estimation of the computational cost being less than one or more of latency or computing resource consumption associated with interpreting the first FaaS function (Holzle, see at least fig. 1 and associated texts, Each method in a byte-coded program may be monitored to determine whether compiling the method would be beneficial to the overall execution of the program. In one embodiment, monitoring a method involves tracking the number of times the method is invoked as an interpreted method. When the invocations of the interpreted method reach a level, or threshold, which indicates that the method is likely to recover compilation costs if compiled, then the method is dynamically compiled; fig. 4-8 and associated texts, A determination is made in step 412 as to whether the counter for method M exceeds the threshold. If the counter for method M does not exceed the threshold, then the indication is that it is not necessary to compile method M. Accordingly, process flow moves from step 412 to step 416 in which method M is executed with an interpreter. Alternatively, if the determination in step 412 is that the counter for method M exceeds the threshold, then the implication is that the execution of the overall program may be more efficient if method M were compiled, rather than interpreted; fig. 3 and associated texts, memory requirements and performance requirements, of a particular system; fi.g 1 and associated texts, Repeatedly interpreting a method, which is included in frequently executed code 158, may be inefficient, as interpreted byte code 154 generally executes slower, or less efficiently, than compiled code. Compiling frequently executed code 158 generally may allow methods embodied in frequently executed code 158 to be executed more efficiently, as time-savings gained by compiling the method is likely to compensate for the compilation overhead associated with the compilation process; fig. 5 and associated texts, generally reduces the volume of code associated with the overall program … in order to save space and to reduce the amount of compilation … where the compilation overhead is checked; Note that compilation is associated with computation, resource consumption, latency (time delay)). It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to have combined Holzle’s cost saving optimizer with Gao’s compilation and Li’s FaaS to modify Gao’s system to combine the cost saving optimization based evaluation as taught by Holzle, with a reasonable expectation of success, since they are analogous art because they are from the same field of endeavor related to machine code development or optimization. Combining Holzle’s functionality with that of Gao and Li results in a system that allows determining a threshold based on a computational cost. The modification would be obvious because one having ordinary skill in the art would be motivated to make this combination to determine cost saving solution in code development and distribution (Holzle, see at least fig. 1 and associated texts, Each method in a byte-coded program may be monitored to determine whether compiling the method would be beneficial to the overall execution of the program. In one embodiment, monitoring a method involves tracking the number of times the method is invoked as an interpreted method. When the invocations of the interpreted method reach a level, or threshold, which indicates that the method is likely to recover compilation costs if compiled, then the method is dynamically compiled; fig. 4-8 and associated texts, A determination is made in step 412 as to whether the counter for method M exceeds the threshold. If the counter for method M does not exceed the threshold, then the indication is that it is not necessary to compile method M. Accordingly, process flow moves from step 412 to step 416 in which method M is executed with an interpreter. Alternatively, if the determination in step 412 is that the counter for method M exceeds the threshold, then the implication is that the execution of the overall program may be more efficient if method M were compiled, rather than interpreted; fig. 3 and associated texts, memory requirements and performance requirements, of a particular system; fi.g 1 and associated texts, Repeatedly interpreting a method, which is included in frequently executed code 158, may be inefficient, as interpreted byte code 154 generally executes slower, or less efficiently, than compiled code. Compiling frequently executed code 158 generally may allow methods embodied in frequently executed code 158 to be executed more efficiently, as time-savings gained by compiling the method is likely to compensate for the compilation overhead associated with the compilation process; fig. 5 and associated texts, generally reduces the volume of code associated with the overall program … in order to save space and to reduce the amount of compilation … where the compilation overhead is checked; Note that compilation is associated with computation, resource consumption, latency (time delay)).
31. The first computing device of claim 26, wherein the instructions are to cause one or more of the at least one programmable circuit to: identify a hardware profile of the second computing device; and compile the source code including the first FaaS function based on the hardware profile to generate the machine code (Gao, see at least [0023] A dynamic profiler is tool for performance analysis of executable code that measures aspects of the execution such as call frequency, time, memory, other metrics made available by the execution environment, or derived metrics calculated from other metrics, and produces profile information for the code; [0034], configures the OCaaS to use a knowledgebase of compiler settings for various combinations of profile information and platform information; [0027] identifies a set of environment parameters that describe the platform on which the compiled application of the source code is expected to operate; [0075] Component 412 collects actual performance data from an execution of the executable made from the optimized object code, where the execution occurs on the platform; [0032] linking the optimized object code to achieve the expected performance on the platform according to the knowledgebase; [0070] Component 330 detects, receives, or otherwise determines the data processing environment parameters that would be applicable to the platform where the executable of source code 310 will operate; [0033] when the optimized object file is converted to an executable of the application, the embodiment collects actual performance information from the operation of the executable on the platform; Note that a profile of execution time (e.g. CPU), memory etc. are a hardware profile).
Per claim 32, this is the apparatus version of claim 26, respectively, and are rejected for the same reasons set forth in connection with the rejection of claim 26 above. Gao further teaches: A semiconductor apparatus of a first computing device, comprising: one or more substrates; and logic coupled to the one or more substrates wherein the logic is implemented in one or more of configurable logic or fixed-functionality hardware logic, the logic coupled to the one or more substrates to: (Gao, see at least [0052] Processing unit 206, main memory 208, and graphics processor 210 are coupled to North Bridge and memory controller hub (NB/MCH) 202. Processing unit 206 may contain one or more processors and may be implemented using one or more heterogeneous processor systems. Processing unit 206 may be a multi-core processor. Graphics processor 210 may be coupled to NB/MCH 202 through an accelerated graphics port (AGP) in certain implementations; [0087], electronic circuit including, for example, programmable logic circuit, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuit).
Per claims 33, 34, and 37, they are the apparatus versions of claims 27, 28, and 31, respectively, and are rejected for the same reasons set forth in connection with the rejection of claims 27, 28, and 31 above.
36. The semiconductor apparatus of claim 32, wherein the second computing device is to execute the machine code (Gao, see at least [0027] An embodiment further identifies a set of environment parameters that describe the platform on which the compiled application of the source code is expected to operate; [0075] Component 412 collects actual performance data from an execution of the executable made from the optimized object code, where the execution occurs on the platform).
38. The semiconductor apparatus of claim 32, wherein the logic circuit includes transistor channel regions that are positioned within the one or more substrate (Gao, see at least [0052] Processing unit 206, main memory 208, and graphics processor 210 are coupled to North Bridge and memory controller hub (NB/MCH) 202. Processing unit 206 may contain one or more processors and may be implemented using one or more heterogeneous processor systems. Processing unit 206 may be a multi-core processor. Graphics processor 210 may be coupled to NB/MCH 202 through an accelerated graphics port (AGP) in certain implementations; [0087], electronic circuit including, for example, programmable logic circuit, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuit; Note that transistors are core elements of electronic circuit).
Per claims 39-41, 43 and 44, they are the medium versions of claims 26-28, 31, and 36 respectively, and are rejected for the same reasons set forth in connection with the rejection of claims 26-28, 31, and 36 above.
Per claims 45-47, 49, and 50, they are the method versions of claims 26-28, 31, and 36 respectively, and are rejected for the same reasons set forth in connection with the rejection of claims 26-28, 31, and 36 above.
Claims 29, 30, 35, 42, and 48 are rejected under 35 U.S.C. 103 as being unpatentable over Gao in view of Li, Holzle and Shotchat et al. (US20130024731, hereafter Shochat).
Per claim 29:
Gao teaches: propagate the machine code to the at least one second computing device (Gao, see at least [0027] An embodiment further identifies a set of environment parameters that describe the platform on which the compiled application of the source code is expected to operate; [0075] Component 412 collects actual performance data from an execution of the executable made from the optimized object code, where the execution occurs on the platform; [0032] linking the optimized object code to achieve the expected performance on the platform according to the knowledgebase; [0070] Component 330 detects, receives, or otherwise determines the data processing environment parameters that would be applicable to the platform where the executable of source code 310 will operate; [0033] when the optimized object file is converted to an executable of the application, the embodiment collects actual performance information from the operation of the executable on the platform. The embodiment provides the profile information, the set of environment parameters, and the actual performance data to create or modify an entry in the knowledgebase for future use).
Gao in view of Li and Holzle does not explicitly teach the first value being normalized based on a first duration during which a first counter counted the first value, the second value being normalized based on a second duration during which a second counter counted the second value. Shochat teaches the first value being normalized based on a first duration during which a first counter counted the first value, the second value being normalized based on a second duration during which a second counter counted the second value (Shochat, see at least [0040] collect and aggregate measured process performance information; [0062] Optionally, as the collected counters are dependent on the duration of capture, with longer durations generating higher counts, performing further analysis of multiple system sessions would require normalizing the measurements with respect to time to a form that isn't dependent on the capture time frame). It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to have combined Shochat’s normalization with Holzle, Gao, and Li’s system to modify Gao’s system to combine the normalization as taught by Shochat, with a reasonable expectation of success, since they are analogous art because they are from the same field of endeavor related to code development or performance monitoring or optimization. Combining Shochat’s functionality with that of Gao, Holzle and Li results in a system that allows applying normalization. The modification would be obvious because one having ordinary skill in the art would be motivated to make this combination to normalize performance measurements for a specific scale (Shochat, see at least [0040] collect and aggregate measured process performance information; [0062] Optionally, as the collected counters are dependent on the duration of capture, with longer durations generating higher counts, performing further analysis of multiple system sessions would require normalizing the measurements with respect to time to a form that isn't dependent on the capture time frame).
30. The first computing device of claim 29, wherein the second computing device is to execute the machine code (Gao, see at least [0027] An embodiment further identifies a set of environment parameters that describe the platform on which the compiled application of the source code is expected to operate; [0075] Component 412 collects actual performance data from an execution of the executable made from the optimized object code, where the execution occurs on the platform).
Per claims 35, 42, and 48, they are the apparatus, medium and method versions of claim 29 respectively, and are rejected for the same reasons set forth in connection with the rejection of claim 29 above.
Examiner’s Note
The Examiner has pointed out particular references contained in the prior art of record within the body of this action for the convenience of the Applicant. 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. Applicant, in preparing the response, should consider fully the entire reference 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.
Response to Arguments
Applicant’s arguments with respect to claim(s) 26-50 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
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to INSUN KANG whose telephone number is (571)272-3724. The examiner can normally be reached M-TR 8 -5pm; week 2: Tu-F 8-5pm.
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, Chat Do can be reached on 571-272-3721. 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.
/INSUN KANG/PRIMARY EXAMINER, ART UNIT 2193
Prosecution Insights