DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Examiner Notes
Examiner cites particular columns and line numbers in the references as applied to the claims below 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 as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in 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.
The examiner encourages Applicant to submit an authorization to communicate with the examiner via the Internet by making the following statement (from MPEP 502.03):
“Recognizing that Internet communications are not secure, I hereby authorize the USPTO to communicate with the undersigned and practitioners in accordance with 37 CFR 1.33 and 37 CFR 1.34 concerning any subject matter of this application by video conferencing, instant messaging, or electronic mail. I understand that a copy of these communications will be made of record in the application file.”
Please note that the above statement can only be submitted via Central Fax, Regular postal mail, or EFS Web (PTO/SB/439).
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claim 10 rejected under 35 U.S.C. § 101 because the claimed invention is directed to non-statutory subject matter.
During examination, the claims must be interpreted as broadly as their terms reasonably allow. In re American Academy of Science Tech Center, 367 F.3d 1359, 1369, 70 U.S.P.Q.2d 1827, 1834 (Fed. Cir. 2004). Independent claim 10 recites a “device,” which is not comprehensively defined by the specification. The broadest reasonable interpretation of a claim drawn to a system covers software per se in view of the ordinary and customary meaning of “device,” particularly when the specification is silent. Software per se is not a “process,” a “machine,” a “manufacture,” or a “composition of matter” as defined in 35 U.S.C. § 101. Examiner suggests adding a recitation of a “processor” and a “memory.”
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-5 and 7-10 are rejected under 35 U.S.C. 103 as being unpatentable over Pilkington et al. (US 10884764) in view of Boilen et al. (US 20200210216).
As per claim 1, Pilkington teaches the invention substantially as claimed including a method for resource allocation for applications and/or application containers (Column 6, Lines 38-42, a managed runtime application may be started, instantiated and run on a virtual machine created by a runtime in a serverless environment, with a profiling agent for profiling the application) in a distributed system (Column 4, Lines 39-46, Nodes 10 may communicate with one another. They may be grouped (not shown) physically or virtually, in one or more networks, such as Private, Community, Public, or Hybrid clouds as described hereinabove, or a combination thereof. This allows cloud computing environment 50 to offer infrastructure, platforms and/or software as services for which a cloud consumer does not need to maintain resources on a local computing device) of heterogeneous compute nodes which are heterogeneous at least with respect to their hardware platforms and/or operating systems (Column 3, Lines 2-4, implementations of the present disclosure are capable of being implemented in conjunction with any type of computing, processing and/or data storage environment; and Column 4, Lines 33-39, cloud computing environment 50 includes one or more cloud computing nodes 10 with which local computing devices used by cloud consumers, such as, for example, personal digital assistant (PDA) or cellular telephone 54A, desktop computer 54B, laptop computer 54C, and/or automobile computer system 54N may communicate), the method comprising the following steps:
executing at least one application of the applications and/or at least one container of the application containers (Column 7, Lines 27-30, during execution of the application by the virtual machine, the profiling agent records method invocations against corresponding intermediate code (e.g., classes and associated bytecode) ) based on an intermediate instruction set architecture using a runtime environment (Column 7, Lines 4-8, receives a request to run a managed runtime application in a serverless environment. As the skilled person will appreciate, the runtime application comprises intermediate code executable by a suitable virtual machine; and Column 7, Lines 31-37, the profiling agent may keep a separate record of the invocations of each method of a class, which corresponds to the invocation of the bytecode corresponding to the method. Accordingly, in the following description, the term “bytecode method” is used to refer an individual method of a class, which is invoked by the execution of corresponding bytecode), wherein the runtime environment is provided on at least one of the compute nodes (Column 7, Lines 24-26, the method starts up a virtual machine, and at step 340 starts to run the application using the virtual machine with the profiling agent; Examiner Note: Pilkington’s distributed system hosts virtual machines: Column 17, Lines 6-9, Distributed computer system 710 of the example implementation shown in FIG. 7 is configured to execute managed runtime software applications received from a consumer in the serverless environment 700; and Column 17, Lines 34-38, memory 720 comprises a virtual machine 780 for executing applications 760 (i.e., a managed runtime application 762 or an optimized application 764) in the serverless environment 700, in response to consumer requests); [and]
carrying out resource monitoring of resource usage at the at least one compute node using the runtime environment (Column 3, Lines 42-44, Resource usage can be monitored, controlled, and reported, providing transparency for both the provider and consumer of the utilized service; Column 7, Lines 20-23, receives a profiling agent for profiling the application. In particular, the profiling agent is configured to record the methods invoked whilst running the application; and Column 7, Lines 45-51, the method stores the method invocation statistics. The method invocation statistics may include, for example, an identifier for each method that was invoked during execution of the application (e.g., with reference to a class and bytecode, or equivalent), and the number of times the method was invoked), wherein the resource monitoring is carried out based on the intermediate instruction set architecture (Column 3, Lines 42-44, Resource usage can be monitored, controlled, and reported, providing transparency for both the provider and consumer of the utilized service; and Column 7, Lines 27-30, during execution of the application by the virtual machine, the profiling agent records method invocations against corresponding intermediate code (e.g., classes and associated bytecode)).
Pilkington fails to specifically teach, carrying out resource allocation based on the resource monitoring that has been carried out. However, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include this step because Pilkington teaches executing an optimized application in the information system which cannot be accomplished without allocating resources for said executing. (Column 8, Lines 5-7, the method sends the method invocation statistics to the service provider for the serverless service for optimization of the managed runtime application; Column 8, Lines 19-26, the serverless service of the service provider receives the method invocation statistics for the runtime application and generates an optimized application. The optimized application is then to be used by the serverless service to startup, instantiate and execute the runtime application in response to future consumer requests, for improved performance in the serverless environment; and Column 8, Lines 31-39, the generation of an optimized application for a runtime application uses a combination of techniques, which together lead to improved performance in a serverless environment. In particular, the inventors have realized that the optimization of a managed runtime application for running in a serverless environment needs to strike a balance two conflicting strategies for reducing overall execution time and resource consumption in the serverless environment).
Furthermore, Boilen teaches, carrying out resource allocation based on the resource monitoring that has been carried out. ([0024], The virtual machine may be divided into multiple separate and private sub-environments, and each tenant of the application server may be allocated one or more of these private environments to run a program. In some cases, this allocation may be performed on the fly at the application server to dynamically manage the load on the virtual machine; and [0050], application server 210 (e.g., via the virtual machine 215 or sandbox 220-a) may use the injected resource usage checks to monitor resource usage of the execution process).
Pilkington and Boilen are analogous because they are each related to application profiling and resource management. Pilkington teaches a method of improving system performance and resource usage by optimizing runtime applications. (Column 5, Lines 33-36, Example implementations of the present disclosure include systems, methods and computer program products for optimizing managed runtime software applications to provide improved performance in a serverless environment; Column 5, Lines 44-48, optimizing such a managed runtime application to improve execution parameters, such as increasing the speed of execution and reducing the resources consumed during execution, in order to improve performance in a serverless environment; and Column 6, Lines 32-37, Example implementations of the present disclosure concern improved systems, methods and computer program products that optimize managed runtime applications for a serverless environment to provide improved performance, such as reduced startup/execution time and resource consumption during initialization and execution). Boilen teaches a method of application profiling and resource management to optimize system performance in a heterogenous environment. (Abstract, application server may host a virtual machine with multiple isolated sub-environments. Each tenant of the application server may request to run a program in a tenant-specific sub-environment of the virtual machine. The sub-environments may be configured so the execution of one tenant's code does not affect execution of another tenant's code or the hosting virtual machine, for example, by considering the resources used to execute the code. The application server may implement techniques to securely execute “untrusted” code, programmed using one or more different programming languages, in the sub-environments by enforcing resource restrictions and restricting the sub-environments from accessing the host's local file system; [0014], the sandboxes within the virtual machine may require additional securities and/or checks to ensure fair sharing of resources and secure multi-tenant operation; and [0016], a sandbox and may replace the call with another call to a parallel class that does support instrumentation (or that already includes resource usage checks). Based on this instrumentation support, the application server may modify the bytecode for the parallel classes to use the injected resource usage checks). It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention that based on the combination, Pilkington’s profiling mechanism would be modified to include the resource allocation mechanism and resource usage monitoring mechanisms as taught by Boilen resulting in a system that profiles and executes applications while managing resource allocation and usage in a heterogenous environment. Therefore, it would have been obvious to combine the teachings of Pilkington and Boilen.
As per claim 2, Boilen teaches, wherein the runtime environment carries out management of the executed application and/or application container ([0016], a sandbox and may replace the call with another call to a parallel class that does support instrumentation (or that already includes resource usage checks). Based on this instrumentation support, the application server may modify the bytecode for the parallel classes to use the injected resource usage checks; and [0024], and each tenant of the application server may be allocated one or more of these private environments to run a program. In some cases, this allocation may be performed on the fly at the application server to dynamically manage the load on the virtual machine) and isolates the executed application and/or application container from the other applications and/or application containers in the distributed system ([0012], The virtual machine may be divided into multiple, isolated virtual environments, and each tenant of the application server may be allocated one or more of these private environments to run a program. The sub-environments, referred to as “sandboxes” or tenant-protected spaces, may be configured to be isolated so that one tenant's program does not interfere with another tenant's program or cause problems with the virtual machine at large).
As per claim 3, Boilen teaches, wherein the heterogeneous compute nodes have different operating systems and architectures, such that the heterogeneous compute nodes differ with respect to their resource management mechanisms ([0035], The tenant may use the user device 205 to execute code and run programs in the sandbox 220-a. In some cases, the sandboxes 220 may be of different sizes, have different resource usage restrictions, or have other varying configurations (e.g., based on tenant-specific access configurations or permissions at the application server 210)), wherein uniform resource management is provided across the different hardware platforms of the compute nodes based on the intermediate instruction set architecture ([0027], The application server may implement an API for tenants to use for running unsafe code securely within the sandboxes. Some unsafe code may, by default, not consider CPU or heap restrictions. Therefore, the application server may implement usage checks when executing the unsafe code to prevent one sandbox from using an amount of CPU time or application server memory greater than a resource limit for the corresponding tenant. ... using the techniques described herein, an application server may support safe execution of code (e.g., unsafe code or non-platform specific code) in a multi-tenant virtual machine with isolated sub-environments for each of the tenants).
As per claim 4, Boilen teaches, wherein the runtime environment has at least one mechanism for enforcing resources based on the resource monitoring that has been carried out ([0015], the virtual machine may insert additional portions or snippets of bytecode to check the resource usage and enforce static or dynamic resource limits; and [0016], a sandbox and may replace the call with another call to a parallel class that does support instrumentation (or that already includes resource usage checks). Based on this instrumentation support, the application server may modify the bytecode for the parallel classes to use the injected resource usage checks), including terminating the executed application when a limit value is exceeded by the resource usage of the executed application ([0015], the virtual machine may insert additional portions or snippets of bytecode to check the resource usage and enforce static or dynamic resource limits; and [0050], During execution, the application server 210 (e.g., via the virtual machine 215 or sandbox 220-a) may use the injected resource usage checks to monitor resource usage of the execution process. If a resource usage check identifies a resource usage for executing the code that surpasses a resource threshold (e.g., a common threshold, a tenant-specific threshold, etc. corresponding to the CPU time, the heap memory usage, or both), the code execution may be halted prior to completion of executing the code).
As per claim 5, Pilkington teaches, wherein the executed application is provided in a bytecode, which is interpreted by the runtime environment for executing the application (Column 1, Lines 17-19, The managed runtime application comprises code defining a plurality of classes, each class including bytecode for one or more methods associated with the class; and Column 18, Lines 47-56, Application execution module 782 comprises instructions for retrieving and executing applications 760, such as managed runtime applications 762 and optimized applications 764. In particular, at startup and instantiation of an application 760, application execution module 782 retrieves and scans the application 760, loads classes and corresponding bytecode to a local class library 786, generates associated object instances, and then executes the intermediate code using an appropriate interpreter (not shown) and at least one processor 730, as well known in the art).
As per claim 7, Pilkington teaches, wherein the runtime environment is implemented as a virtual machine including the intermediate instruction set architecture (Column 6, Lines 38-42, a managed runtime application may be started, instantiated and run on a virtual machine created by a runtime in a serverless environment, with a profiling agent for profiling the application).
As per claim 8, Pilkington teaches, wherein the application is instrumented (Column 1, Line 66-Column 2, Line 4, retrieving the managed runtime application, and selectively replacing bytecode for at least one method of a class of the managed runtime application with proxy code based on the method invocation statistics. The proxy code is configured for retrieving the replaced bytecode) and monitored by the runtime environment (Column 2, Lines 18-29, An optimized version of the managed runtime application is executed with a feedback mechanism. The feedback mechanism records invocations of at least one of proxy code in the optimized application and classes removed from the optimized application during execution of the optimized application. The feedback mechanism optionally records methods invoked during execution of the optimized application. The feedback mechanism stores the recorded invocations, in response to an indication that execution of the optimized application is complete, for use in generating an updated optimized application) based on an evaluation of intermediate instructions of the application (Column 2, Lines 10-15, Methods recorded as invoked by the profiling agent are stored as method invocation statistics, in response to an indication that execution of the managed runtime application is complete, for use in generating an optimized version of the managed runtime application) including a counting of a number of the intermediate instructions (Column 8, Lines 46-51, the method stores the method invocation statistics. The method invocation statistics may include, for example, an identifier for each method that was invoked during execution of the application (e.g., with reference to a class and bytecode, or equivalent), and the number of times the method was invoked), wherein for this purpose, an intermediate code of the application is supplemented by an instrumentation code (Column 2, Lines 10-15, Methods recorded as invoked by the profiling agent are stored as method invocation statistics, in response to an indication that execution of the managed runtime application is complete, for use in generating an optimized version of the managed runtime application; Column 2, Lines 18-30, An optimized version of the managed runtime application is executed with a feedback mechanism. The feedback mechanism records invocations of at least one of proxy code in the optimized application and classes removed from the optimized application during execution of the optimized application. The feedback mechanism optionally records methods invoked during execution of the optimized application. The feedback mechanism stores the recorded invocations, in response to an indication that execution of the optimized application is complete, for use in generating an updated optimized application; and Column 16, Lines 4-9, if step 660 determines that the number of times the bytecode method is invoked is below the predetermined threshold, the method proceeds to step 680 which retains the proxy code in the updated optimized application. In particular, the proxy code is retained in place of the bytecode in the updated optimized application).
As per claim 9, this is the “non-transitory computer-readable medium claim” corresponding to claim 1 and is rejected for the same reasons. The same motivation used in the rejection of claim 1 is applicable to the instant claim.
As per claim 10, this is the “device claim” corresponding to claim 1 and is rejected for the same reasons. The same motivation used in the rejection of claim 1 is applicable to the instant claim.
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over the combination of Pilkington-Boilen and in further view of Neundorffer et al. (US 10671779).
As per claim 6, The combination of Pilkington-Boilen fails to specifically teach, wherein the resource monitoring is carried out based on a cost model which is specific to the hardware platforms of the compute nodes and in which costs are defined based on individual intermediate instructions according to the intermediate instruction set architecture.
However, Neundorffer teaches, wherein the resource monitoring is carried out based on a cost model which is specific to the hardware platforms of the compute nodes (Column 16, Lines 7-24, the system is capable of profiling the hardware implementation(s) of the application. For example, the system is capable of determining an implementation cost of the third function. The implementation cost may be measured in terms of size of the hardware implementation of function H... The system is capable of comparing hardware implementation cost of function H with a threshold hardware implementation cost. In response to determining that the hardware implementation cost of function H exceeds the threshold hardware implementation cost (e.g., and that function G should be implemented in parallel per above criteria), the system is capable of determining that circuit architecture 600 is suitable for implementing functions G and H; and Column 16, Lines 27-32, the system is capable of generating multiple different circuit architectures (e.g., in RTL), simulating such architectures using a user provided test bench, comparing performance of the different circuit architectures, and selecting a particular circuit architecture for use in hardware accelerating the application) and in which costs are defined based on individual intermediate instructions according to the intermediate instruction set architecture (Column 6, Lines 6-16, system 100 operates on application 135. System 100, for example, may analyze the source code of application 135, detect particular constructs within the source code, and perform compilation to generate circuit design 140 based on the constructs detected within application 135. In one or more embodiments, system 100 may generate an intermediate representation (IR) of application 135. For example, system 100 may translate application 135 into an IR as part of compilation and perform the analysis and further compilation and/or translation on the IR to generate hardware (e.g., circuit design 140; Column 16, Lines 8-12, he system is capable of determining an implementation cost of the third function. The implementation cost may be measured in terms of size of the hardware implementation of function H).
The combination of Pilkington-Boilen and Neundorffer are analogous because they are each related to application profiling and resource management. Pilkington teaches a method of improving system performance and resource usage by optimizing runtime applications. Boilen teaches a method of application profiling and resource management to optimize system performance in a heterogenous environment. Neundorffer teaches a method of circuit design for running applications based on application profiling and resource costs. (Column 15, Lines 35-42, the system is capable of profiling different functions of the application to determine the amount of time that each function contributes to runtime of the application. The amount of time that a function contributes to the runtime of the application may be characterized in terms of the number of times that the function is called during execution of the application, the amount of time the function takes to execute for each call, or both; Column 16, Lines 8-12, the system is capable of determining an implementation cost of the third function. The implementation cost may be measured in terms of size of the hardware implementation of function H; and Column 16, Lines 27-32, the system is capable of generating multiple different circuit architectures (e.g., in RTL), simulating such architectures using a user provided test bench, comparing performance of the different circuit architectures, and selecting a particular circuit architecture for use in hardware accelerating the application). It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention that based on the combination, profiling mechanism taught by the combination of Pilkington-Boilen would be modified to include the cost comparison model as taught by Neundorffer resulting in a system that profiles and executes applications while managing resource allocation and costs in a heterogenous environment. Therefore, it would have been obvious to combine the teachings of the combination of Pilkington-Boilen and Neundorffer.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MELISSA A HEADLY whose telephone number is (571)272-1972. The examiner can normally be reached Monday- Friday 9-5:30pm.
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, Bradley Teets can be reached at 571-272-3338. 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.
/MELISSA A HEADLY/ Examiner, Art Unit 2197