Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-20 are currently pending for examination.
Claim Objections
Claims 11-18 are objected to because of the following informalities:
Claims 11-18 recite “machine-readable medium”, however claim 10 from which each of these claims depend recites “non-transitory machine-readable medium”. Claims 11-18 should be amended to match claim 10. Appropriate correction is required.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-5, 7, 10-14, 16, 19-21, and 23-25 are rejected under 35 U.S.C. 103 as being unpatentable over D'Innocenzo (US 20230142198 A1) in view of Kwatra (US 20240086190 A1).
As per claim 1, D’Innocenzo discloses:
A method for processing of a container software package for use in a development platform of edge computing hardware, comprising: receiving, at the development platform from a remote location, package data for a deployment of one or more containers, the package data including a configuration for the one or more containers (“In some embodiments, the present disclosure may be implemented in a mobile edge computing (MEC) environment implemented in conjunction with a 4G, 5G, or other cellular network. MEC is a type of edge computing that uses cellular networks and 5G and enables a data center to extend cloud services to local deployments using a distributed architecture that provide federated options for local and remote data and control management.”, 0029 ;"FIG. 2 illustrates a Kubernetes control plane 222 which is configured to receive and implement the desired state information for a deployment. In an embodiment, the files that describe the desired set of Kubernetes resources can be defined by a Helm chart 205 that contains input metadata 210. The control plane 222 may receive as input metadata including the API, entity URL or identifier, access credentials, desired states, and other information needed to deploy a service at cluster 230.", 0030 ; "Helm charts are often used to define configurations for a given deployment.", 0002 ; Examiners Note: a Helm chart equates to package data for a container )
extracting the configuration for the one or more containers from the package data (“The schema files from all the Helm charts may be parsed and the “exposedName” tokens may be extracted. A relationship map may be created (e.g., “exposedName”<->backend-value). This will be one to many. Customized input data for all “exposedName” values in the relationship map may be provided.”, 0017 ; Examiner Note: a relationship map equates to a configuration)
Although D’Innocenzo discloses the above limitations of claim 1, they do not disclose them within a development platform; nor do they disclose validating compliance with a security policy.
However, Kwatra discloses:
performing a security evaluation of the one or more containers and the configuration for the one or more containers, to validate compliance with a security policy of the development platform (“Aspects of the present invention relate generally to software development environments “, 0001 ; “In a first aspect of the invention, there is a computer-implemented method including: receiving, by a processor, a plurality of infrastructure as code files specifying a configuration of a runtime environment for a deployable image of source code in a continuous integration and continuous delivery pipeline for a cloud platform “, 0003 ; “In embodiments, the system including a processor… may detect code that does not follow a compliance rule of security and compliance policies in a continuous integration and continuous delivery pipeline for a cloud service, append compliance code that follows the compliance rule of the security and compliance policies to remediate the non-compliant code, verify the code follows compliance rules of the security and compliance policies, and deploy the cloud service.", 0018 ; “Server 206 includes, in memory 208, a cognitive module 210 having functionality to receive data, including source code, code for Infrastructure as Code (IaC), playbooks, CI/CD pipeline configuration files, among other data provided and used during CI/CD delivery on cloud platforms, and process this data to detect non-compliance of code with compliance rules and policies of an enterprise and to generate compliance code which updates the source code, the IaC code and other files to comply with compliance rules and policies of an enterprise”, 0039 ; Examiner Note: the IaC code which is evaluated for security compliance equates to configuration, and the source code corresponds to the container)
enabling the development platform to conduct execution of one or more container images for the one or more containers based on the configuration, in response to validating compliance with the security policy. ( see Fig.4 – step 420 : validating security compliance of the container, step 422: executing deployment of container which is compliant with security policies)
It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the system of D’Innocenzo with that of Kwatra in order to provide a means for identifying defects and security flaws during the development and deployment of runtime environments (Kwatra, [0002]).
As per claim 2, D’Innocenzo in view of Kwatra fully discloses the limitations of claim 1.
Furthermore, D’Innocenzo discloses:
the package data for the one or more containers comprises a Helm chart, wherein the Helm chart defines one or more application manifests, and wherein the one or more application manifests include the configuration to specify the execution of the one or more container images ("In various embodiments, Helm charts may be implemented that optionally include a schema file that describes every value that a user can set (whether optional or required) and can be enhanced to simplify workload deployment. In one embodiment, parameters that are required for a system to be deployed and do not typically include a default value are annotated with a meaningful token. As an example, the “exposedName” token is used, but it should be understood that any name can be used to identify values that are to be exposed. The “exposedName” token may be reused for duplicated values in all Helm charts that are required to deploy the system. The schema files from all the Helm charts may be parsed and the “exposedName” tokens may be extracted. A relationship map may be created (e.g., “exposedName”<->backend-value). This will be one to many. Customized input data for all “exposedName” values in the relationship map may be provided. The filled relationship map may be parsed and a Helm-values overlay file for each Helm chart may be output. The Helm charts may be deployed along with the generated values overlay.", 0017 ; Examiner Note: a schema file equates to an application manifest (XML file) which contains a relationship map- equating to a configuration- of a container)
As per claim 3, D’Innocenzo in view of Kwatra fully discloses the limitations of claim 1.
Furthermore, Kwatra discloses:
the package data for the one or more containers comprises a Docker Compose YAML file, and wherein the Docker Compose YAML file includes the configuration to specify the execution of the one or more container images ("IaC code 232 files may include various configuration format files such as HCL, JSON or YAML file formats with functional and/or procedural instructions to provision the configuration of infrastructure components in a runtime environment. For example, storage 224 may store playbooks 234, each a type of IaC code 232 file written in YAML that include declarations specifying the final state infrastructure to provision for the runtime environment", 0044)
As per claim 4, D’Innocenzo in view of Kwatra fully discloses the limitations of claim 1.
Furthermore, Kwatra discloses:
the package data for the deployment of the one or more containers provides references to source code from a repository, and wherein the method further comprises: building the one or more container images, at the development platform, from the source code; and storing the one or more container images at the development platform. ("build a deployable image of source code in the continuous integration and continuous delivery pipeline according to a configuration of a runtime environment specified by the plurality of code files", 0004 ; see fig.2 – Source code 230 stored in repository 224 ; “The virtual computing environments (VCEs) typically take the form of virtual machines from virtual machine set 143 and/or containers from container set 144. It is understood that these VCEs may be stored as images and may be transferred among and between the various physical machine hosts, either as images or after instantiation of the VCE.”, 0035)
As per claim 5, D’Innocenzo in view of Kwatra fully discloses the limitations of claim 1.
Furthermore, Kwatra discloses:
the source code and the package data are obtained from a software development project repository ("Server 206 also includes, in memory 208, continuous integration module 212 having functionality to download source code from a repository and any dependent code required by the source code to execute, compile the source code with the dependent code, build an executable instance of the compiled source code with the dependent code, and test the executable instance of the source code", 0039 ; see fig.2- Source code 230 and playbooks 234 are stored in a repository for the development platform)
As per claim 7, D’Innocenzo in view of Kwatra fully discloses the limitations of claim 1.
Furthermore, D’Innocenzo discloses:
the development platform comprises a plurality of types of edge computing hardware available for execution of the one or more containers ("In some embodiments, the present disclosure may be implemented in a mobile edge computing (MEC) environment implemented in conjunction with a 4G, 5G, or other cellular network.", 0029 ; "It should also be appreciated that a server, gateway, or other computing device may comprise any combination of hardware or software that can interact and perform the described types of functionality, including without limitation desktop or other computers, database servers, network storage devices and other network devices, PDAs, tablets, smartphone, Internet appliances, television-based systems (e.g., using set top boxes and/or personal/digital video recorders), and various other consumer products that include appropriate communication capabilities.", 0028)
As per claim 10, it is a non-transitory machine-readable medium (D’Innocenzo, [0071]) claim comprising substantially the same limitations as claim 1. As such, it is rejected for substantially the same reasons.
As per claim 11, it is a non-transitory machine-readable medium claim comprising substantially the same limitations as claim 2. As such, it is rejected for substantially the same reasons.
As per claim 12, it is a non-transitory machine-readable medium claim comprising substantially the same limitations as claim 3. As such, it is rejected for substantially the same reasons.
As per claim 13, it is a non-transitory machine-readable medium claim comprising substantially the same limitations as claim 4. As such, it is rejected for substantially the same reasons.
As per claim 14, it is a non-transitory machine-readable medium claim comprising substantially the same limitations as claim 5. As such, it is rejected for substantially the same reasons.
As per claim 16, it is a non-transitory machine-readable medium claim comprising substantially the same limitations as claim 7. As such, it is rejected for substantially the same reasons.
As per claim 19, D’Innocenzo discloses:
a storage device to store package data for a deployment of one or more containers, the package data including a configuration for the one or more containers (see fig.7- system memory 720 is a storage device ; “receiving, by a service running in the cloud computing environment, a plurality of Helm charts associated with a function to be deployed in the cloud computing environment, the plurality of Helm charts comprising a schema file and a plurality of parameters defining deployment of the function in the cloud computing environment”, 0084 ; Examiner Note: it is necessary that the package data, or Helm charts, are stored in the system memory, equating to a storage device, in order to be received)
extract the configuration for the one or more containers from the package data (“The schema files from all the Helm charts may be parsed and the “exposedName” tokens may be extracted. A relationship map may be created (e.g., “exposedName”<->backend-value). This will be one to many. Customized input data for all “exposedName” values in the relationship map may be provided.”, 0017 ; Examiner Note: a relationship map equates to a configuration)
Furthermore, Kwatra discloses:
perform a security evaluation of the one or more containers and the configuration for the one or more containers, to validate compliance with a security policy of the development platform (“Aspects of the present invention relate generally to software development environments “, 0001 ; “In a first aspect of the invention, there is a computer-implemented method including: receiving, by a processor, a plurality of infrastructure as code files specifying a configuration of a runtime environment for a deployable image of source code in a continuous integration and continuous delivery pipeline for a cloud platform “, 0003 ; “In embodiments, the system including a processor… may detect code that does not follow a compliance rule of security and compliance policies in a continuous integration and continuous delivery pipeline for a cloud service, append compliance code that follows the compliance rule of the security and compliance policies to remediate the non-compliant code, verify the code follows compliance rules of the security and compliance policies, and deploy the cloud service.", 0018 ; “Server 206 includes, in memory 208, a cognitive module 210 having functionality to receive data, including source code, code for Infrastructure as Code (IaC), playbooks, CI/CD pipeline configuration files, among other data provided and used during CI/CD delivery on cloud platforms, and process this data to detect non-compliance of code with compliance rules and policies of an enterprise and to generate compliance code which updates the source code, the IaC code and other files to comply with compliance rules and policies of an enterprise”, 0039 ; Examiner Note: the IaC code which is evaluated for security compliance equates to configuration, and the source code corresponds to the container)
enable the development platform to conduct execution of one or more container images for the one or more containers based on the configuration, in response to validating compliance with the security policy. ( see Fig.4 – step 420 : validating security compliance of the container, step 422: executing deployment of container which is compliant with security policies)
As per claim 20, it is a system claim comprising substantially the same limitations as claim 2. As such, it is rejected for substantially the same reasons.
As per claim 21, it is a system claim comprising substantially the same limitations as claim 3. As such, it is rejected for substantially the same reasons.
As per claim 23, it is a system claim comprising substantially the same limitations as claim 1. As such, it is rejected for substantially the same reasons.
As per claim 24, it is a system claim comprising substantially the same limitations as claim 2. As such, it is rejected for substantially the same reasons.
As per claim 25, it is a system claim comprising substantially the same limitations as claim 3. As such, it is rejected for substantially the same reasons.
Claims 6 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over D'Innocenzo (US 20230142198 A1) in view of Kwatra (US 20240086190 A1) in further view of Pieczul (US 20220191248 A1).
As per claim 6, D’Innocenzo in view of Kwatra fully discloses the limitations of claim 1.
Furthermore, Kwatra discloses:
the security evaluation is performed on the one or more container images that provide the one or more containers ("Additionally, the build of the deployable image is validated to verify the code is compliant with compliance rules as part of the deployment process, and the cloud service is deployed on the cloud platform.", 0016)
D’Innocenzo in view of Kwatra fully discloses the above limitation of claim 6, but does not explicitly disclose a security evaluation performed on one or more resource objects specified by package data.
However, Pieczul discloses:
the security evaluation is further performed on one or more resource objects specified by the package data. (“In certain examples, the deployment package comprises the first version of the component and the first network security policy.”, 0005 ; "After obtaining the information identifying the network connections originating from the component 106, as part of performing the policy compliance test for the component 106, the acceptance test subsystem 602 then determines if the network connections that the component are attempting to use are in compliance with the coarse-grained policy 117 defined for the application. ", 0065 ; Examiner Note: a component corresponds to a resource object)
It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the system of D’Innocenzo in view of Kwatra with that of Pieczul in order to provide the development platform with the ability to generate network security policies for different versions of a component of an application deployed in a computing environment where the different versions have potentially different network requirements (Pieczul, [0101]).
As per claim 15, it is a non-transitory machine-readable medium claim comprising substantially the same limitations as claim 6. As such, it is rejected for substantially the same reasons.
Claims 8, 17, and 22 are rejected under 35 U.S.C. 103 as being unpatentable over D'Innocenzo (US 20230142198 A1) in view of Kwatra (US 20240086190 A1) in further view of Bartholomew (US 20210297355 A1).
As per claim 8, D’Innocenzo in view of Kwatra fully discloses the limitations of claim 7.
Furthermore, Kwatra discloses:
Control the execution of the one or more container images at the development platform (“Additionally, server 206 includes a continuous delivery module 214 having functionality to package the build into a deployable image, such as a container or virtual machine (VM) image, configure the deployable image for a runtime environment, and deploy the configured image in the production environment, among other functionality such as load testing.”, 0039 ; “Aspects of the present invention relate generally to software development environments and, more particularly, to systems, computer program products, and methods of automating software development, security, and operations (DevSecOps).”, 0015)
D'Innocenzo in view of Kwatra may disclose the above limitations of claim 8, but they do not explicitly disclose the performance of one or more workloads being distributed among a selected set of edge hardware.
However, Bartholomew discloses:
the execution includes performance of one or more workloads distributed among a selected set of hardware of the plurality of types of edge computing hardware (“"In another embodiment, aspects of the disclosure relate to a system configured for administering a distributed edge computing system utilizing an adaptive edge engine… identify, from the set of endpoints, an optimal set of endpoints for deploying the first workload based in part on the executing the at least one functional strategy; and update a state store, the state store comprising one or more states of workload-endpoint pairs, the workload-endpoint pairs associated with the one or more workloads and the plurality of endpoints.", 0019)
It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the system of D’Innocenzo in view of Kwatra with that of Bartholomew in order to provide the development platform for container deployment with a method for organization and operation of data structures and the algorithms for manipulating data in such structures which improves the fundamental operation of the computing system (Bartholomew, [0065]).
As per claim 17, it is a non-transitory machine-readable medium claim comprising substantially the same limitations as claim 8. As such, it is rejected for substantially the same reasons.
As per claim 22, D’Innocenzo in view of Kwatra fully discloses the limitations of claim 19.
Furthermore, D’Innocenzo discloses:
the development platform comprises a plurality of types of edge computing hardware available for execution of the one or more containers ("In some embodiments, the present disclosure may be implemented in a mobile edge computing (MEC) environment implemented in conjunction with a 4G, 5G, or other cellular network.", 0029 ; "It should also be appreciated that a server, gateway, or other computing device may comprise any combination of hardware or software that can interact and perform the described types of functionality, including without limitation desktop or other computers, database servers, network storage devices and other network devices, PDAs, tablets, smartphone, Internet appliances, television-based systems (e.g., using set top boxes and/or personal/digital video recorders), and various other consumer products that include appropriate communication capabilities.", 0028)
Furthermore, Kwatra discloses:
Control the execution of the one or more container images at the development platform (“Additionally, server 206 includes a continuous delivery module 214 having functionality to package the build into a deployable image, such as a container or virtual machine (VM) image, configure the deployable image for a runtime environment, and deploy the configured image in the production environment, among other functionality such as load testing.”, 0039 ; “Aspects of the present invention relate generally to software development environments and, more particularly, to systems, computer program products, and methods of automating software development, security, and operations (DevSecOps).”, 0015)
D'Innocenzo in view of Kwatra may disclose the above limitations of claim 22, but they do not explicitly disclose the performance of one or more workloads being distributed among a selected set of edge hardware.
However, Bartholomew discloses:
the execution includes performance of one or more workloads distributed among a selected set of hardware of the plurality of types of edge computing hardware (“"In another embodiment, aspects of the disclosure relate to a system configured for administering a distributed edge computing system utilizing an adaptive edge engine… identify, from the set of endpoints, an optimal set of endpoints for deploying the first workload based in part on the executing the at least one functional strategy; and update a state store, the state store comprising one or more states of workload-endpoint pairs, the workload-endpoint pairs associated with the one or more workloads and the plurality of endpoints.", 0019)
Claims 9 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over D'Innocenzo (US 20230142198 A1) in view of Kwatra (US 20240086190 A1) in further view of Bartholomew (US 20210297355 A1) in further view of Guim Bernat (US 20210144517 A1) in further view of Wang (US 20230325267 A1).
As per claim 9, D’Innocenzo in view of Kwatra in further view of Bartholomew fully discloses the limitations of claim 8.
Furthermore, D’Innocenzo discloses:
coordinating a deployment request at the development platform for the execution of the one or more container images, (“Referring to FIG. 5B, operation 551 illustrates receiving, by a service running in the cloud computing environment, a plurality of Helm charts associated with a function to be deployed in the cloud computing environment.”, 0044)
Furthermore, Kwatra discloses:
the development platform (“Aspects of the present invention relate generally to software development environments “, 0001)
D’Innocenzo in view of Kwatra may disclose the above limitations of claim 9, however, they do not explicitly disclose a distributed queue.
However, Guim Bernat discloses:
using a distributed queue of the development platform, (“The globally shared or subscribeable queue may also be invoked, observed, or implemented as a result of service operations and service functions in the edge computing system (e.g., to support sharing among services in FaaS or EaaS settings). Thus, features of the preceding examples (and other features of distributed queues) may be combined with any of the other Examples herein to configure an edge cluster or edge cloud system, as coordinated or designed by a system orchestrator or architect.”, 0449)
a multi-container service; wherein the multi-container service of the development platform is used to coordinate distribution of the one or more container images and other container images, among the plurality of types of edge computing hardware, based on the distributed queue (“FIG. 9 illustrates various compute arrangements deploying containers in an edge computing system… This arrangement is adapted for use of multiple tenants in system arrangement 930 (using compute nodes 936), where containerized pods (e.g., pods 912), functions (e.g., functions 913, VNFs 922, 936), and functions-as-a-service instances (e.g., FaaS instance 915) are launched within virtual machines (e.g., VMs 934, 935 for tenants 932, 933) specific to respective tenants (aside the execution of virtualized network functions).”, 0151 ; “Various device implementation examples of a subscribeable and distributed edge queue may be provided within service orchestration and execution systems, as deployed in any number of edge computing hardware, circuitry, node, or system arrangements (e.g., edge cloud 110, and the edge computing system configurations depicted in FIGS. 3 to 22D). Various method examples may include adding, coordinating, and removing information from the globally accessible queue, and executing jobs (one or more services, service actions, workflows, etc.) according to a coordinated use of the queue.”, 0448)
It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the teachings of D’Innocenzo in view of Kwatra in further view of Bartholomew with those of Guim Bernat, in order to provide the development platform with a distributed queue, as well as the ability to serve and respond to multiple applications (e.g., object tracking, video surveillance, connected cars, etc.) in real time and the ability to meet ultra-low latency requirements for these applications (Guim Bernat, [0973]).
D'Innocenzo in view of Kwatra in further view of Bartholomew in further view of Guim Bernat discloses the above limitations of claim 9, but does not explicitly disclose an edge monitor.
However, Wang discloses:
an edge monitor … wherein the edge monitor of the development platform is used to monitor the distributed queue and the multi-container service for successful execution of the one or more container images in addition to other container images. (“The computer installs a privileged container corresponding to the pending task in each respective edge device of the target group of edge devices to monitor execution of a child task by an application container in a given edge device of the target group of edge devices.”, 0005 ; Examiner Note: the privileged container equates to an edge monitor)
The system of D’Innocenzo in view of Kwatra in further view of Bartholomew in further view of Guim Bernat in further view of Wang would provide an edge monitor and a distributed queue to a CaaS Development platform. It would have been obvious to one of ordinary skill in the art to combine the teachings of of D’Innocenzo in view of Kwatra in further view of Bartholomew in further view of Guim Bernat with those of Wang in order to provide a method which improves edge computing performance by enabling dynamic task assignment to edge devices, selective privileged container augmentation of edge devices, and automatic failed task recovery of application workloads on edge devices within an edge computing environment (Wang, [0045]).
As per claim 18, it is a non-transitory machine-readable medium claim comprising substantially the same limitations as claim 9. As such, it is rejected for substantially the same reasons.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Lee (US 20170054759 A1) – discloses a method and apparatus for security checking of image for container comprising; receiving an image for a container, identifying one or more layers of the image, collecting a path of a security configuration file, and searching the path and checking whether a security configuration file violates a predetermined security policy.
Shah (US 11861342 B2) – discloses a system for enhanced cloud computing deployment comprising; deployment tools, a set of container files to provide a server environment, and configuration data for the container images.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ROSS MICHAEL VINCENT whose telephone number is (703)756-1408. The examiner can normally be reached Mon-Fri 8:30AM-5:30PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, April Blair can be reached at (571) 270-1014. 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.
/R.M.V./
Examiner, Art Unit 2196
/APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196