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 .
This Office Action is in response to claims filed on 02/25/2026.
Claims 23-74 are pending.
Claims 23-25, 27-30, 32-39, 41-43, 45-52, 54-56, 58-65, 67-69, and 71-74 are rejected under 35 U.S.C. 103 as being unpatentable over Paraschiv (US 2021/0211391 A1) in view of Derdak (US 2020/0241944 A1) in view of Liu (US 2018/0293150 A1).
With regard to claim 23, Paraschiv teaches:
A method, comprising: either obtaining, by a service virtual instance, program code from a tenant, or downloading, by the service virtual instance, the program code from another device, “In a functional programming methodology, a client of a computing service may simply specify the function or programs to be executed on the client's behalf, without acquiring any specific computing resources in advance” [Paraschiv ¶ 30]. “As shown, system 100 includes resources of a network-accessible virtualized computing service (VCS) 110 of a provider network 102. The VCS 110 may include a plurality of virtualization hosts (VHs) 132, such as 132A and 132B, which may be used to launch compute instances on behalf of VCS clients” [Paraschiv ¶ 36]. “In a functional programming methodology, a client of a computing service may simply specify the function or programs to be executed on the client's behalf, without acquiring any specific computing resources in advance” [Paraschiv ¶ 30].
wherein the program code comprises main program code and subroutine code, “The compute instances and virtualization hosts 132 may be considered part of the data plane of the VCS 110, used primarily for client applications and associated data” [Paraschiv ¶ 36]. “The functional programming orchestration manager (e.g., comprising one or more processes or threads) may cause a specified function (subroutine code) to be executed or implemented at a CCI launched for the function based on the client-selected scaling policy, and terminate the CCI after the function has been executed and results or output of the function have been collected” [Paraschiv ¶ 30].
wherein the first configuration information is after the symbol tag, “Instead of requesting the redistribution of the resources manually every time, the client may prefer to specify one or more customizable policies (e.g., collections of rules describing the resource redistributions desired) which can be used to automatically initiate the resource redistributions” [Paraschiv ¶ 17]. “In one embodiment, based on the scaling policy, the state of a CCI may be stored, e.g., to persistent storage in the form of a snapshot (configuration information), and the snapshot may later be used to launch another CCI (e.g., with a modified resource allocation relative to the CCI whose state was saved)” [Paraschiv ¶ 27].“In at least one embodiment, a client may specify a machine image which is to be used for a CCI; for example, identifiers (configuration information) of various pre-created machine images to be used for various CCIs launched in accordance with the triggering conditions of the scaling policy may also be included in the scaling policy” [Paraschiv ¶ 25].
wherein the first configuration information indicates a virtual instance specification, and wherein the virtual instance specification comprises or specifies a processor core number and a memory size; “An instance type may be characterized by its hardware type, computational resources (e.g., number, type, and configuration of central processing units [CPUs] or CPU cores), memory resources (e.g., capacity, type, and configuration of local memory), storage resources (e.g., capacity, type, and configuration of locally accessible storage), network resources (e.g., characteristics of its network interface and/or network capabilities), and/or other suitable descriptive characteristics” [Paraschiv ¶ 36]. “Metadata generated and stored for such a snapshot may indicate a default set of resources to be used when launching a CCI from the snapshot in some embodiments: for example, a default amount of memory, a default number of CPUs, a default collection of networking devices, and/or a default amount of persistent storage may be indicated in the metadata” [Paraschiv ¶ 27].
sending, by the service virtual instance, the subroutine code to a cloud platform; “An API refers to an interface and/or communication protocol between a client and a server, such that if the client makes a request in a predefined format, the client should receive a response in a specific format or initiate a defined action. In the cloud provider network context, APIs provide a gateway for customers to access cloud infrastructure by allowing customers to obtain data from or cause actions within the cloud provider network” [Parschiv ¶ 38]. “The parent CI may include one or more functional programming orchestration managers in such embodiments, configured to receive programmatic representations of functions to be implemented to perform a computation on behalf of a client” [Paraschiv ¶ 30]. “The cloud can provide convenient, on-demand network access to a shared pool of configurable computing resources that can be programmatically provisioned and released in response to customer commands” [Paraschiv ¶ 21]. “A local instance scaling manager (LISM), e.g., comprising one or more user-mode processes, may be set up within a parent compute instance to facilitate such automated rule-driven resource redistributions in at least some embodiments” [Parashiv ¶ 18].
configuring, by the cloud platform, at least one first virtual instance on at least one data center, wherein the at least one first virtual instance is matched with the first configuration information of the first annotation, “A compute instance such as a virtual machine may be instantiated at a virtualization host of the service on behalf of a client, and allocated a set of resources (e.g., CPUs, memory, storage, etc.), based for example on a resource specification of a particular category of a set of pre-defined instance categories of the service” [Paraschiv ¶ 16]. “In at least one embodiment, based on a scaling policy, a CCI (child compute instance) may be created to run such a function or program on demand, and the CCI may be terminated after the results of the function or program are obtained” [Paraschiv ¶ 30]. “The container manager may receive an indication (e.g., a container image identifier) of the desired software container programmatically from a client, e.g., as part of the scaling policy, and cause the container to be run within a CCI launched specifically for the container” [Paraschiv ¶ 31].
and wherein configuring the at least one first virtual instance comprises either creating, by the cloud platform, the at least one first virtual instance on the at least one data center, or selecting, by the cloud platform, the at least one first virtual instance from a plurality of virtual instances which are pre-created by the cloud platform on the at least one data center, wherein the at least one first virtual instance is configured with the virtual instance specification; “A compute instance such as a virtual machine may be instantiated at a virtualization host of the service on behalf of a client, and allocated a set of resources (e.g., CPUs, memory, storage, etc.), based for example on a resource specification of a particular category of a set of pre-defined instance categories of the service” [Paraschiv ¶ 16]. “In at least one embodiment, based on a scaling policy, a CCI (child compute instance) may be created to run such a function or program on demand, and the CCI may be terminated after the results of the function or program are obtained” [Paraschiv ¶ 30].
receiving, by the at least one first virtual instance, the subroutine code from the cloud platform; running, by the at least one first virtual instance, the subroutine code to obtain the at least one running result; “In at least one embodiment, based on a scaling policy, a CCI may be created to run such a function or program on demand, and the CCI may be terminated after the results of the function or program are obtained” [Paraschiv ¶ 30].
sending, by the at least one first virtual instance, the at least one running result of the subroutine code to the cloud platform; receiving, by the service virtual instance, the at least one running result from the cloud platform; “The functional programming orchestration manager (e.g., comprising one or more processes or threads) may cause a specified function to be executed or implemented at a CCI launched for the function based on the client-selected scaling policy, and terminate the CCI after the function has been executed and results or output of the function have been collected” [Paraschiv ¶ 30].
wherein the at least one first virtual instance is released after the at least one running result of the subroutine code is sent. “The cloud can provide convenient, on-demand network access to a shared pool of configurable computing resources that can be pro grammatically provisioned and released in response to customer commands” [Paraschiv ¶ 21]. “As part of a resource redistribution triggered by a client-specified policy, in at least some embodiments the number of child compute instances of a parent compute instance may be increased (by launching additional CCIs, each allocated some of the parent Cl's resources) or decreased (by terminating existing CCIs and returning their resources to the parent CI)” [Paraschiv ¶ 27].
Paraschiv fails to explicitly teach wherein the service virtual instance is remotely logged in by the tenant with a client, running, by the service virtual instance, the main program code; waiting, by the service virtual instance, for at least one running result of the subroutine code when running to a location of the main program code at which the subroutine code is invoked; and continue running, by the service virtual instance, the main program code according to the at least one running result.
However, Derdak teaches:
wherein the service virtual instance is remotely logged in by the tenant with a client, “For example, system 116 may provide tenant access to multiple hosted (standard and custom) applications, including a CRM application” [Derdak ¶ 23].
running, by the service virtual instance, the main program code; “A developer may define a sequence of functions in the workflow 304, which may be a program executing on the computing system 302” [Derdak ¶ 45]. “For example, system 116 may provide tenant access to multiple hosted (standard and custom) applications, including a CRM application. User (or third-party developer) applications, which may or may not include CRM, may be supported by the application platform 118, which manages creation, storage of the applications into one or more database objects, and execution of the applications in a virtual machine in the process space of the system 116” [Derdak ¶ 23].
waiting, by the service virtual instance, for at least one running result of the subroutine code when running to a location of the main program code at which the subroutine code is invoked; “An instruction pointer may reference code associated with execution of the callout function 312. While the instruction pointer references the code and the orchestrator service 306 is waiting for a response from a called microservice, no other instructions may be executed” [Derdak ¶ 67].
and continue running, by the service virtual instance, the main program code according to the at least one running result, “Execution of the workflow 304 may be suspended until the orchestrator service 306 receives an execution state and/or an external output from the microservice 340, where the execution state indicates that the microservice has completed its task. The orchestrator service 306 may reanimate the workflow 304 after receiving an execution state indicating that the microservice 340 has completed the task and/or the external output from the microservice. The execution module 307 may accordingly execute the callback function 314 having the set of input parameters 362 and start executing the workflow 304 again” [Derdak ¶ 68].
Derdak is considered to be analogous to the claimed invention because it is in the same field of remote procedure calls. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Paraschiv to incorporate the teachings of Derdak and include: wherein the service virtual instance is remotely logged in by the tenant with a client, running, by the service virtual instance, the main program code; waiting, by the service virtual instance, for at least one running result of the subroutine code when running to a location of the main program code at which the subroutine code is invoked; and continue running, by the service virtual instance, the main program code according to the at least one running result. Doing so would allow for the waiting period of subroutine execution to be tracked. “In another example, the execution state 344 indicates a progress of the microservice 340. For example, the progress may indicate a percentage of the task completed (e.g., 10%) and/or not yet completed (e.g., 90%) by the microservice 340. In these examples, the microservice 340 is pending. A microservice is pending if it is still processing but has not yet completed the task. It may be desirable to not proceed to the next function until the microservice 340 has completed execution of the task” [Derdak ¶ 56].
Paraschiv in view of Derdak fails to teach wherein the subroutine code comprises a first annotation, wherein the first annotation comprises first configuration information and a symbol tag, … on at least one data center.
However, Liu teaches:
wherein the subroutine code comprises a first annotation, wherein the first annotation comprises first configuration information and a symbol tag, “The present invention may include generating a pattern expression (PE) header file, wherein the common datatypes associated with a software program are pre-defined, and modifying the software program to both include the PE header file and to add an annotation symbol to selected common datatypes of the software program” [Liu ¶ 3].
on at least one data center “There is a sense of location independence in that the consumer generally has no control or knowledge over the exact location of the provided resources but may be able to specify location at a higher level of abstraction (e.g., country, state, or datacenter)” [Liu ¶ 55].
Liu is considered to be analogous to the claimed invention because it is in the same field of compilation. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Paraschiv in view of Derdak to incorporate the teachings of Liu and include: wherein the subroutine code comprises a first annotation, wherein the first annotation comprises first configuration information and a symbol tag, … on at least one data center. Doing so would allow for the code to be parsed using annotations. “In one embodiment, the process may involve adding an annotation symbol (i.e. /@) to the datatype definition where the PE layer will use the predefined PEs. When compiling the software program, the compiler may parse these annotations according to the PE header file, and translate the source code into a PE table” [Liu ¶ 36].
With regard to claim 24, Paraschiv in view of Derdak in view of Liu teaches the method of claim 23, as referenced above. Paraschiv further teaches:
wherein the first configuration information indicates a virtual instance type and a virtual instance number, “An instance type may be characterized by its hardware type, computational resources (e.g., number, type, and configuration of central processing units [CPUs] or CPU cores), memory resources (e.g., capacity, type, and configuration of local memory), storage resources (e.g., capacity, type, and configuration of locally accessible storage), network resources (e.g., characteristics of its network interface and/or network capabilities), and/or other suitable descriptive characteristics” [Paraschiv ¶ 36]. “Metadata generated and stored for such a snapshot may indicate a default set of resources to be used when launching a CCI from the snapshot in some embodiments: for example, a default amount of memory, a default number of CPUs, a default collection of networking devices, and/or a default amount of persistent storage may be indicated in the metadata” [Paraschiv ¶ 27].
and wherein the at least one first virtual instance is configured with the virtual instance type and the virtual instance number. “A compute instance such as a virtual machine may be instantiated at a virtualization host of the service on behalf of a client, and allocated a set of resources (e.g., CPUs, memory, storage, etc.), based for example on a resource specification of a particular category of a set of pre-defined instance categories of the service” [Paraschiv ¶ 16]. “The container manager may receive an indication (e.g., a container image identifier) of the desired software container programmatically from a client, e.g., as part of the scaling policy, and cause the container to be run within a CCI launched specifically for the container” [Paraschiv ¶ 31].
With regard to claim 25, Paraschiv in view of Derdak in view of Liu teaches the method of claim 24, as referenced above. Paraschiv further teaches:
wherein the virtual instance number is greater than 1, wherein configuring the at least one first virtual instance further comprises configuring, by the cloud platform, multiple first virtual instances corresponding to the virtual instance number on the at least one data center, “Based on one or more triggering conditions indicated in the scaling policy, and the analysis of the metrics, the policy executor 273 may determine at approximately time T2 that a pool comprising four child compute instances (CCIs) 230A-230D is to be created” [Paraschiv ¶ 49].
and wherein the method further comprises respectively running, by the multiple virtual instances, the subroutine code to process different data from a shared storage space. “In this scenario, the policy executor 273 may initiate (a) the launch of four CCIs 230A-230D at or around time T2, (b) the allocation of respective resource sets 231A-231D to the four CCIs, and (c) the establishment of communication channels (e.g., a respective shared-memory based local communication channel between each of the CCIs and the parent CI) enabling the requests to be distributed among the four CCIs” [Paraschiv ¶ 49].
With regard to claim 27, Paraschiv in view of Derdak in view of Liu teaches the method of claim 24, as referenced above. Paraschiv further teaches:
wherein the virtual instance number is 1, wherein a first virtual instance is configured by the cloud platform on the at least one data center according to the first configuration information, wherein the program code further comprises nested program code, “A scaling policy 610 may include one or more specification(s) 622 of triggering conditions for a particular type of resource redistribution action 620 (e.g., the creation of one or more new child compute instance (CCIs), the allocation of additional resources to one or more CCIs, the termination of one or more CCIs, and so on) in the depicted embodiment” [Paraschiv ¶ 63]. “If one or more CCIs is to be launched, and multiple launch methodologies such as nested virtualization or custom instance partitioning are supported at the virtualization host at which the scaling policy 610 is applied, the launch methodology 632 to be used for the CCIs may be indicated in various embodiments” [Paraschiv ¶ 66].
wherein the second annotation comprises second configuration information, wherein the second configuration information indicates one or any combination of the virtual instance type, the virtual instance specification, or the virtual instance number, “Instead of requesting the redistribution of the resources manually every time, the client may prefer to specify one or more customizable policies (e.g., collections of rules describing the resource redistributions desired) which can be used to automatically initiate the resource redistributions” [Paraschiv ¶ 17]. “In one embodiment, based on the scaling policy, the state of a CCI may be stored, e.g., to persistent storage in the form of a snapshot (configuration information), and the snapshot may later be used to launch another CCI (e.g., with a modified resource allocation relative to the CCI whose state was saved)” [Paraschiv ¶ 27].“In at least one embodiment, a client may specify a machine image which is to be used for a CCI; for example, identifiers (configuration information) of various pre-created machine images to be used for various CCIs launched in accordance with the triggering conditions of the scaling policy may also be included in the scaling policy” [Paraschiv ¶ 25].
and wherein the method further comprises: running, by the first virtual instance, the subroutine code; “In other embodiments, CCIs may also include RPTs and/or LISMs, and a multi-level hierarchy of CCIs may be created if desired based on the policies indicated by VCS clients” [Paraschiv ¶ 74]. “A compute instance such as a virtual machine may be instantiated at a virtualization host of the service on behalf of a client, and allocated a set of resources (e.g., CPUs, memory, storage, etc.), based for example on a resource specification of a particular category of a set of pre-defined instance categories of the service” [Paraschiv ¶ 16]. “In at least one embodiment, based on a scaling policy, a CCI (child compute instance) may be created to run such a function or program on demand, and the CCI may be terminated after the results of the function or program are obtained” [Paraschiv ¶ 30].
configuring, by the cloud platform, at least one second virtual instance on the at least one data center, wherein the at least one second virtual instance is matched with the second configuration information; “quote” [citation]. “In other embodiments, CCIs may also include RPTs and/or LISMs, and a multi-level hierarchy of CCIs may be created if desired based on the policies indicated by VCS clients” [Paraschiv ¶ 74].
receiving, by the at least one second virtual instance, the nested code from the cloud platform; running, by the at least one second virtual instance, the nested code to obtain the at least one running result; “The functional programming orchestration manager (e.g., comprising one or more processes or threads) may cause a specified function to be executed or implemented at a CCI launched for the function based on the client-selected scaling policy, and terminate the CCI after the function has been executed and results or output of the function have been collected” [Paraschiv ¶ 30].
and continue running, by the first virtual instance, the subroutine program code according to the at least one running result. “The cloud can provide convenient, on-demand network access to a shared pool of configurable computing resources that can be pro grammatically provisioned and released in response to customer commands” [Paraschiv ¶ 21]. “As part of a resource redistribution triggered by a client-specified policy, in at least some embodiments the number of child compute instances of a parent compute instance may be increased (by launching additional CCIs, each allocated some of the parent Cl's resources) or decreased (by terminating existing CCIs and returning their resources to the parent CI)” [Paraschiv ¶ 27].
Paraschiv fails to explicitly teach waiting, by the first virtual instance, for at least one running result of the nested code when running to a location of the subroutine code at which the nested code is invoked; sending, by the first virtual instance, the subroutine code to the cloud platform; sending, by the at least one second virtual instance, the at least one running result to the cloud platform; receiving, by the first virtual instance, the at least one running result from the cloud platform.
However, Derdak teaches:
waiting, by the first virtual instance, for at least one running result of the nested code when running to a location of the subroutine code at which the nested code is invoked; “An instruction pointer may reference code associated with execution of the callout function 312. While the instruction pointer references the code and the orchestrator service 306 is waiting for a response from a called microservice, no other instructions may be executed” [Derdak ¶ 67].
sending, by the first virtual instance, the subroutine code to the cloud platform; “Execution of the workflow 304 may be suspended until the orchestrator service 306 receives an execution state and/or an external output from the microservice 340, where the execution state indicates that the microservice has completed its task. The orchestrator service 306 may reanimate the workflow 304 after receiving an execution state indicating that the microservice 340 has completed the task and/or the external output from the microservice. The execution module 307 may accordingly execute the callback function 314 having the set of input parameters 362 and start executing the workflow 304 again” [Derdak ¶ 68].
sending, by the at least one second virtual instance, the at least one running result to the cloud platform; receiving, by the first virtual instance, the at least one running result from the cloud platform; “Execution of the workflow 304 may be suspended until the orchestrator service 306 receives an execution state and/or an external output from the microservice 340, where the execution state indicates that the microservice has completed its task. The orchestrator service 306 may reanimate the workflow 304 after receiving an execution state indicating that the microservice 340 has completed the task and/or the external output from the microservice. The execution module 307 may accordingly execute the callback function 314 having the set of input parameters 362 and start executing the workflow 304 again” [Derdak ¶ 68].
Paraschiv in view of Derdak fails to teach wherein the nested program code comprises a second annotation.
However, Liu teaches:
wherein the nested program code comprises a second annotation, “The present invention may include generating a pattern expression (PE) header file, wherein the common datatypes associated with a software program are pre-defined, and modifying the software program to both include the PE header file and to add an annotation symbol to selected common datatypes of the software program” [Liu ¶ 3].
With regard to claim 28, Paraschiv in view of Derdak in view of Liu teaches the method of claim 23, as referenced above. Paraschiv further teaches:
wherein before obtaining the program code or before downloading the program code, the method further comprises: receiving, by the cloud platform, a service virtual instance creation request from a virtual instance service interface of the cloud platform, “For example, just as some validation tasks may be performed at the primary control plane to ensure that sufficient resources are available at the VCS for a requested PPCI before the PPCI is launched, the IPC may perform validation tasks to ensure that sufficient free resources are available for a requested CCI before the CCI is launched” [Paraschiv ¶ 70]. “The RPT 731 may implement programmatic interfaces which can be used by the VCS client on whose behalf the PPCI 730 is set up to submit requests pertaining to CCis, to view status information of the CCis, and so on” [Paraschiv ¶ 71].
wherein the virtual instance service interface is used to identify a type and a specification of the service virtual instance selected by the tenant; “A compute instance such as a virtual machine may be instantiated at a virtualization host of the service on behalf of a client, and allocated a set of resources (e.g., CPUs, memory, storage, etc.), based for example on a resource specification of a particular category of a set of pre-defined instance categories of the service” [Paraschiv ¶ 16].
and creating, by the cloud platform, the service virtual instance corresponding to the type and the specification. “In at least one embodiment, based on a scaling policy, a CCI (child compute instance) may be created to run such a function or program on demand, and the CCI may be terminated after the results of the function or program are obtained” [Paraschiv ¶ 30]. “The container manager may receive an indication (e.g., a container image identifier) of the desired software container programmatically from a client, e.g., as part of the scaling policy, and cause the container to be run within a CCI launched specifically for the container” [Paraschiv ¶ 31].
With regard to claim 29, Paraschiv in view of Derdak in view of Liu teaches the method of claim 23, as referenced above. Paraschiv further teaches:
further comprising: providing, by the cloud platform, a cloud service; “The provider network 102 may also include a number of other network-accessible services in some embodiments, such as a storage service 164, a database service 165, a machine learning service 166, and so on, which may be accessed from the compute instances of the VCS for various types of applications as needed” [Paraschiv ¶ 36].
and setting, by the cloud platform, a cloud service application programming interface (API) for the cloud service, wherein the cloud service API is invoked in the subroutine code. “The VCS may implement one or more programmatic interfaces 177 (e.g., web-based consoles, application programming interfaces (APIs), command-line tools, graphical user interfaces and the like), which may be used by VCS users or clients to submit programmatic requests for some types of compute instances, and receive corresponding responses in the depicted embodiment … In the cloud provider network context, APIs provide a gateway for customers to access cloud infrastructure by allowing customers to obtain data from or cause actions within the cloud provider network” [Paraschiv ¶ 38].
With regard to claim 30, Paraschiv in view of Derdak in view of Liu teaches the method of claim 29, as referenced above. Paraschiv further teaches wherein the cloud service API comprises one or any combination of an object storage service (OBS) API, a database service API, a shared cache service API, or a message queue service API. “The provider network 102 may also include a number of other network-accessible services in some embodiments, such as a storage service 164, a database service 165, a machine learning service 166, and so on, which may be accessed from the compute instances of the VCS for various types of applications as needed” [Paraschiv ¶ 36].
With regard to claim 32, Paraschiv in view of Derdak in view of Liu teaches the method of claim 29, as referenced above. Paraschiv further teaches wherein the virtual instance type comprises a virtual machine or a container. “A compute instance such as a virtual machine may be instantiated at a virtualization host of the service on behalf of a client, and allocated a set of resources (e.g., CPUs, memory, storage, etc.), based for example on a resource specification of a particular category of a set of pre-defined instance categories of the service” [Paraschiv ¶ 16].
With regard to claim 33, Paraschiv in view of Derdak in view of Liu teaches the method of claim 23, as referenced above. Paraschiv further teaches wherein configuring the at least one first virtual instance comprises: creating, by the cloud platform, the at least one first virtual instance on one or more physical servers of the at least one data center; or selecting, by the cloud platform, the at least one first virtual instance from a plurality of virtual instances which are pre-created by the cloud platform on the one or more physical servers. “In at least one embodiment, based on a scaling policy, a CCI may be created to run such a function or program on demand, and the CCI may be terminated after the results of the function or program are obtained” [Paraschiv ¶ 30]. “Instances of each category may be set up at the request of clients using a set of standardized virtualization servers selected by the operators of the virtualized computing service” [Paraschiv ¶ 3].
With regard to claim 34, Paraschiv in view of Derdak in view of Liu teaches the method of claim 30, as referenced above. Paraschiv further teaches wherein the at least one first virtual instance is released comprises: the at least one first virtual instance is stopped from running and is de-registered from the one or more physical servers. “The cloud can provide convenient, on-demand network access to a shared pool of configurable computing resources that can be pro grammatically provisioned and released in response to customer commands” [Paraschiv ¶ 21]. “After a CCI is terminated, processors that were allocated to the CCI may be returned to the parent CI in at least some embodiments, in an operation which represents the logical reversal of the processor off-lining and on-lining which were used to allocate the processors to the CCI earlier” [Paraschiv ¶ 33].
With regard to claim 35, Paraschiv in view of Derdak in view of Liu teaches the method of claim 23, as referenced above. Paraschiv further teaches wherein the symbol tag comprises @. “Furthermore, the CardID, iChannelID, PhoneNum, and mail datatypes of the software program are selected to be included in the PE file, and are therefore annotated with the /@ symbol.” [Liu ¶ 36].
With regard to claim 36, it is a method type claim having similar limitations as claim 23 above. Therefore, it is rejected under the same rationale.
Paraschiv teaches the further limitation either obtaining, by a cloud platform, program code from a tenant, wherein the program code is obtained from the tenant on a program code editing screen provided by the cloud platform, or downloading, by the cloud platform, the program code from a client, wherein the program code is from the tenant on a code editor of the client, “In contrast to the data plane, the VCS may include a set of servers and/or other resources used for administrative tasks and referred to as the primary control plane 112 in the depicted embodiment. The traffic and operations of the cloud provider network may broadly be subdivided into two categories in various embodiments: control plane operations carried over a logical control plane and data plane operations carried over a logical data plane” [Paraschiv ¶ 37]. “The primary control plane 112 may include, for example, global availability managers 120, provisioning managers 116, client request handlers 114 as well as one or more machine learning model managers 112 in the depicted embodiments. The VCS may implement one or more programmatic interfaces 177 (e.g., web-based consoles, application programming interfaces (APIs), command-line tools, graphical user interfaces and the like), which may be used by VCS users or clients to submit programmatic requests for some types of compute instances, and receive corresponding responses in the depicted embodiment” [Paraschiv ¶ 38].
Derdak teaches the further limitation wherein the cloud platform is remotely logged in by the tenant with the client, “For example, system 116 may provide tenant access to multiple hosted (standard and custom) applications, including a CRM application” [Derdak ¶ 23].
With regard to claims 37 and 38, they are method type claims having similar limitations as claim 24 above. Therefore, they are rejected under the same rationale.
With regard to claim 39, it is a method type claim having similar limitations as claim 25 above. Therefore, it is rejected under the same rationale.
With regard to claim 41, it is a method type claim having similar limitations as claim 27 above. Therefore, it is rejected under the same rationale.
With regard to claim 42, it is a method type claim having similar limitations as claim 29 above. Therefore, it is rejected under the same rationale.
With regard to claim 43, it is a method type claim having similar limitations as claim 30 above. Therefore, it is rejected under the same rationale.
With regard to claim 45, it is a method type claim having similar limitations as claim 32 above. Therefore, it is rejected under the same rationale.
With regard to claim 46, it is a method type claim having similar limitations as claim 33 above. Therefore, it is rejected under the same rationale.
With regard to claim 47, it is a method type claim having similar limitations as claim 34 above. Therefore, it is rejected under the same rationale.
With regard to claim 48, it is a method type claim having similar limitations as claim 35 above. Therefore, it is rejected under the same rationale.
With regard to claim 49, it is a system type claim having similar limitations as claim 23 above. Therefore, it is rejected under the same rationale.
With regard to claim 50, it is a system type claims having similar limitations as claim 24 above. Therefore, it is rejected under the same rationale.
With regard to claim 51, it is a system type claim having similar limitations as claim 28 above. Therefore, it is rejected under the same rationale.
With regard to claim 52, it is a system type claim having similar limitations as claim 25 above. Therefore, it is rejected under the same rationale.
With regard to claim 54, it is a system type claim having similar limitations as claim 27 above. Therefore, it is rejected under the same rationale.
With regard to claim 55, it is a system type claim having similar limitations as claim 29 above. Therefore, it is rejected under the same rationale.
With regard to claim 56, it is a system type claim having similar limitations as claim 30 above. Therefore, it is rejected under the same rationale.
With regard to claim 58, it is a system type claim having similar limitations as claim 32 above. Therefore, it is rejected under the same rationale.
With regard to claim 59, it is a system type claim having similar limitations as claim 33 above. Therefore, it is rejected under the same rationale.
With regard to claim 60, it is a system type claim having similar limitations as claim 34 above. Therefore, it is rejected under the same rationale.
With regard to claim 61, it is a system type claim having similar limitations as claim 35 above. Therefore, it is rejected under the same rationale.
With regard to claim 62, it is a system type claim having similar limitations as claim 36 above. Therefore, it is rejected under the same rationale.
With regard to claims 63 and 64, they are system type claims having similar limitations as claim 24 above. Therefore, they are rejected under the same rationale.
With regard to claim 65, it is a system type claim having similar limitations as claim 25 above. Therefore, it is rejected under the same rationale.
With regard to claim 67, it is a system type claim having similar limitations as claim 27 above. Therefore, it is rejected under the same rationale.
With regard to claim 68, it is a system type claim having similar limitations as claim 29 above. Therefore, it is rejected under the same rationale.
With regard to claim 69, it is a system type claim having similar limitations as claim 30 above. Therefore, it is rejected under the same rationale.
With regard to claim 71, it is a system type claim having similar limitations as claim 32 above. Therefore, it is rejected under the same rationale.
With regard to claim 72, it is a system type claim having similar limitations as claim 33 above. Therefore, it is rejected under the same rationale.
With regard to claim 73, it is a system type claim having similar limitations as claim 34 above. Therefore, it is rejected under the same rationale.
With regard to claim 74, it is a system type claim having similar limitations as claim 35 above. Therefore, it is rejected under the same rationale.
Claims 26, 40, 53, and 66 are rejected under 35 U.S.C. 103 as being unpatentable over Paraschiv (US 2021/0211391 A1) in view of Derdak (US 2020/0241944 A1) in view of Liu (US 2018/0293150 A1) in view of Jayamohan (US 2022/0086178 A1).
With regard to claim 26, Paraschiv in view of Derdak in view of Liu teaches the method of claim 25, as referenced above. Paraschiv further teaches and wherein respectively running the subroutine code to process the different data comprises respectively running, by the multiple virtual instances, the subroutine code to process the different data with a same service logic. “In this scenario, the policy executor 273 may initiate (a) the launch of four CCIs 230A-230D at or around time T2, (b) the allocation of respective resource sets 231A-231D to the four CCis, and (c) the establishment of communication channels (e.g., a respective shared-memory based local communication channel between each of the CCis and the parent CI) enabling the requests to be distributed among the four CCIs” [Paraschiv ¶ 49].
Paraschiv in view of Derdak in view of Liu fails to teach wherein the shared storage space comprises an object storage service (OBS) bucket, a shared cache, or a shared database.
However, Jayamohan teaches wherein the shared storage space comprises an object storage service (OBS) bucket, a shared cache, or a shared database, “The pod 244 can share a database instance 290 configured as a multi-tenant environment in which different organizations share access to the same database. Additionally, services rendered by the pod 244 may call upon various hardware or software resources” [Jayamohan ¶ 66].
Jayamohan is considered to be analogous to the claimed invention because it is in the same field of hypervisor specific management. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Paraschiv in view of Derdak in view of Liu to incorporate the teachings of Jayamohan and include: wherein the shared storage space comprises an object storage service (OBS) bucket, a shared cache, or a shared database. Doing so would allow for access to database resources to be shared.
With regard to claim 40, it is a method type claim having similar limitations as claim 26 above. Therefore, it is rejected under the same rationale.
With regard to claim 53, it is a system type claim having similar limitations as claim 26 above. Therefore, it is rejected under the same rationale.
With regard to claim 66, it is a system type claim having similar limitations as claim 26 above. Therefore, it is rejected under the same rationale.
Claims 31, 44, 57, and 70 are rejected under 35 U.S.C. 103 as being unpatentable over Paraschiv (US 2021/0211391 A1) in view of Derdak (US 2020/0241944 A1) in view of Liu (US 2018/0293150 A1) in view of Chung (US 2011/0161636 A1).
With regard to claim 31, Paraschiv in view of Derdak in view of Liu teaches the method of claim 23, as referenced above. Paraschiv in view of Derdak fails to teach wherein the symbol tag is pre-agreed with the cloud platform, “quote” [citation].
However, Liu teaches wherein the symbol tag is pre-agreed with the cloud platform, “Furthermore, the CardID, iChannelID, PhoneNum, and mail datatypes of the software program are selected to be included in the PE file, and are therefore annotated with the /@ symbol. The gender and address datatypes are not selected, and are therefore not appended. Next, at 206, each annotated datatype of software program 108 may be converted by the compiler 112 into a PE, which may contain a link to the software program 108.” [Liu ¶ 37].
Paraschiv in view of Derdak in view of Liu fails to teach and wherein the virtual instance specification comprises a primary frequency amplitude of a processor.
However, Chung teaches and wherein the virtual instance specification comprises a primary frequency amplitude of a processor. “The method may further include: requesting setting of the determined clock frequency of the core; releasing a clock frequency currently set for the core; and setting the determined clock frequency for the core” [Chung ¶ 27].
Chung is considered to be analogous to the claimed invention because it is in the same field of arrangements for program control. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Paraschiv in view of Derdak in view of Liu to incorporate the teachings of Chung and include: and wherein the virtual instance specification comprises a primary frequency amplitude of a processor. Doing so would allow for a quality of service to be met. “Example embodiments of the present invention provide a method of managing power of a multi-core processor capable of reducing power consumption and ensuring quality of service (QoS)” [Chung ¶ 24].
With regard to claim 44, it is a method type claim having similar limitations as claim 31 above. Therefore, it is rejected under the same rationale.
With regard to claim 57, it is a system type claim having similar limitations as claim 31 above. Therefore, it is rejected under the same rationale.
With regard to claim 70, it is a system type claim having similar limitations as claim 31 above. Therefore, it is rejected under the same rationale.
Response to Arguments
Applicant's arguments filed 02/25/2026 have been fully considered but they are not persuasive. Applicant argues in substance:
New claims 23-74 recite novel and non-obvious aspects of the invention. Support for claims 23-74 is found in the application, thus no new matter is contained in these claims. The Applicant respectfully submits that none of the cited prior art alone, or in combination, discloses the limitations recited in claims 23-74. As such, claims 23-74 are allowable. Examples of support for new claims 23-74 are described below.
a) Applicant’s arguments with respect to claim(s) 23-74 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.
Examiner respectfully requests, in response to this Office action, support be shown for language added to any original claims on amendment and any new claims. That is, indicate support for newly added claim language by specifically pointing to page(s) and line number(s) in the specification and/or drawing figure(s). This will assist Examiner in prosecuting the application.
When responding to this Office Action, Applicant is advised to clearly point out the patentable novelty which he or she thinks the claims present, in view of the state of the art disclosed by the references cited or the objections made. He or she must also show how the amendments avoid such references or objections. See 37 CFR 1.111(c).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ARI F RIGGINS whose telephone number is (571)272-2772. The examiner can normally be reached Monday-Friday 7:00AM-4: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.
/A.F.R./Examiner, Art Unit 2197
/KENNETH TANG/Primary Examiner, Art Unit 2197
Prosecution Insights