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 .
Response to Arguments
Applicant's arguments filed 7 August 20266 have been fully considered but they are not persuasive.
Applicant contends that claim 1, as amended, is not obvious in view of Shah, Marinelli, and Harper, and specifically, Shah does not teach “storage nodes are disconnected from the internet,” because Shah “does not provide any indication or suggestion that the server environments in the cloud computing account are disconnected from the internet.” Remarks at 7-9.
The Examiner respectfully disagrees. Although Shah discloses “deploy server environments in the cloud computing account of the customer without granting permissions to access the cloud computing account of the customer” (¶ 10), Harper discloses “a runtime subsequent to the build time when the host environment is not connected to a network” (¶ 49). Harper further discloses “the host environment 100 may be unconnected to an external network or otherwise unable to access a network connection (e.g., at run time)” (¶ 29).
The Examiner finds a person having ordinary skill in the art would have found “the zero-touch storage node is disconnected from the internet,” as recited in claim 1, obvious in view of Harper’s teaching of a host environment unconnected to an external network.
Regarding claim 5, Applicant contends that Harper does not teach “each tarball in the plurality of tarballs includes distinct container images,” because Harper is merely directed to a teaching that “multiple container images 122 may exist.” Remarks at 9.
The Examiner respectfully disagrees. Harper discloses that “manifest artifacts 118 may include container images 122 (e.g., formatted as Tape ARchive files or “tarballs”, .tar, .tar.gz)” (¶ 32) and “manifest artifacts (118, FIG. 1) of the SMCO system 116 may include a full version or a partial/incremental version of an application 104 to be updated.” The Examiner finds a person having ordinary skill would have found the recited “each tarball in the plurality of tarballs includes distinct container images” obvious in view of Harper’s disclosure of manifest artifacts containing container images formatted as tarballs.
Regarding claim 9, Applicant contends that Harper does not teach “the Autodiscover capability identifies when new container images should be created based on detection of a tool update and/or a new script being available,” because “none of the references disclose “a process for detecting when the new container images should be created.” Remarks at 9-10.
The Examiner respectfully disagrees. Harper discloses “the manifest launcher 120 may execute full or patch installations of an associated application (104, FIG. 1) (add, remove, update), e.g., at startup or in response to a software update request, based on the associated application packages in the manifest artifact” (¶ 37). Further, Shah discloses “[w]hen a software developer completes code and merges it into the code repository, the computer system 110 can trigger an automated job (e.g., including a “docker build” command) to build a container image 113 based on an underlying Docker file” (¶ 23).
The Examiner finds a person having ordinary skill would have found the recited “the Autodiscover capability identifies when new container images should be created based on detection of a tool update and/or a new script being available” obvious in view of Harpers teaching of installation at startup or in response to a software update request and Shah’s teaching of building of container images when a software developer completes code and merges it into a code repository.
Claim Objections
Claim 12 is objected to because of the following informalities: “groups” should be “grouped.” Appropriate correction is required.
Claim 1, 10, and 19 are objected to because of the following informalities: “unziping” should be “unzipping.” Appropriate correction is required.
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-20 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 recites the limitation “the tarball.” There is insufficient antecedent basis for this limitation in the claim. Claims 2-20 require commensurate subject matter; therefore, they are rejected for the same reason.
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.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Shah (US 2023/0244466) and further in view of Marinelli (US 7,403,987) and further in view of Harper (US 2023/0044016).
Regarding claim 1, Shah teaches: A method comprising:
validating a distributed computing storage platform with zero-touch storage node containers (¶ 2, “Using cloud computing systems provides many advantages, such as on-demand availability of computer system resources, scalability of data storage and computing power, without requiring direct active management by the user”) by;
creating a container image including a tools repository (¶ 23, “build a container image 113 based on an underlying Docker file” and ¶ 21, “Using the deployment tools and API already established in the account 150, as well as the container images and configuration data retrieved earlier, the administrator 102 can create, run, and manage server environments, with desired combinations of containers, in the account 150 without any communication with the software provider's system 110”),
pushing the container image to a repository (¶ 25, “the certified versions of the container images 113 and configuration data 114 are added to the repository 111”),
pulling the container image from the repository a local folder and saving the container image in the local folder (¶ 27, “invoking the deployment package 112 can cause the cloud computing account 150 to automatically retrieve the container images 113, configuration data 114, and automation data 115 over the network 140 and store them in the cloud computing account 150”),
creating a container to import the container image as well as tools repository into a plurality of storage nodes (¶ 14, “creating a namespace for a new environment, identifying a set of containers needed for the new environment, and running, in the created namespace, instances of the identified set of containers based on the retrieved container images stored in the cloud computing account”).
Shah does not teach; however, Marinelli discloses: creating an inventory configured to group the plurality of storage nodes and creating an alias for each group in the plurality of storage nodes (col. 29:27-32, “the group utility may be provided through the SAN manager. The group utility may facilitate the management of end-user resources as logical groups of SAN objects. The group utility may be used to create logical storage groups where device membership may be based on zoning, LUN masking, hosts etc.”),
executing the storage operations and storing results of the storage operations in a specific directory (col. 14:18-22, “SAN management tasks that may be performed as transactions may include one or more of, but are not limited to: LUN binding tasks for creating an access path between an addressable storage unit of a storage system coupled to a SAN fabric and a fabric port of the storage system”),
collecting the results of each executed storage operation (col. 14:1-4, “The SAN management server 200 may obtain results 180 of the operations of the transaction from the affected SAN objects and/or persistent store 172, verify from the results if the operations as indicated by the transaction 178 completed successfully”), and
logging back to the local folder after a command is executed (col. 25:26-27, “the SAN management system may log data collected by the alarm service in a database 226”).
It would have been obvious to a person having ordinary skill in the art, before the effective filing date of the invention, to have applied the known technique of creating an ansible inventory configured to group the plurality of storage nodes and creating an alias for each group in the plurality of storage nodes, executing the storage operations and storing results of the storage operations in a specific directory, collecting the results of each executed storage operation, and logging back to the local folder after a command is executed and cleaning up the container, as taught by Marinelli, in the same way to the validating a distributed computing storage platform, as taught by Shah. Both inventions are in the field of deploying containers, and combining them would have predictably resulted in “performing transactional management tasks on a Storage Area Network (SAN),” as indicated by Marinelli (col. 2:33-35).
Shah and Marinelli do not teach; however, Harper discloses: the zero-touch storage node is disconnected from the internet (¶ 29, “the host environment 100 may be unconnected to an external network or otherwise unable to access a network connection (e.g., at run time)”);
extracting the container and copying the tarball from the container into the storage nodes (¶ 32, “manifest artifacts 118 may include container images 122 (e.g., formatted as Tape ARchive files or “tarballs”, .tar, .tar.gz)” and ¶ 49, “updates the application with a container runtime environment (CRE) of the host environment by extracting containers from the manifest artifacts and into local container registries of the CRE”),
unziping the tarball on each of the storage nodes in the plurality of storage nodes (¶ 14, “extracting containers from the manifest artifacts to a local container registry of the CRE as provided for by the configuration tools”); and
and cleaning up the container (¶ 8, “the manifest launcher removes unused CRE objects from local container registries subsequent to the application update”).
It would have been obvious to a person having ordinary skill in the art, before the effective filing date of the invention, to have applied the known technique of extracting the container and copying the tarball from the container into the storage nodes, unziping the tarball on each of the storage nodes in the plurality of storage nodes; and cleaning up the container, as taught by Harper, in the same way to the validating a distributed computing storage platform, as taught by Shah and Marinelli. Both inventions are in the field of deploying containers, and combining them would have predictably resulted in “service management and container orchestration of applications configured to execute within a host environment,” as indicated by Harper (¶ 2).
Regarding claim 2, Harper teaches: The method of claim 1, wherein the tools repository includes at least validation tools (¶ 32, “manifest artifacts 118 may include container images 122 (e.g., formatted as Tape ARchive files or “tarballs”, .tar, .tar.gz) and any associated container configuration tools 124 (e.g., configurations, data, and scripts necessary for setup and deployment of containers and container suites, application version information and dependency policies (full or patch versions of applications 104”).
Regarding claim 3, Marinelli teaches: The method of claim 1, wherein the plurality of storage nodes are grouped and aliased based on storage characteristics of each individual storage node (col. 12:42-43, “Embodiments of the SAN manager 202 may include a group utility for defining and naming groups of SAN objects based on quality of service (QoS) criteria”).
Regarding claim 4, Shah teaches: The method of claim 1, wherein the zero-touch storage node containers lack login access privilege (¶ 10, “create and deploy server environments in the cloud computing account of the customer without granting permissions to access the cloud computing account of the customer”).
Regarding claim 5, Harper teaches: The method of claim 1, wherein the tarball is selected from a plurality of tarballs (¶ 32, “manifest artifacts 118 may include container images 122 (e.g., formatted as Tape ARchive files or “tarballs”, .tar, .tar.gz)”), and wherein each tarball in the plurality of tarballs includes distinct container images (¶ 32, “manifest artifacts 118 may include container images 122 (e.g., formatted as Tape ARchive files or “tarballs”, .tar, .tar.gz)”).
Regarding claim 6, Harper teaches: The method of claim 5, wherein the plurality of storage nodes is a cluster configuration (¶ 28, “the host environment 100 may be distributed throughout more than one appliance (e.g., a Kubernetes cluster or other type of distributed environment)”), and wherein each storage node in the cluster configuration is validated using a different set of container images contained in the tarball (¶ 43, “a manifest artifact 118 may incorporate more than one application artifact 118a-b and/or application 104, each individual application including any associated container images 122 or container suites and configuration tools 124, 124a-b” and ¶ 32, “manifest artifacts 118 may include container images 122 (e.g., formatted as Tape ARchive files or “tarballs”, .tar, .tar.gz)”).
Regarding claim 7, Harper teaches: The method of claim 6 further comprising identifying a tarball corresponding to each storage node in the plurality of storage nodes (¶ 37, “the manifest launcher 120 may execute full or patch installations of an associated application (104, FIG. 1) (add, remove, update), e.g., at startup or in response to a software update request, based on the associated application packages in the manifest artifact (118, FIG. 1; e.g., container images (122, FIG. 1) used by the package in “tarball” form, command line tools (e.g., YAML docker compose)”) and pushing the identified tarball to the corresponding storage node (¶ 39, “converting the downloaded containers into container images 122 (e.g., tarball format (.tgz, .tar.gz., etc.)”).
Regarding claim 8, Harper teaches: The method of claim 1, wherein the distributed computing storage platform includes an Autodiscover capability (¶ 39, “the manifest builder 318 may (e.g., at build time) generate manifest artifacts 118 by downloading containers (e.g., from container registries 402) and any associated configuration tools 124 retrieved from configuration repositories 404”) configured to identify when a new container image should be created and pushed to the repository (¶ 38, “the transition state operator 316 may be notified of any detected drift, and may take steps to transition a current application state to match the desired state (e.g., adding, removing, or updating services to re-apply the latest desired state)”).
Regarding claim 9, Harper teaches: The method of claim 8, wherein the Autodiscover capability identifies when the new container image should be created by identifying at least one of a tool update and a new script being available (¶ 13, “Based on the retrieved configuration tools and generated container images, the manifest builder generates manifest artifacts loadable to the host environment for a subsequent runtime (e.g., when the SMCO system may be without network access)”).
Claims 10-20 recite commensurate subject matter as claims 1-9. Therefore, they are rejected for the same reasons.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JACOB D DASCOMB whose telephone number is (571)272-9993. The examiner can normally be reached M-F 9:00-5:00.
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, Pierre Vital can be reached at (571) 272-4215. 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.
/JACOB D DASCOMB/Primary Examiner, Art Unit 2198
Prosecution Insights