DETAILED ACTION
The Office Action is in response to claims filed 3/14/2024.
Claim 25 is cancelled.
Claims 1-24 are currently amended.
Claims 1-24 are pending.
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 .
Drawings
The drawings are objected to because the unlabeled rectangular boxes shown in the drawings should be provided with descriptive text labels. Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Claim Objections
Claims 3, 6-8, 14, are objected to because of the following informalities:
Claims 3 and 14 are objected to for a minor informality. The claims recite the limitation “based on a result of the verification if the verification on the integrated configuration file fails”. For the purposes of consistency and clarity, Applicant is recommended to amend as follows: “based on a result of the verification on the integrated configuration file if the verification on the integrated configuration file fails”.
Claims 6 and 17 are objected to for a minor informality. The claims recite the limitation “based on a result of the verification if the verification on the image configuration file fails”. For the purposes of consistency and clarity, Applicant is recommended to amend as follows: “based on a result of the verification on the image configuration file if the verification on the image configuration file fails”.
Claims 8 and 19 are objected to for a minor informality. The claims recite the limitation “based on a result of the verification if the verification on the application configuration file fails”. For the purposes of consistency and clarity, Applicant is recommended to amend as follows: “based on a result of the verification on the application configuration file if the verification on the application configuration file fails”.
Claims 7 and 18 are objected to for a minor grammatical informality. The claim currently recites “obtaining information about a basic image, image push, and an image service port from the source code, the integrated configuration file, and the image configuration file”. Applicant is recommended to amend as follows: “obtaining information about a basic image, image push,
Claim 17 is objected to for a minor grammatical informality. The claim currently recites “The apparatus according to any one of claims 12”. Applicant is recommended to amend as follows: “The apparatus according to claim 12”.
Appropriate correction is required.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: an obtaining unit, an integrated management unit, an image management unit, and an application management unit in claim 12-22.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
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.
Claims 1-22 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.
Claims 1 and 12 recite the limitation “obtaining source code associated with a containerized application”. It is unclear if “a containerized application” refers to the aforementioned “a containerized application” or to something else entirely. Thus, the claim is considered vague and indefinite.
Claims 2-11 and 13-22 are rejected in light of their chain of dependency upon claims 1 and 12 respectively.
Claim 2 recites the limitation “an integrated configuration file”. It is unclear if “an integrated configuration file” refers to the aforementioned “an integrated configuration file” in claim 1 or to something else entirely. Thus, the claim is considered vague and indefinite.
Claims 3 and 14 recite the limitation “before the constructing, by using the integrated configuration file, a component associated with the source code;”. It is unclear if “a component associated with the source code” refers to the aforementioned “a component” in claim 1 or to something else entirely. Thus, the claim is considered vague and indefinite.
Claim 4 recites the limitation “generating an image configuration file based on the source code”. It is unclear if “an image configuration file” refers to the aforementioned “image configuration file” in claim 1 or to something else entirely. Thus, the claim is considered vague and indefinite.
Claim 5 is rejected in light of its dependency upon claim 4.
Claim 6 recites the limitation “a container image associated with the source code”. It is unclear if “a container image” refers to the aforementioned “a container image” in claim 1 or to something else entirely. Thus, the claim is considered vague and indefinite.
Claim 7 recites the limitation “generating an application configuration file”. It is unclear if “an application configuration file” refers to the aforementioned “application configuration file” in claim 1 or to something else entirely. Thus, the claim is considered vague and indefinite.
Claim 10 recites the limitation “deploying the containerized application to an edge device comprises…” It is unclear if “an edge device” refers to aforementioned “edge device” in claim 9 or to something else entirely. Thus, the claim is considered vague and indefinite.
Claim 21 recites the limitation “the deployment unit” and “the edge device”. There is a lack of antecedent basis for these limitations in the claims. For the purposes of compact prosecution, applicant is recommended to adjust the claim dependency with the following amendment: “The apparatus according to claim 20”.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 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 –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(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.
Claims 1, 9, 11-12, 20, and 22-24 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by US 20220012045 A1 hereinafter “Rudraraju”.
With regards to claim 1,
A method for automatically configuring and deploying a containerized application, the method comprising: (Rudraraju [0107], “Table 4 shows an example of automatically generated custom resource operator code that can be used to deploy an application, in accordance with embodiments. In the example of Table 4, the control plane is a container orchestration layer that exposes the API and interfaces to define, deploy, and manage the lifecycle of containers.”)
obtaining source code associated with a containerized application; (Rudraraju [0025], “The user systems 12 can communicate with system 16 using TCP/IP and, at a higher network level, other common Internet protocols to communicate, such as Hypertext Transfer Protocol (HTTP), File Transfer Protocol (FTP), Andrew File System (AFS), Wireless Application Protocol (WAP), Internet Protocol (IP), Internet Protocol Security (IPsec), Session Initiation Protocol (SIP) with Real-Time Transport Protocol (RTP or Secure RTP (SRTP), Internet Control Message Protocol (ICMP), User Datagram Protocol (UDP), QUIC (sometimes referred to as “Quick UDP Internet Connections”), Stream Control Transmission Protocol (SCTP), Web-based secure shell (SSH), Extensible Messaging and Presence Protocol (XMPP), WebSocket protocol, Internet Group Management Protocol (IGMP), Internet Control Message Protocol (ICMP), etc. In an example where HTTP is used, each user system 12 can include an HTTP client commonly referred to as a “web browser” or simply a “browser” for sending and receiving HTTP signals to and from an HTTP server (also referred to as a “web server”) of the system 16. In this example, each user system 12 may send and receive HTTP messages where a header of each message includes various operating parameters and the body of the such messages may include code or source code documents (e.g., HTML, XML, JSON, Apex®, CSS, JSP, MessagePack™, Apache® Thrift™, ASN.1, Google® Protocol Buffers (protobuf), DBOs, or some other like object(s)/document(s)).”)
generating an integrated configuration file based on the source code, and constructing, with the integrated configuration file, a component associated with the source code; (Rudraraju [0068-69], “In FIG. 2, a Custom Request 202 may be identified that includes requirements that may reflect business logic, operational requirements, business rules such as defining authorizations for access or for other resources based upon a type of a user for custom resource components that make up the deployed application/service [constructing, with the integrated configuration file, a component associated with the source code]. Based upon the Custom request 202, one or more custom resource components 204 are identified. In this example, custom resource components 204 may include a controller file 206, a resource file 208, and a resource container file 210 [generating an integrated configuration file].”)
generating an image configuration file based on the source code and the integrated configuration file, and generating, with the image configuration file, a container image associated with the source code; (Rudraraju [0090-91], “a container image is built and pushed [generating an image configuration file]. A controller container image (e.g., a controller DockerImage) contains all the necessary information that is required to create the operator image 218 and push it to the container 222 (e.g., a Docker® container or the like). All of the user's CRUD operations are place in the controller container image. In the example of FIG. 2, this controller container image may be the resource CRUD container image 220. To generate the operator image 218, the following command may be run: craft build image -b -a<path-to-controller.json>--podDockerFile <path-to-DockerFile> [and generating, with the image configuration file, a container image associated with the source code]”)
Generating an application configuration file based on the source code, the integrated configuration file, and the image configuration file; (Rudraraju [0101], “As alluded to previously, a developer provides the configurations and validations needed to develop the CRD in the form of the controller file 206 (e.g., controller.json) and resource file 208 (e.g., resource json) [the integrated configuration file]. These configurations and validations are then used by CRAFT 212 to develop an operator template and operator metadata in the form of the operator file 218 (e.g., operator.yaml) [Generating an application configuration file], build operator container image 218, and deploy the operator 220 onto a cluster. CRAFT 212 generates the operator-template including information about the controllers, reconcilers, configurations (e.g., web hooks, RBAC, etc.), and the application package (e.g., main.go in Golang) [based on the source code]. This operator template controls the operator variables that need to be controlled, such as reconciliation frequency, resource manager, CRUD operations deployment, and the like. The operator file 218 generated by CRAFT contains all the metadata about the operator such as, for example, schema validations, specification properties, the API version rules, and the like. The operator file 218 helps in creating the operator and deploying it into the cluster. The operator file 218 code is generated by CRAFT and includes the code used to deploy the operator to the cluster and make changes to the operator variables (e.g., reconciliation frequency, etc.) when required.”) [Examiner’s Note: Metadata can be in the form of the additional information required for the image configuration in the form of the image configuration file] and
generating the containerized application using the application configuration file and the container image. (Rudraraju [0043], “The stream processor(s) may be implemented using any stream/event processing engines or stream analytics engines such as, for example, Apache® Kafka®, Apache® Storm®, Apache® Flink®, Apache® Apex®, Apache® Spark®, IBM® Spade, Nvidia® CUDA™, Intel® Ct™, Ampa™ provided by Software AGO, StreamC™ from Stream Processors, Inc., and/or the like. In some implementations, the stream processor(s) 105 may implement or operate virtual machines (VMs), containers, or other suitable runtime environment(s) in which user apps, web apps, and/or CP apps may be executed. In some implementations, the query processor(s) 103 may also be stream processor(s) that are the same or similar to stream processor(s) 105. In some embodiments, the stream processor(s) 105 may be used to orchestrate container spin-up and deployment, as well as generate operators based on one or more configuration files according to the embodiments discussed herein.”)
With regards to claim 9, the rejection of claim 1 is incorporated.
Rudraraju further teaches deploying the containerized application to an edge device. (Rudraraju [0016], “Cloud computing refers to a paradigm for enabling network access to a scalable and elastic pool of shareable computing resources with self-service provisioning and administration on-demand and without active management by users. Computing resources (or simply “resources”) are any physical or virtual component, or usage of such components, of limited availability within a computer system or network. Examples of resources include usage/access to, for a period of time, servers, processor(s), storage equipment, memory devices, memory areas, networks, electrical power, input/output (peripheral) devices, mechanical devices, network connections (e.g., channels/links, ports, network sockets, etc.), operating systems, virtual machines (VMs), software/applications, computer files, and/or the like. Cloud computing provides cloud computing services (or cloud services), which are one or more capabilities offered via cloud computing that are invoked using a defined interface (e.g., an API or the like). Multi-tenancy is a feature of cloud computing where physical or virtual resources are allocated in such a way that multiple tenants and their computations and data are isolated from and inaccessible to one another. As used herein, the term “tenant” refers to a group of users (e.g., cloud service users) who share common access with specific privileges to a software instance and/or a set of computing resources. Tenants may be individuals, organizations, or enterprises that are customers or users of a cloud computing service or platform.”)
With regards to claim 11, the rejection of claim 1 is incorporated.
Rudraraju further teaches wherein the containerized application comprises an artificial intelligence application (Rudraraju [0043], “In some implementations, the stream processor(s) 105 is/are systems and/or applications that send or receive data streams and execute the applications or analytics logic in response to detecting events or triggers in/from the data streams. The stream processor(s) 105 process data directly as it is produced or received and detect conditions from the data streams within a relatively small time period (e.g., measured in terms of milliseconds to minutes). The stream processor(s) 105 may be implemented as software components (e.g., software engines, software agents, artificial intelligence (AI) agents, modules, objects, or other like logical units), as individual hardware elements, or a combination thereof … AI accelerating co-processor(s), tensor processing units (TPUs), and/or the like. In some embodiments, the stream processor(s) may be implemented using stream processor(s), which are systems and/or applications that send or receive data streams and execute the applications or analytics logic in response to detecting events or triggers from the data streams. The stream processor(s) process data directly as it is produced or received and detect conditions from the data streams within a relatively small time period (e.g., measured in terms of milliseconds to minutes) … In some implementations, the stream processor(s) 105 may implement or operate virtual machines (VMs), containers, or other suitable runtime environment(s) in which user apps, web apps, and/or CP apps may be executed.”)
Claims 12, 20, and 22 are directed to an apparatus corresponding to the method limitations as disclosed in claims 1, 9, and 11 respectively. Thus, claims 12, 20, and 22 are rejected for the same reasons set forth in claims 1, 9, and 11.
Claim 23 is directed to a computing device (Rudraraju FIG 1A.) corresponding to the method limitations as disclosed in claim 1. Thus, claim 23 is rejected for the same reasons set forth in claim 1.
Claim 24 is directed to a non-transitory computer readable storage medium corresponding to the method limitations as disclosed in claims 1. Thus, claim 24 is rejected for the same reasons set forth in claim 1.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 2, 7, 13, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Rudraraju in view of US 11650810 B1 hereinafter “Wang”.
With regards to claim 2, the rejection of claim 1 is incorporated.
Rudraraju does not teach: generating an integrated configuration file based on the source code comprises: determining a type of the source code;
obtaining information about a basic image and a dependency relationship from the source code;
and generating the integrated configuration file based on the type of the source code and by using the information about the basic image and the dependency relationship.
However, in an analogous art Wang teaches generating an integrated configuration file based on the source code comprises: determining a type of the source code; (Wang Column 6 Lines 29-37, “As mention above, systems and techniques disclosed herein may use any type of retention policies. CLASS and RUN-TIME retention types of annotations may be built into binary byte-code and analyzed through scanning the binary byte-code annotations to get the annotation specified information. In the case of SOURCE retention types of annotations, the systems and techniques disclosed herein may analyze the annotations through source code analysis tools to get the annotations.”)
obtaining information about a basic image and a dependency relationship from the source code; (Wang Column 6 Lines 42-58, “The scanning may read all the class and method annotations to get the annotations A and B. The classes including annotation A may be identified as primary functionality of the associated container or microservice unit. Methods annotated with annotation B within the classes annotated with annotation A may be identified as methods to be exposed by the container or microservice unit APIs. In some examples, retrieval and/or analysis of CLASS and RUN-TIME retention policy annotations in the standalone may be performed by using a library such as the Apache BCEL (Binary Code Engineering Library). Containerization of the application may then be performed based on the retrieved information. More particularly, the container image may be built from classes annotated with annotation A and their dependencies and API model generation may be implemented based on methods annotated with annotation B.”)
and generating the integrated configuration file based on the type of the source code and by using the information about the basic image and the dependency relationship. (Wang Column 7 Lines 40-52, “As mentioned above, once annotations A and B have been identified and analyzed, the container images and an API model may be generated. Using Docker containers as an example, building the container image may include creating a container work is created. Jar files may be generated [generating the integrated configuration file] classes including annotation A [based on the type of the source code and by using the information about the basic image]and for any dependencies. Depending on the implementation, the dependencies may be identified using information from annotation A annotations, additional annotations or through additional analysis (e.g., sandbox or other dependency detection) [and the dependency relationship].”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Wang into the teachings of Rudraraju. This combination of teachings would have resulted in a method to configure dynamic container deployment, as in Rudraraju, with annotations to analyze source code for containerized application deployment, as in Wang. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of using annotations to create one or more containers that can be leveraged by applications and microservice units (Wang Column 2 Lines 45-53)
With regards to claim 7, the rejection of claim 1 is incorporated.
Rudraraju does not teach: obtaining information about a basic image, image push, and an image service port from the source code, the integrated configuration file, and the image configuration file;
and generating the application configuration file by using the information about the basic image, the image push, and the image service port.
However, in an analogous art Wang teaches obtaining information about a basic image, image push, and an image service port from the source code, the integrated configuration file, and the image configuration file;
and generating the application configuration file by using the information about the basic image, the image push, and the image service port.
(Wang Column 9 Lines 20-50, “At 110, the containerization service may perform containerization configuration based on the final container definition(s). In some examples, the containerization configuration may set forth information for the running of the produced container(s) or microservice unit(s), such as the amount of memory needed, the number of instances of a container that should be executed, the port numbers that should be used [and an image service port], and so on … At 112, based on the container definition(s) and containerization configuration, the containerization service may gather components to build the container(s) or microservice unit(s). Example components include executable files, configuration files, libraries, and binaries [from the source code, the integrated configuration file, and the image configuration file]. At 114, the containerization service may use metadata (e.g., the container definition and any other information derived from the discovery phase) and the components gathered at 112 together with the containerization configuration to build a container image for the container or microservice unit. Though details are implementation specific, in general, the containerization service may build the container image by generating a standalone, executable package that includes everything needed to run the microservice unit including the executables [and generating the application configuration file], dependencies and configuration information (e.g., code, runtime, system tools, system libraries, and settings) [obtaining information about a basic image, image push].”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Wang into the teachings of Rudraraju. This combination of teachings would have resulted in a method to configure dynamic container deployment, as in Rudraraju, with annotations to analyze source code for containerized application deployment, as in Wang. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of using annotations to create one or more containers that can be leveraged by applications and microservice units (Wang Column 2 Lines 45-53)
Claims 13 and 18 are directed to an apparatus corresponding to the method limitations as disclosed in claims 2 and 7 respectively. Thus, claims 13 and 18 are rejected for the same reasons set forth in claims 2 and 7.
Claims 3 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Rudraraju in view of US 20100107153 A1 hereinafter “Kwon”.
With regards to claim 3, the rejection of claim 1 is incorporated.
Rudraraju does not teach: performing verification on the integrated configuration file before the constructing, by using the integrated configuration file, a component associated with the source code;
checking the integrated configuration file based on a result of the verification if the verification on the integrated configuration file fails;
and updating the integrated configuration file based on a result of the check and the source code.
However, in an analogous art Kwon teaches performing verification on the integrated configuration file before the constructing, by using the integrated configuration file, a component associated with the source code; (Kwon [0025], “The controller 14 analyzes a metadata file describing information about the first package file, stores the installation target files in the storage unit 17, and installs a file to be installed in the image forming apparatus when the file to be installed is determined according to a result of the metadata analysis. In other words, the controller 14 separates and analyzes the metadata file from the first package file, manages installation target files installed in the image forming apparatus, and installs a file to be installed in the image forming apparatus when the file is determined after the result of the analysis.”)
checking the integrated configuration file based on a result of the verification if the verification on the integrated configuration file fails; (Kwon [0040], “After analyzing the metadata file, the metadata processor 150 analyzes version information of a file in the metadata file, such that when there is no existing file information, the file is newly installed, or when a file having a different version from a previously installed file is requested, updates the previously installed file. In other words, the metadata processor 150 analyzes the metadata file received from the package file analyzer 145, records installation information, and stores information of a corresponding package file (PAR file), so that the package file may be later revised and/or deleted.”) [Examiner’s Note: failed verification is a result of license information, sign information, and EULA information in which requires installation by the installer for retrieval of the file]
and updating the integrated configuration file based on a result of the check and the source code. (Kwon [0043], “The metadata processor 150 checks the internal information, and then requests the installer unit 160 to install an actual file according to information about each application, driver, and/or firmware files. Then, according to version information of the file transmitted from the metadata processor 150, the installer unit 160 newly installs the file when there is no existing file information, or updates the file, when the file has a different version from a previously installed file.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Kwon into the teachings of Rudraraju. This combination of teachings would have resulted in a method to configure dynamic container deployment, as in Rudraraju, and facilitating the container image through a metadata file, as in Kwon. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of forming images that are tailored for installing integrated files therein.
Claim 14 is directed to an apparatus corresponding to the method limitations as disclosed in claim 3. Thus, claim 14 is rejected for the same reasons set forth in claim 3.
Claims 4-5 and 15-16 are rejected under 35 U.S.C. 103 as being unpatentable over Rudraraju in view of US 20200272427 A1 hereinafter “Wang2”.
With regards to claim 4, the rejection of claim 1 is incorporated.
Rudraraju does not teach: generating an image configuration file based on the source code and the integrated configuration file comprises: determining a type of the source code;
obtaining information about a basic image and a component from the source code and the integrated configuration file;
and generating the image configuration file based on the type of the source code and by using the information about the basic image and the component
However, in an analogous art Wang2 teaches generating an image configuration file based on the source code and the integrated configuration file comprises: determining a type of the source code; (Wang2 [0018], “In one aspect, using a specified command or the running process information such as, for example, process identifiers (“ID”), a command name), corresponding runtime environment information may be monitored and collected (e.g., an OS, binaries, libraries, environment variables, related files, related processes). That is, for the specified command, in order to move an application to container, a running process about the application is first required and then a corresponding runtime environment (“env”) information may be collected. If there is no running process, a command may be specified (e.g., “specified command”) about that application and the present invention may execute the specified command as a running process. Thus, the specified command or the “running process” is specifically about that application. A list dynamic dependencies “ldd” command may be used to collect which libraries are necessary for the application.”)
obtaining information about a basic image and a component from the source code and the integrated configuration file; (Wang2 [0020], “In another aspect, the present invention enables building a complex service into a container image, prepares all service related environment by editing a container file, and enables migration of an existing service from a host to a container image when lacking knowledge for the migration operation. In one aspect, the present invention may monitor/detect a service runtime environment and migrate the service runtime environment into the container image (e.g., docker image). With service information or “running process information” (e.g., a process ID, command name), the corresponding runtime environment information (e.g., dependent libraries, environment variables, related files, etc.) may be detected and collected.”)
and generating the image configuration file based on the type of the source code and by using the information about the basic image and the component (Wang2 [0021], “The collected runtime information can be verified. The same runtime environment may be created on a container, and this container will be saved as a container image (e.g., a docker image), which is the required/needed image (e.g., output or final output of the present invention). The container image can be updated if the service runtime environment is later changed.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Wang2 into the teachings of Rudraraju. This combination of teachings would have resulted in a method to configure dynamic container deployment, as in Rudraraju, and generating the container image through integration information and the resulting generated image file, as in Wang2. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of building a container from an image that defines what the container will hold and a variety of other configuration data to run an application (Wang2 [0014]).
With regards to claim 5, the rejection of claim 4 is incorporated.
Rudraraju further teaches generating the image configuration file based on one or more of […], security enhancement information […] (Rudraraju [0045], “generating the image configuration file based on one or more of an external dependency package configuration file, security enhancement information, and image cleaning information.)
Rudraraju does not teach: generating the image configuration file based on one or more of an external dependency package configuration file, [security enhancement information], and image cleaning information.
However, in an analogous art Wang2 teaches generating the image configuration file based on one or more of an external dependency package configuration file, [security enhancement information], and image cleaning information. (Wang2 [0068-69], “Starting in FIG. 6A, runtime information may be collected at startup time of an OS that executes process 1, process 2, and process 3, at blocks 602, 604, and 606 respectively. The collected information may include the startup time and location information associated process 1 at block 602, one or more dependent libraries associated with process 2 at block 604 [based on one or more of an external dependency package configuration file] … Also, any accessed files associated with process 1 at block 602 may also be collect. Upon collecting the runtime information, a command or running process (e.g., process 1 at block 602, process 2 at block 604, and/or process 3 at block 606) related environment may be verified. The command or running process may be originally provided. With user's request (e.g., request of an application developer), any unrelated running environment information may be cleaned (e.g., rename unrelated files, block a network connection from unrelated binaries/ports/hosts, unset the unrelated environment variables, etc.) on a host [and image cleaning information]”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Wang2 into the teachings of Rudraraju. This combination of teachings would have resulted in a method to configure dynamic container deployment, as in Rudraraju, and generating the container image through integration information and the resulting generated image file, as in Wang2. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of building a container from an image that defines what the container will hold and a variety of other configuration data to run an application (Wang2 [0014]).
Claims 15-16 are directed to an apparatus corresponding to the method limitations as disclosed in claims 4-5 respectively. Thus, claims 15-16 are rejected for the same reasons set forth in claims 4-5.
Claims 6 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Rudraraju in view of US 20190146772 A1 hereinafter “Griffin”.
With regards to claim 6, the rejection of claim 1 is incorporated.
Rudraraju does not teach: performing verification on the image configuration file before the generating, by using the image configuration file, a container image associated with the source code;
checking the image configuration file based on a result of the verification if the verification on the image configuration file fails;
and updating the image configuration file based on a result of the check, the source code, and the integrated configuration file.
However, in an analogous art Griffin teaches performing verification on the image configuration file before the generating, by using the image configuration file, a container image associated with the source code; (Griffin [0028], “The update engine 104 can communicate information related to an updated container image to the testing engine 106. For example, the update engine 104 can transmit an identifier of an updated container image to the testing engine. The identifier may be a name, filename, identification number, commit ID, or other identifier of the updated container image. The testing engine 106 can use the identifier to obtain the updated container image. For example, the update engine 104 can transmit a commit ID for an updated container image to the testing engine 106. The testing engine 106 can then access the repository 132 and obtain the updated container image using the commit ID.”)
checking the image configuration file based on a result of the verification if the verification on the image configuration file fails; (Griffin [0017], “The alert engine 102 can access a database 108 to detect an alert related to a piece of software. The alert can indicate a problem with the piece of software.”)
and updating the image configuration file based on a result of the check, the source code, and the integrated configuration file. (Griffin [0017], “If the update engine 104 detects the updated version of the container image 120a, the update engine 104 can update one or more other container images, such as container image 120b, that depend on container image 120a. In some examples, the update engine 104 can then communicate the updated version of container image 120b to the testing engine 106. The testing engine 106 can provision a test environment 128, perform one or more tests on the updated version of container image 120b to ensure that the updated version of container image 120b complies with one or more predefined criteria, and transmit the results of the tests to a client device 130 of a developer. In this manner, updating and testing of container images 118 can be performed automatically (e.g., with little or no human involvement).”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Griffin into the teachings of Rudraraju. This combination of teachings would have resulted in a method to configure dynamic container deployment, as in Rudraraju, alerting to problems of containers through checking images for automated updates, as in Griffin. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of launching containers from image files with problem transparency for updates (Griffin [0002-4]).
Claim 17 is directed to an apparatus corresponding to the method limitations as disclosed in claim 6. Thus, claim 17 is rejected for the same reasons set forth in claim 6.
Claims 8 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Rudraraju in view of US 20180150380 A1 hereinafter “Darbha”.
With regards to claim 8, the rejection of claim 1 is incorporated.
Rudraraju does not teach: performing verification on the application configuration file before [the generating the containerized application by using the application configuration file and the container image in combination;]
checking the application configuration file based on a result of the verification if the verification on the application configuration file fails;
and updating the application configuration file based on a result of the check, the source code, the integrated configuration file, and the image configuration file.
However, in an analogous art Darbha teaches performing verification on the application configuration file before the generating the containerized application by using the application configuration file and the container image in combination; (Darbha [0026-30], “One or more cycles of testing stage 240 may occur during development stage 230. Once software developers are confident that the developed application is running properly and/or no other bugs exist, the application may undergo deployment … Verification engine 330 may then perform one or more checks on resolved source code 325, flagging engine 340 may flag one or more issues with resolved source code 325 based on the one or more checks, and reporting engine 350 may generate a report comprising information about the one or more checks. The one or more modules of source code migration tool 120 may be executed by processor 160 and may be communicably coupled to memory 150 of source code migration tool 120. Accordingly, the various modules of source code migration tool 120 may access source code 150a of a plurality of applications 170, environment/config files 150b, metadata 150c for the plurality of applications 170, login credentials 150d, and server access details 150e which are stored in memory 150.”)
checking the application configuration file based on a result of the verification if the verification on the application configuration file fails; (Darbha [0049-53], “The flagged version of resolved source code 325 may enable a software developer to identify issues in resolved source code 325. In some embodiments, a report generated by reporting engine 350 is sent to a software developer for further attention to the issues remaining in resolved source code 325. An example of an algorithm that may be executed by reporting engine 350 is as follows: (1) receive, from verification engine, information about checks failed by resolved source code 325; (2) generate a report comprising an identification of each failed check that occurred in resolved source code; (3) receive a flagged version of resolved source code; and (3) send the generated report with the flagged version of resolved source code to a software developer … At step 420, source code migration tool 120 creates a copy of the source code 150a of the migrating application. In some embodiments, the copy of the source code 150a of the migrating application 170 is created by resolved source code file generation engine 340 of source code migration tool 120. After creating a copy of the source code 150a, the method 400 may continue to step 430.”)
and updating the application configuration file based on a result of the check, the source code, the integrated configuration file, and the image configuration file. (Darbha [0036], “Resolved source code file generation engine 340 may be configured to receive source code 150a of the migrating application, create a copy of the received source code 150a, and modify the copy of the source code to generate resolved source code 325. In some embodiments, resolved source code file generation engine 340 receives an identification of the migration application 170 from receiver 310 and retrieves the corresponding source code 150a from memory 150 (e.g., by querying memory 150). In other embodiments, resolved source code file generation engine 340 receives source code 150a corresponding to the migrating application 170 due to one or more actions of receiver 310. Upon receiving source code 150a, resolved source code file generation engine 340 may create a copy of the received source code 150a [the source code] and make modifications to the copy. In one embodiment, the modifications made to the copy include adding parameter values from environment/config files 150b into the copy. For example, resolved source code file generation engine 340 may substitute each parameter in source code 150a for a parameter value stored in environment/config files 150b [and the image configuration file]. In other words, resolved source code file generation engine 340 may be configured to resolve parameters that are identified in source code 150a (or rather, in the copy of source code 150a). The output of resolved source code file generation engine 340 is a modified copy of source code 150a, also referred to herein as resolved source code or resolved source code file 325 [and updating the application configuration file based on a result of the check].”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Darbha into the teachings of Rudraraju. This combination of teachings would have resulted in a method to configure dynamic container deployment, as in Rudraraju, while performing one or more checks to verify the application for eventual migration, as in Darbha. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of detecting issues in source code with checks in the production environment to generate a report accordingly to allow deployment with maximum confidence (Darbha [0015-16]).
Claim 19 is directed to an apparatus corresponding to the method limitations as disclosed in claim 8. Thus, claim 19 is rejected for the same reasons set forth in claim 8.
Claims 10 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Rudraraju in view of US 20190294461 A1 hereinafter “Woods”.
With regards to claim 10, the rejection of claim 9 is incorporated.
Rudraraju does not teach: wherein deploying the containerized application to an edge device comprises at least one of the following: sending the application configuration file to the edge device, so that the edge device generates the containerized application;
or pushing the generated containerized application to the edge device.
However, in an analogous art Woods teaches wherein deploying the containerized application to an edge device comprises at least one of the following: sending the application configuration file to the edge device, so that the edge device generates the containerized application;
or pushing the generated containerized application to the edge device. (Woods [0024], “In an example, physical host 110 may run one or more isolated guests, for example, VM 122, and containers 172 and 174. In an example, any of containers 172 and 174 may be a container using any form of operating system level virtualization, for example, Red Hat® OpenShift®, Docker® containers, chroot, Linux®-VServer, FreeB SD® Jails, HP-UX® Containers (SRP), VMware ThinApp®, etc. Containers may run directly on a host operating system or run within another layer of virtualization, for example, in a virtual machine. In an example, containers that perform a unified function may be grouped together in a container cluster that may be deployed together (e.g., in a Kubernetes® pod). In an example, a given service may require the deployment of multiple containers and/or pods in multiple physical locations.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Woods into the teachings of Rudraraju. This combination of teachings would have resulted in a method to configure dynamic container deployment, as in Rudraraju, and deployment of the application with a container to an external device, as in Woods. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of assuring that the necessary components for the application to execute are present and available to reduce compatibility problems on the host device in different environments (Woods [0012]).
With regards to claim 21,
Rudraraju does not teach: wherein the deployment unit is configured to perform at least one of the following:
send the application configuration file to the edge device, so that the edge device generates the containerized application; or
push the generated containerized application to the edge device.
However, in an analogous art Woods teaches send the application configuration file to the edge device, so that the edge device generates the containerized application; or
push the generated containerized application to the edge device. (Woods [0024], “In an example, physical host 110 may run one or more isolated guests, for example, VM 122, and containers 172 and 174. In an example, any of containers 172 and 174 may be a container using any form of operating system level virtualization, for example, Red Hat® OpenShift®, Docker® containers, chroot, Linux®-VServer, FreeB SD® Jails, HP-UX® Containers (SRP), VMware ThinApp®, etc. Containers may run directly on a host operating system or run within another layer of virtualization, for example, in a virtual machine. In an example, containers that perform a unified function may be grouped together in a container cluster that may be deployed together (e.g., in a Kubernetes® pod). In an example, a given service may require the deployment of multiple containers and/or pods in multiple physical locations.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Woods into the teachings of Rudraraju. This combination of teachings would have resulted in a method to configure dynamic container deployment, as in Rudraraju, and deployment of the application with a container to an external device, as in Woods. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of assuring that the necessary components for the application to execute are present and available to reduce compatibility problems on the host device in different environments (Woods [0012]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20200183766 A1 (Kumar-Mayernik) teaches: A system and computer-implemented method for container provenance tracking uses a build instruction file of a container image to output a new provenance document associated with the container image for distribution. For each file system layer of the container image specified in the build instruction file, an existing provenance document for the file system layer is inserted into the new provenance document.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TRAVIS VIET TRAN whose telephone number is (571)272-3720. The examiner can normally be reached Monday-Friday 8:30AM-5PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Wei Mui can be reached at 571-272-3708. 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.
/T.V.T./Examiner, Art Unit 2191 /WEI Y MUI/Supervisory Patent Examiner, Art Unit 2191