CTNF 18/617,321 CTNF 87732 DETAILED ACTION Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. Claim Rejections - 35 USC § 112 07-30-02 AIA The following is a quotation of 35 U.S.C. 112(b): (b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention. The following is a quotation of 35 U.S.C. 112 (pre-AIA), second paragraph: The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention. 07-34-01 Claim(s) 1-20 is/are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Claim 1 (similarly claims 13, 14, 17 and 19) recite: “security context”. The limitation security context is ambiguous. The examiner is unclear what particular security context would be considered as a security context. For example, there are numerous security contexts (i.e. network, memory, hardware, software, user, etc.). Therefore, metes-and-bounds of the term “security context” is not clearly defined, thus ambiguous. Claim 1 (similarly claims 17 and 19) recite: “store the common resource in a memory”. The limitation and the specification provide several examples of a data resource(s) along with hardware resource(s). However, common resource can be a hardware type of common resource that workloads access. Thus, the examiner is unclear how a different hardware resource that is not a memory and data can be stored in the memory. Claims 2-16, 18 and 20 are rejected based on rejection of its corresponding dependent claim. Claim Rejections - 35 USC § 102 07-06 AIA 15-10-15 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. 07-07-aia AIA 07-07 The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action: A person shall be entitled to a patent unless – 07-12-aia AIA (a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention. 07-15-03-aia AIA Claim(s) 1-4, 6, 8-12 and 17-20 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Turovsky et al. (Pub 20180046446) (hereafter Turovsky) . As per claim 1, Turovsky teaches: A compute node comprising: a processing unit; and memory including instructions for implementing a workload execution manager to manage a plurality of elastic workloads, the instructions, when executed by the processing unit, cause the processing unit to: ([Paragraph 41], Orchestrator [119] may refer to the Application Management Engines (106), as part of the Elastic Compute Cloud Framework described in the utility patent application Elastic Compute Cloud Based on Underutilized Server Resources Using a Distributed Container System (U.S. patent application Ser. No. 14/640,569, filed on Mar. 6, 2015), as well as the Elastic Workload Orchestrator [107], as part of the Elastic Workload Orchestration Architecture described in the utility patent application Ubiquitous and Elastic Workload Orchestration Architecture of Hybrid Applications/Services on Hybrid Cloud (U.S. patent application Ser. No. 15/381,427, filed on Dec. 16, 2016), the entireties of which are incorporated by reference herein. [Paragraph 44], Global Resource Tracker [122], which keeps track of resource utilization metrics of each Server [121] in the Heterogeneous/Hybrid Server Cluster [120]. These resource utilization metrics may include, but are not limited to, capacity of its central processing unit (CPU), random-access memory (RAM), graphics processing unit (GPU), storage, network bandwidth, memory bandwidth, and central processing unit (CPU) cache. For example, resource utilization metrics may be gathered for, and differentiated between, physical servers, virtual machines (VMs), containers, unikernels, applications, and processes. These resource utilization metrics may be gathered from agents running on each Server [121], as well as with agentless approaches. Furthermore, the Global Resource Tracker [122] shares the resource utilization metrics with the (a) Deployment Package Selector [106], to assist in selecting the most fitting Deployment Package [107] for each Application/Service [101] deployment; (b) Condensed Containerization [108], for optimized container-based deployment; (c) Specialized Unikernel Generation [109], for optimized unikernel-based deployment; (d) Orchestrator [119], for selecting the most fitting Server [121] onto which to deploy in the Heterogeneous/Hybrid Server Cluster [120].) receive data describing a first elastic workload of the plurality of elastic workloads, the first elastic workload to execute on a first virtual execution environment, the first virtual execution environment associated with a first security context; ([Paragraph 36], Application Requirement Determination [110] is a step in the Specialized Unikernel Generation [109] that determines the various requirements and dependencies for deployed Applications/Services [101] and any corresponding User Specification Interface [102] content. For example, this may be determining required and user-specified libraries and packages, similar to Application/Service Library and Package Requirement Determination [201] and User Specification Application/Service Library and Package Requirement Determination [208], both depicted in FIG. 2, respectively. Application Requirement Determination [110] may also determine which programming language(s) and software framework(s) are required. For Applications/Services [101] that are deployed as source code, the Application Requirement Determination [110] may also build the Applications/Services [101] into binaries to gather some or all of these requirements. [Paragraph 9], This selection may be based on application/service type, size, granularity, duration, estimated execution time, coupling, modularity, technical fit, user-specified content, resource availability, resource utilization metrics, historical data, including the use of machine learning, specifications for any licensed software, security boundaries in the network and/or organization, as well as device driver and protocol library availabilities. [Paragraph 13], In a further implementation, a deployment package is selected from a plurality of deployment packages to deploy one or more applications and services, based on at least one factor associated with the applications and services, specified user content, deployment resources, historical data, licensed software specifications, organization or network security boundaries, or driver or protocol library availability.) determine a common resource that is used by the plurality of elastic workloads; store the common resource in a memory accessible by the first virtual execution environment; and ([Paragraph 47], application/Service Library and Package Requirement Determination [201] are steps that determine all the library and corresponding package requirements based on the Applications/Services [101] deployed by the user. Application/Service Library and Package Requirement Determination [201] steps include: [0048] a) Determine List of Shared Libraries by Running LDD (List Dynamic Dependencies) Utility on Application/Service [202], which, for example, involves running the LDD (list dynamic dependencies) Linux utility, which prints the shared objects (shared libraries) required by each Application/Service [101] or shared object. For Applications/Services [101] that are deployed as source code, the Application/Service Library and Package Requirement Determination [201] may also first build the Applications/Services [101] into binaries. Running the LDD (list dynamic dependencies) utility is an example, and may also be accomplished with a number of other utilities and tools for a number of operating systems. Determine List of Shared Libraries by Running LDD (List Dynamic Dependencies) Utility on Application/Service [202] may be assisted by the Library and Package Repository [200], for example, in providing library availability for various operating systems. [0049] b) Determine (or Build) Corresponding Packages that Support Shared Libraries [203], which, for example, involves determining (or building) corresponding packages that support the shared libraries that are determined in the previous step of the Application/Service Library and Package Requirement Determination [201]. Determine (or Build) Corresponding Packages that Support Shared Libraries [203] may be assisted by the Library and Package Repository [200], for example, in matching libraries to packages for various operating systems. [Paragraph 32], Traditional container technologies, which are depicted by Containerization (Optional) [118] in FIG. 1 and Containerize Application and Libraries/Packages Using Scratch Container Image from Container Base Image Repository [219] in FIG. 2, may leverage server virtualization methods such as operating system (OS)-level virtualization, where the kernel of an operating system (OS) allows for multiple isolated user space instances, instead of just one. Some instances of this may include, but are not limited to, containers, virtualization engines (VEs), virtual private servers (VPS), jails, or zones, and/or any hybrid combination thereof. Some example available technologies for this containerization include chroot, Docker, Linux-VServer, lmctfy (“let me contain that for you”), LXC (Linux containers), Canonical LXD, OpenVZ (Open Virtuozzo), Parallels Virtuozzo Containers, Solaris Containers (and Solaris Zones), FreeBSD Jail, sysjail, WPARs (workload partitions), HP-UX Containers (SRP, secure resource partitions), iCore Virtual Accounts, Sandboxie, Spoon, and VMware ThinApp.) execute the first elastic workload, wherein the first elastic workload has access to the common resource, and wherein the plurality of elastic workloads is executed in isolation from one another based on respective security contexts. ([Paragraph 10], Accordingly, in one aspect, a method for creating a condensed container includes receiving an instruction to create a container that includes one or more applications and services, and identifying one or more shared libraries and corresponding packages required for executing applications and services. An optimal operating system for the container is determined, and versions of the shared libraries and the corresponding packages that correspond to the optimal operating system are selected. [Paragraph 44], For example, resource utilization metrics may be gathered for, and differentiated between, physical servers, virtual machines (VMs), containers, unikernels, applications, and processes. These resource utilization metrics may be gathered from agents running on each Server [121], as well as with agentless approaches. [Paragraph 9], This selection may be based on application/service type, size, granularity, duration, estimated execution time, coupling, modularity, technical fit, user-specified content, resource availability, resource utilization metrics, historical data, including the use of machine learning, specifications for any licensed software, security boundaries in the network and/or organization, as well as device driver and protocol library availabilities. [Paragraph 13], In a further implementation, a deployment package is selected from a plurality of deployment packages to deploy one or more applications and services, based on at least one factor associated with the applications and services, specified user content, deployment resources, historical data, licensed software specifications, organization or network security boundaries, or driver or protocol library availability. [Paragraph 3], Containers enable application/service deployment environments with relatively-low overhead compared with other virtualization techniques, while offering portability, compatibility, and isolation. [Paragraph 9], This selection may be based on application/service type, size, granularity, duration, estimated execution time, coupling, modularity, technical fit, user-specified content, resource availability, resource utilization metrics, historical data, including the use of machine learning, specifications for any licensed software, security boundaries in the network and/or organization, as well as device driver and protocol library availabilities.) As per claim 2, rejection of claim 1 is incorporated: Turovsky teaches wherein the first virtual execution environment includes a first virtual machine tenant. ([Paragraph 3], They leverage server virtualization methods such as operating system-level virtualization, where the kernel of an operating system allows for multiple isolated user space instances, instead of just one. [Paragraph 11], In one implementation, one or more user-selected libraries and corresponding packages are identified based on functionality specified by a user for inclusion in the container.) As per claim 3, rejection of claim 1 is incorporated: Turovsky teaches wherein a second virtual execution environment is used to execute a second elastic workload, and includes a second virtual machine tenant. ([Paragraph 32], Traditional container technologies, which are depicted by Containerization (Optional) [118] in FIG. 1 and Containerize Application and Libraries/Packages Using Scratch Container Image from Container Base Image Repository [219] in FIG. 2, may leverage server virtualization methods such as operating system (OS)-level virtualization, where the kernel of an operating system (OS) allows for multiple isolated user space instances, instead of just one. [Paragraph 41], Orchestrator [119] may refer to the Application Management Engines (106), as part of the Elastic Compute Cloud Framework described in the utility patent application Elastic Compute Cloud Based on Underutilized Server Resources Using a Distributed Container System (U.S. patent application Ser. No. 14/640,569 , filed on Mar. 6, 2015), as well as the Elastic Workload Orchestrator [107], as part of the Elastic Workload Orchestration Architecture described in the utility patent application Ubiquitous and Elastic Workload Orchestration Architecture of Hybrid Applications/Services on Hybrid Cloud (U.S. patent application Ser. No. 15/381,427 , filed on Dec. 16, 2016), the entireties of which are incorporated by reference herein . [ 14/640,569 Paragraph 91], This can enable agile computing systems that can completely adapt to the requirements of different types of users of the virtual private cloud. [ 14/640,569 Paragraph 31], Disclosed herein is an Elastic Compute Cloud Framework that is capable of creating an elastic compute cloud out of underutilized enterprise server resources. Furthermore, this Framework allows enterprises to transparently run more workloads…) As per claim 4, rejection of claim 3 is incorporated: Turovsky teaches wherein to determine the common resource, the compute node is to analyze first code of the first elastic workload and second code of the second elastic workload to identify a function reference that is common to both the first code and the second code. ([Paragraph 10], Accordingly, in one aspect, a method for creating a condensed container includes receiving an instruction to create a container that includes one or more applications and services, and identifying one or more shared libraries and corresponding packages required for executing applications and services. An optimal operating system for the container is determined, and versions of the shared libraries and the corresponding packages that correspond to the optimal operating system are selected. A container is then created based on a merge formed of the selected versions of the shared libraries and corresponding packages with the applications and services. Other aspects of the foregoing method include corresponding systems and non-transitory computer-readable media. [Paragraph 47], Application/Service Library and Package Requirement Determination [201] are steps that determine all the library and corresponding package requirements based on the Applications/Services [101] deployed by the user. Application/Service Library and Package Requirement Determination [201] steps include: [0048] a) Determine List of Shared Libraries by Running LDD (List Dynamic Dependencies) Utility on Application/Service [202], which, for example, involves running the LDD (list dynamic dependencies) Linux utility, which prints the shared objects (shared libraries) required by each Application/Service [101] or shared object. For Applications/Services [101] that are deployed as source code, the Application/Service Library and Package Requirement Determination [201] may also first build the Applications/Services [101] into binaries. Running the LDD (list dynamic dependencies) utility is an example, and may also be accomplished with a number of other utilities and tools for a number of operating systems. Determine List of Shared Libraries by Running LDD (List Dynamic Dependencies) Utility on Application/Service [202] may be assisted by the Library and Package Repository [200], for example, in providing library availability for various operating systems. [0049] b) Determine (or Build) Corresponding Packages that Support Shared Libraries [203], which, for example, involves determining (or building) corresponding packages that support the shared libraries that are determined in the previous step of the Application/Service Library and Package Requirement Determination [201]. Determine (or Build) Corresponding Packages that Support Shared Libraries [203] may be assisted by the Library and Package Repository [200], for example, in matching libraries to packages for various operating systems. [Paragraph 21], Applications/Services [101] are software functionalities that can be reused for different purposes, and may also be coupled with policies that control their usage. For example, in an enterprise setting, Applications/Services [101] may be defined through enterprise architecture (EA) practices for organizing business processes and information technology (IT) infrastructure. Different enterprises may have different types of Applications/Services [101] with various application granularities, which are often also correlated with their size and duration. Applications/Services [101] that may be deployed in any state, including (but not limited to) as any combination of source code, binaries, functional elements, build instructions, container images, virtual machine (VM) images, or unikernel images.) As per claim 6, rejection of claim 3 is incorporated: Turovsky teaches wherein to determine the common resource, the compute node is to analyze first code of the first elastic workload and second code of the second elastic workload to identify a data reference that is common to both the first code and the second code. ([Paragraph 10], Accordingly, in one aspect, a method for creating a condensed container includes receiving an instruction to create a container that includes one or more applications and services, and identifying one or more shared libraries and corresponding packages required for executing applications and services. An optimal operating system for the container is determined, and versions of the shared libraries and the corresponding packages that correspond to the optimal operating system are selected. A container is then created based on a merge formed of the selected versions of the shared libraries and corresponding packages with the applications and services. Other aspects of the foregoing method include corresponding systems and non-transitory computer-readable media. [Paragraph 47], Application/Service Library and Package Requirement Determination [201] are steps that determine all the library and corresponding package requirements based on the Applications/Services [101] deployed by the user. Application/Service Library and Package Requirement Determination [201] steps include: [0048] a) Determine List of Shared Libraries by Running LDD (List Dynamic Dependencies) Utility on Application/Service [202], which, for example, involves running the LDD (list dynamic dependencies) Linux utility, which prints the shared objects (shared libraries) required by each Application/Service [101] or shared object. For Applications/Services [101] that are deployed as source code, the Application/Service Library and Package Requirement Determination [201] may also first build the Applications/Services [101] into binaries. Running the LDD (list dynamic dependencies) utility is an example, and may also be accomplished with a number of other utilities and tools for a number of operating systems. Determine List of Shared Libraries by Running LDD (List Dynamic Dependencies) Utility on Application/Service [202] may be assisted by the Library and Package Repository [200], for example, in providing library availability for various operating systems. [0049] b) Determine (or Build) Corresponding Packages that Support Shared Libraries [203], which, for example, involves determining (or building) corresponding packages that support the shared libraries that are determined in the previous step of the Application/Service Library and Package Requirement Determination [201]. Determine (or Build) Corresponding Packages that Support Shared Libraries [203] may be assisted by the Library and Package Repository [200], for example, in matching libraries to packages for various operating systems. [Paragraph 21], Applications/Services [101] are software functionalities that can be reused for different purposes, and may also be coupled with policies that control their usage. For example, in an enterprise setting, Applications/Services [101] may be defined through enterprise architecture (EA) practices for organizing business processes and information technology (IT) infrastructure. Different enterprises may have different types of Applications/Services [101] with various application granularities, which are often also correlated with their size and duration. Applications/Services [101] that may be deployed in any state, including (but not limited to) as any combination of source code, binaries, functional elements, build instructions, container images, virtual machine (VM) images, or unikernel images.) As per claim 8, rejection of claim 3 is incorporated: Turovsky teaches wherein to execute the first elastic workload and the second elastic workload, the compute node is to alternate execution of the first and second elastic workloads. ([ 14/640,569 Paragraph 7], The containers can be configured to yield to the incumbent applications if they require additional compute resources. For example, by configuring the secondary applications to yield to high priority applications the containers provide for a way to back off resources in real-time. [ 14/640,569 Paragraph 52], This enables completely elastic, dynamic, and instantaneous resource yield as soon as higher-priority Applications (103) need the resources, and redeployment as soon as those resources become available. This also reduces the communication bandwidth between the Compute Servers (100) and the Secondary Application Management Engine (201).) As per claim 9, rejection of claim 1 is incorporated: Turovsky teaches wherein the common resource includes a function. ([Paragraph 9], This selection may be based on application/service type, size, granularity, duration, estimated execution time, coupling, modularity, technical fit, user-specified content, resource availability, resource utilization metrics, historical data, including the use of machine learning, specifications for any licensed software, security boundaries in the network and/or organization, as well as device driver and protocol library availabilities. [Paragraph 13], In a further implementation, a deployment package is selected from a plurality of deployment packages to deploy one or more applications and services, based on at least one factor associated with the applications and services, specified user content, deployment resources, historical data, licensed software specifications, organization or network security boundaries, or driver or protocol library availability.) As per claim 10, rejection of claim 1 is incorporated: Turovsky teaches wherein the common resource includes a microservice. ([Paragraph 5], Unikernels consist of single address space machine images, and may be constructed with the use of library operating systems (OS). Traditionally, to deploy applications/services as unikernels, the developers would manually identify the minimum set of libraries corresponding to the operation system (OS) constructs for specific types of unikernels. These libraries would then be compiled with the applications/services and any corresponding configuration code. Many times, device drivers would also be required for specific hardware on which the unikernel is to be deployed, as well as protocol libraries. [Paragraph 10], Accordingly, in one aspect, a method for creating a condensed container includes receiving an instruction to create a container that includes one or more applications and services, and identifying one or more shared libraries and corresponding packages required for executing applications and services. An optimal operating system for the container is determined, and versions of the shared libraries and the corresponding packages that correspond to the optimal operating system are selected. A container is then created based on a merge formed of the selected versions of the shared libraries and corresponding packages with the applications and services. Other aspects of the foregoing method include corresponding systems and non-transitory computer-readable media.) As per claim 11, rejection of claim 1 is incorporated: Turovsky teaches wherein the common resource includes a library function. ([Paragraph 10], Accordingly, in one aspect, a method for creating a condensed container includes receiving an instruction to create a container that includes one or more applications and services, and identifying one or more shared libraries and corresponding packages required for executing applications and services. An optimal operating system for the container is determined, and versions of the shared libraries and the corresponding packages that correspond to the optimal operating system are selected. A container is then created based on a merge formed of the selected versions of the shared libraries and corresponding packages with the applications and services. Other aspects of the foregoing method include corresponding systems and non-transitory computer-readable media.) As per claim 12, rejection of claim 1 is incorporated: Turovsky teaches wherein the common resource includes public data. ([Paragraph 42], Heterogeneous/Hybrid Server Cluster [120] is a cluster that is formed from any hybrid combination of Server [121] resources, spanning, for example, on-premises data centers, private clouds, and public clouds. [Paragraph 10], Accordingly, in one aspect, a method for creating a condensed container includes receiving an instruction to create a container that includes one or more applications and services, and identifying one or more shared libraries and corresponding packages required for executing applications and services. An optimal operating system for the container is determined, and versions of the shared libraries and the corresponding packages that correspond to the optimal operating system are selected. A container is then created based on a merge formed of the selected versions of the shared libraries and corresponding packages with the applications and services.) As per claims 17 and 18, these are method claims corresponding to the compute node claims 1-4. Therefore, rejected based on similar rationale. As per claims 19 and 20, these are non-transitory machine-readable medium claims corresponding to the method claims 1-3 and 8. Therefore, rejected based on similar rationale . Claim Rejections - 35 USC § 103 07-06 AIA 15-10-15 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. 07-20-aia AIA 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. 07-21-aia AIA Claim(s) 5 and 7 is/are re jected under 35 U.S.C. 103 as being unpatentable over Turovsky in view of Cheruvu et al. (Pub 20220014467) (hereafter Cheruvu). As per cla im 5, rejection of claim 4 is incorporated: Although Turovsky discloses common library(ies)/application(s)/service(s) which contains function(s) for workload execution with network security boundaries via elastic container(s)/VM(s) which is/are deployed and executed. ([Paragraph 43], Server [121], which may operate within a client-server architecture, responds to requests across a computer network to provide, or help to provide a networked service. The client or clients may run on the same physical or virtual Server [121], or may be connected to the Server [121] over a network. Some examples of Server [121] types include computing servers, application servers, database servers, web servers, file servers, mail servers, and game servers. [Paragraph 13], In a further implementation, a deployment package is selected from a plurality of deployment packages to deploy one or more applications and services, based on at least one factor associated with the applications and services, specified user content, deployment resources, historical data, licensed software specifications, organization or network security boundaries, or driver or protocol library availability. ) Turovsky does not explicitly disclose wherein the function reference is a Named Function Networking (NFN) expression. ([Paragraph 10], Accordingly, in one aspect, a method for creating a condensed container includes receiving an instruction to create a container that includes one or more applications and services, and identifying one or more shared libraries and corresponding packages required for executing applications and services. An optimal operating system for the container is determined, and versions of the shared libraries and the corresponding packages that correspond to the optimal operating system are selected. A container is then created based on a merge formed of the selected versions of the shared libraries and corresponding packages with the applications and services. Other aspects of the foregoing method include corresponding systems and non-transitory computer-readable media. [Paragraph 13], In a further implementation, a deployment package is selected from a plurality of deployment packages to deploy one or more applications and services, based on at least one factor associated with the applications and services, specified user content, deployment resources, historical data, licensed software specifications, organization or network security boundaries, or driver or protocol library availability.) Cheruvu teaches Named Function Networking (NFN) expression. ([Paragraph 2], A named function network (NFN) is an ICN where names refer to functions to be executed. Thus, the interest packet may include a name of a function and possibly parameters to execute the function and the data packet includes the results of the function. [Paragraph 38], Routing nodes—such as NFN node A, NFN node B 115, or NFN node C 120—may cache NFN functions and may use a BF to efficiently route requests to either NFN routing node caches or to function providers. The NFN Nodes' cache content may contain NFN code—such as programs, object code, executable code, binaries, scripts, binary translations, executable metadata, etc.—an NFN Code Name, or a cache index value (as illustrated in the function list of the directory 150). [Paragraph 91], Also, with the use of container pods, tenant boundaries can still exist but in the context of each pod of containers. If each tenant specific pod has a tenant specific pod controller, there will be a shared pod controller that consolidates resource allocation requests to avoid typical resource starvation situations. [Paragraph 132], Thus, if an ICN element has a cached item or route for both “www.somedomain.com or videos” and “www.somedomain.com or videos or v8675309,” the ICN element will match the later for an interest packet 1030 specifying “www.somedomain.com or videos or v8675309.” In an example, an expression may be used in matching by the ICN device.) It would have been obvious to a person with ordinary skill in the art, before the effective filing date of the invention, to combine the teachings of Turovsky wherein elastic workload(s) is/are managed by a workload execution manager, elastic workload description is received to execution utilizing virtual execution environment (i.e. container/VM), common resource/function is identified for plurality of elastic workloads and the elastic workload(s) is/are executed based on respective security context in isolation via computing resources across a network, into teachings of Cheruvu wherein the function reference is Named Function Networking (NFN) expression, wherein by analyzing codes to identify common functions to include NFN expression, it allows combining of common functions such as libraries to provide efficient elastic workload deployment and also NFN expression for efficient network manageability. [Cheruvu paragraph 21] As per claim 7, rejection of claim 3 is incorporated: Although Turovsky discloses common library(ies)/application(s)/service(s) which contains function(s) for workload execution with network security boundaries via elastic container(s)/VM(s) which is/are deployed and executed. ([Paragraph 43], Server [121], which may operate within a client-server architecture, responds to requests across a computer network to provide, or help to provide a networked service. The client or clients may run on the same physical or virtual Server [121], or may be connected to the Server [121] over a network. Some examples of Server [121] types include computing servers, application servers, database servers, web servers, file servers, mail servers, and game servers. [Paragraph 13], In a further implementation, a deployment package is selected from a plurality of deployment packages to deploy one or more applications and services, based on at least one factor associated with the applications and services, specified user content, deployment resources, historical data, licensed software specifications, organization or network security boundaries, or driver or protocol library availability. ) Turovsky does not explicitly disclose wherein the data reference is a Named Data Networking (NDN) expression. ([Paragraph 10], Accordingly, in one aspect, a method for creating a condensed container includes receiving an instruction to create a container that includes one or more applications and services, and identifying one or more shared libraries and corresponding packages required for executing applications and services. An optimal operating system for the container is determined, and versions of the shared libraries and the corresponding packages that correspond to the optimal operating system are selected. A container is then created based on a merge formed of the selected versions of the shared libraries and corresponding packages with the applications and services. Other aspects of the foregoing method include corresponding systems and non-transitory computer-readable media. [Paragraph 13], In a further implementation, a deployment package is selected from a plurality of deployment packages to deploy one or more applications and services, based on at least one factor associated with the applications and services, specified user content, deployment resources, historical data, licensed software specifications, organization or network security boundaries, or driver or protocol library availability.) Cheruvu teaches Named Function Networking (NFN) expression. ([Paragraph 2], A named function network (NFN) is an ICN where names refer to functions to be executed. Thus, the interest packet may include a name of a function and possibly parameters to execute the function and the data packet includes the results of the function. [Paragraph 38], Routing nodes—such as NFN node A, NFN node B 115, or NFN node C 120—may cache NFN functions and may use a BF to efficiently route requests to either NFN routing node caches or to function providers. The NFN Nodes' cache content may contain NFN code—such as programs, object code, executable code, binaries, scripts, binary translations, executable metadata, etc.—an NFN Code Name, or a cache index value (as illustrated in the function list of the directory 150). [Paragraph 91], Also, with the use of container pods, tenant boundaries can still exist but in the context of each pod of containers. If each tenant specific pod has a tenant specific pod controller, there will be a shared pod controller that consolidates resource allocation requests to avoid typical resource starvation situations. [Paragraph 132], Thus, if an ICN element has a cached item or route for both “www.somedomain.com or videos” and “www.somedomain.com or videos or v8675309,” the ICN element will match the later for an interest packet 1030 specifying “www.somedomain.com or videos or v8675309.” In an example, an expression may be used in matching by the ICN device.) It would have been obvious to a person with ordinary skill in the art, before the effective filing date of the invention, to combine the teachings of Turovsky wherein elastic workload(s) is/are managed by a workload execution manager, elastic workload description is received to execution utilizing virtual execution environment (i.e. container/VM), common resource/function is identified for plurality of elastic workloads and the elastic workload(s) is/are executed based on respective security context in isolation via computing resources across a network, into teachings of Cheruvu wherein the function reference is Named Function Networking (NFN) expression, wherein by analyzing codes to identify common functions to include NFN expression, it allows combining of common functions such as libraries to provide efficient elastic workload deployment and also NFN expression for efficient network manageability. [Cheruvu paragraph 21] 07-21-aia AIA Claim( s) 15 and 16 i s/are rejected under 35 U.S.C. 103 as being unpatentable over T urovsky in view of Haghighat et al. (Pub 20210263779) (hereafter Haghighat). A s per claim 15, rejection of claim 1 is incorporated: Turovsky teaches detect an application programming interface (API) call made by the first elastic workload, wherein the API is used to act on a resource, and wherein a parameter of the API call includes a token, the token including security, trust, or resiliency directives to apply to the resource; and determine that the security, trust, or resiliency directives are satisfied before allowing the API call access to the resource. ([Paragraph 20], User Submission Interface [100] is an interface that a user may use to interface with the system. For example, the user may submit Applications/Services [101] to the Deployment Package Selector [106] through the User Submission Interface [100]. This may be accomplished, for example, manually or automatically, through a command-line interface (CLI), graphical user interface (GUI), application program interface (API), web browser interface, or any combination thereof. [Paragraph 8], One implementation of specialized unikernel generation includes a system that first automatically determines the minimum set of requirements and dependencies, in forms of libraries and packages, for the deployed applications/services and any corresponding user-specified content. This system then matches the best available library operating system, and performs the compilation to generate the unikernel. Thus, this system produces optimized (in terms of most fitting to applications/services, for any combination of size, speed, resource utilization, and performance) unikernel images from applications/services by leveraging traditional unikernel technologies. [Paragraph 9], This selection may be based on application/service type, size, granularity, duration, estimated execution time, coupling, modularity, technical fit, user-specified content, resource availability, resource utilization metrics, historical data, including the use of machine learning, specifications for any licensed software, security boundaries in the network and/or organization, as well as device driver and protocol library availabilities.) However, Turovsky does not explicitly disclose wherein a parameter of the API call includes a token, the token including security, trust, or resiliency directives to apply to the resource; and determine that the security, trust, or resiliency directives are satisfied before allowing the API call access to the resource. Haghighat teaches wherein a parameter of the API call includes a token, the token including security, trust, or resiliency directives to apply to the resource; and determine that the security, trust, or resiliency directives are satisfied before allowing the API call access to the resource. ([Paragraph 165], The telemetry information may include attributes such as CPU utilization, memory consumption, cache hierarchy behavior, I/O and networking behavior, time/location of the execution, power/energy consumption, security/privacy aspects of the functions and their data (e.g., security requirements and malicious attack detection), users and applications calling the functions, parameters and data used by the functions, etc… [Paragraph 181], Illustrated processing block 642 provides for detecting a security attestation token associated with a function that is executed within a container. For example, an orchestrator provides the required security attestation tokens when the orchestrator sends the function to a function invoker. Further, an invoker may maintain a registry of such security attestation tokens and is framework dependent. Security attestation tokens may be generated by either of the invoker or the orchestrator ahead of time when, for example, when a function is registered with the orchestrator by a developer or a consumer of the function. [Paragraph 182], A determination may be made at block 644 as to whether the security attestation token is valid by verification of signature or other applicable method. If so, block 646 permits a use (e.g., direct access) by the function of a set of user level capabilities, wherein the set of user level capabilities corresponds to one or more features outside the container. [Paragraph 792], Some embodiments of the enhanced FaaS system 3040 may add technology/capabilities to function invocations to be able to pass down code, data, context, etc. to the callee functions. The callee functions may then recursively pass down the code, data, context, etc. For example, function g is the callee of function ƒ, which passes data to function g; function h is the callee of function g, which passed data to function h… Advantageously, some embodiments of the enhanced FaaS system 3040 may help implement resilient solutions and enable proper/efficient exception handling. [Paragraph 221], In some embodiments, the OS may expose a function call API to the functions. For example, the API framework may use an OS API for function calls instead of network communication if available. Advantageously, the API framework may provide a more efficient transport as compared to the network for remote calls.) It would have been obvious to a person with ordinary skill in the art, before the effective filing date of the invention, to combine the teachings of Turovsky wherein elastic workload(s) is/are managed by a workload execution manager, elastic workload description is received to execution utilizing virtual execution environment (i.e. container/VM), common resource/function is identified for plurality of elastic workloads and the elastic workload(s) is/are executed based on respective security context in isolation via computing resources across a network, into teachings of Haghighat wherein API framework is utilized to act on a resource with a token (security/trust) before allowing access to the resource, because this would enhance the teachings of Turovsky wherein by using a security attestation token, it provides verification functionality to ensure proper access to a set user level capabilities prior to allowing access. As per claim 16, rejection of claim 1 is incorporated: Turovsky teaches wherein the compute node is to: detect an application programming interface (API) call made by the first elastic workload, wherein the API is used to act on a resource, and wherein a parameter of the API call includes a service level agreement; and determine that the service level agreement is satisfied before allowing the API call access to the resource. ([Paragraph 20], User Submission Interface [100] is an interface that a user may use to interface with the system. For example, the user may submit Applications/Services [101] to the Deployment Package Selector [106] through the User Submission Interface [100]. This may be accomplished, for example, manually or automatically, through a command-line interface (CLI), graphical user interface (GUI), application program interface (API), web browser interface, or any combination thereof. [Paragraph 8], One implementation of specialized unikernel generation includes a system that first automatically determines the minimum set of requirements and dependencies, in forms of libraries and packages, for the deployed applications/services and any corresponding user-specified content. This system then matches the best available library operating system, and performs the compilation to generate the unikernel. Thus, this system produces optimized (in terms of most fitting to applications/services, for any combination of size, speed, resource utilization, and performance) unikernel images from applications/services by leveraging traditional unikernel technologies. [Paragraph 9], This selection may be based on application/service type, size, granularity, duration, estimated execution time, coupling, modularity, technical fit, user-specified content, resource availability, resource utilization metrics, historical data, including the use of machine learning, specifications for any licensed software, security boundaries in the network and/or organization, as well as device driver and protocol library availabilities.) However, Turovsky does not explicitly disclose wherein a parameter of the API call includes a service level agreement; and determine that the service level agreement is satisfied before allowing the API call access to the resource. ([Paragraph 165], The telemetry information may include attributes such as CPU utilization, memory consumption, cache hierarchy behavior, I/O and networking behavior, time/location of the execution, power/energy consumption, security/privacy aspects of the functions and their data (e.g., security requirements and malicious attack detection), users and applications calling the functions, parameters and data used by the functions, etc… [Paragraph 161], The Orchestrator 404 may also include the following sub-components: telemetry manager 416, profile manager 418, machine learning/artificial intelligence (ML/AI) advisor 420, and service-level agreement/quality of service (SLA/QoS) manager 422. The orchestrator 404 may profile data such as for example resource needs and/or demand profiles of functions described with respect to the embodiments of FIGS. 13A-13C, static and dynamic profile information of a function as described with respect to the embodiments of FIGS. 24A-24B, and dynamic profiles as described below with respect to FIGS. 40A-40B. [Paragraph 221], In some embodiments, the OS may expose a function call API to the functions. For example, the API framework may use an OS API for function calls instead of network communication if available. Advantageously, the API framework may provide a more efficient transport as compared to the network for remote calls. [Paragraph 282], In selecting the thresholds for launching Bm or Bh (e.g., as respectively the utilization Bs or Bm rises), and in selecting the thresholds for reclaiming Bh or Bm (e.g., as utilization of Bh and Bm respectively declines), some embodiments may take into account service level agreement (SLA) inputs provided dynamically by an AFaaS control service. If no SLA input is provided, then these thresholds may be set heuristically and dynamically, based on the arrival rates for requests for B (e.g., or a moving window average of the arrival rates). [Paragraph 925], The above-described embodiment may be used to generalize to chain depths >1, transitively. In general there may be more parameters than one in computing the coupling contribution (z)—for example, in a resource constrained environment, a variable amount of increase in the time-to-live may be applied for a given accelerated function B when the demand for function B and its precursors drops off (so that B may be reclaimed faster); similarly, when the overall demand is low or when SLA requirements are stringent, there may be a stronger positive bias for launching function B and a stronger negative bias against reclaiming B, based the observations at its precursors.) It would have been obvious to a person with ordinary skill in the art, before the effective filing date of the invention, to combine the teachings of Turovsky wherein elastic workload(s) is/are managed by a workload execution manager, elastic workload description is received to execution utilizing virtual execution environment (i.e. container/VM), common resource/function is identified for plurality of elastic workloads and the elastic workload(s) is/are executed based on respective security context in isolation via computing resources across a network, into teachings of Haghighat wherein API framework is utilized to act on a resource with included parameter for a SLA, because this would enhance the teachings of Turovsky, wherein by utilizing SLA parameter, it allows workload profile to be provided to ensure resource needs/demands/requirements are satisfied/met based on user(s) need. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to DONG U KIM whose telephone number is (571)270-1313. The examiner can normally be reached 9:00am - 5:00pm. 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 5712723338. 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. /DONG U KIM/Primary Examiner, Art Unit 2197 Application/Control Number: 18/617,321 Page 2 Art Unit: 2197 Application/Control Number: 18/617,321 Page 4 Art Unit: 2197 Application/Control Number: 18/617,321 Page 5 Art Unit: 2197 Application/Control Number: 18/617,321 Page 6 Art Unit: 2197 Application/Control Number: 18/617,321 Page 7 Art Unit: 2197 Application/Control Number: 18/617,321 Page 8 Art Unit: 2197 Application/Control Number: 18/617,321 Page 9 Art Unit: 2197 Application/Control Number: 18/617,321 Page 10 Art Unit: 2197 Application/Control Number: 18/617,321 Page 11 Art Unit: 2197 Application/Control Number: 18/617,321 Page 12 Art Unit: 2197 Application/Control Number: 18/617,321 Page 13 Art Unit: 2197 Application/Control Number: 18/617,321 Page 14 Art Unit: 2197 Application/Control Number: 18/617,321 Page 15 Art Unit: 2197 Application/Control Number: 18/617,321 Page 16 Art Unit: 2197 Application/Control Number: 18/617,321 Page 17 Art Unit: 2197 Application/Control Number: 18/617,321 Page 18 Art Unit: 2197 Application/Control Number: 18/617,321 Page 19 Art Unit: 2197 Application/Control Number: 18/617,321 Page 20 Art Unit: 2197 Application/Control Number: 18/617,321 Page 21 Art Unit: 2197 Application/Control Number: 18/617,321 Page 22 Art Unit: 2197 Application/Control Number: 18/617,321 Page 23 Art Unit: 2197 Application/Control Number: 18/617,321 Page 24 Art Unit: 2197 Application/Control Number: 18/617,321 Page 25 Art Unit: 2197 Application/Control Number: 18/617,321 Page 26 Art Unit: 2197 Application/Control Number: 18/617,321 Page 27 Art Unit: 2197 Application/Control Number: 18/617,321 Page 28 Art Unit: 2197 Application/Control Number: 18/617,321 Page 29 Art Unit: 2197 Application/Control Number: 18/617,321 Page 30 Art Unit: 2197
Prosecution Insights