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 with respect to claim(s) 1-11, 13-16, 19, and 20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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 13, 19, and 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 13 recites the limitation “[t]he apparatus of claim 1” in line 1. There is insufficient antecedent basis for this limitation in the claim. For the purpose of examination, claim 13 is interpreted as “[t]he apparatus of claim [[1]]9 . . . .” Appropriate correction is required.
Claim 1 recites the limitation "[t]he system of claim 17" in line 1. There is insufficient antecedent basis for this limitation in the claim, because claim 17 has been canceled. For the purpose of examination, claim 19 is interpreted as “[t]he apparatus of claim [[1]]15 . . . .” Appropriate correction is required.
Claim 20 depends on claim 19; therefore, it is 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-11, 13, 15, 16, 19, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Suarez (US 2017/0177860) and further in view of Breternitz (US 8,887,056).
Regarding claim 1, Suarez teaches: A comprising:
uploading a plurality of Dockerfiles via a management application;
uploading, for each Dockerfile of the plurality of Dockerfiles, Dockerfile metadata via the management application (¶ 97, “In the example 1100, a customer 1166, uploads a set of build artifacts 1158, including the build file for the set of files, via an application programming interface of the managed source control service 1186”), wherein each Dockerfile of the plurality of Dockerfiles is configured to be converted into a container image such that a plurality of container images are created (¶ 97, “The managed source control service 1186 forwards the set of build artifacts 1158 to the automated build service 1184 builds the container image 1152 in accordance with the build file and the container engine type that the set of build artifacts 1158 have been configured for or specified as, and stores the container image 1152 in repository of the customer 1166 in the container registry 1102”);
presenting at least one search interface (¶ 75, “Such container images in a global repository may be available to for purchase (i.e., transacted) through the container marketplace 768, which may be an online marketplace in the form of a website or other user interface from which licenses for one or more container images may be selected and/or purchased by consumers”), wherein the at least one search interface enables searching the plurality of container images via Dockerfile metadata for a container image configured to operate an application on at least one third-party compute system (¶ 58, “the manifests/metadata is searched using a registry metadata service, such as the registry metadata service 222 of FIG. 2.”), and wherein the container image is one of the plurality of container images (¶ 119, “In 1502, the system performing the process 1500 may receive a request from a client (e.g., a client device) to access (e.g., download from, upload to, delete from, list images stored in, search the contents of, etc.) a repository assigned to a customer of a computing resource service provider”);
presenting at least one search result based on the searching of the Dockerfile metadata, wherein the at least one search result indicates the container image for the application (¶ 21, “The system may also obtain or generate a manifest that contains metadata about the set of container image layers corresponding to the specified container image” and ¶ 26, “a “container image” may refer to metadata and one or more computer files corresponding to contents and/or structure of one or more software applications configured to execute in a software container”); and
providing, in response to a user selection (¶ 75, “The example 700 further depicts a customer 770 who has selected, through the container marketplace 768, the container image 752”), the container image to the at least one third-party compute systems (¶ 75, “directed that one or more copies of the container images 752 be downloaded and launched in one or more container instances 718 belonging to the customer 770”), wherein the container image is configured to be deployed as a container on the at least one third-party compute system to operate the application (¶ 26, “a “container image” may refer to metadata and one or more computer files corresponding to contents and/or structure of one or more software applications configured to execute in a software container”), and wherein the at least one third-party compute system is at least one of a plurality of third-party compute systems (¶ 28, “The primary responsibility of the container registry front-end service 114 may be to provide external application programming interfaces for customers of the computing resource service provider to be able to manage images stored in their container registry (e.g., the container registry 102)”).
Suarez does expressly teach; however, Breternitz discloses: a plurality of third-party compute systems (col. 10:51-54, “one or more third-party data centers (e.g., Amazon Web Services, etc.) and/or user-provided hardware may be configured for cloud computing by control server 12”).
It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of a plurality of third-party compute systems, as taught by Breternitz, in the same way to the customer systems, as taught by Suarez. Both inventions are in the field of cloud computing systems, and combining them would have predictably resulted in a system configured ot “provide for the delivery of computing capacity and storage capacity as a service to end users,” as indicated by Breternitz (col. 1:45-46).
Regarding claim 2, Suarez teaches: The method of claim 1 further comprising presenting at least a portion of the Dockerfile metadata with the at least one search result (¶¶ 28 and 29, Table 1, “the requesting entity DescribeRegistries( ) Returns metadata about a Yes specified registry”).
Regarding claim 3, Suarez teaches: The method of claim 2 further comprising presenting a graphical metadata user interface that enables selection of at least a portion of the Dockerfile metadata to be uploaded during the uploading of the Dockerfile metadata (¶¶ 28 and 29, Table 1, “UpdateRegistry( ) Modifies metadata about a specified registry” and ¶ 44, “Another advantage presented by storing metadata separately in the registry metadata service 222 is that metadata about the data stored in the storage service 290 may be manipulated (e.g., modified, marked for deletion, mark as inaccessible, etc.) in the registry metadata service 222 without locking data in the storage service 290”).
Regarding claim 4, Suarez teaches: The method of claim 3 further comprising updating the Dockerfile metadata based on user input (¶¶ 28 and 29, Table 1, “UpdateRegistry( ) Modifies metadata about a specified registry”).
Regarding claim 5, Suarez teaches: The method of claim 1 further comprising receiving at least one search term from a user via the at least one search interface, wherein the at least one search term is associated with at least a portion of the Dockerfile metadata (¶ 58, “in some embodiments the manifests/metadata is searched using a registry metadata service, such as the registry metadata service 222 of FIG. 2”).
Regarding claim 6, Suarez teaches: The method of claim 5 further comprising receiving a selection of one search result from the at least one search result (¶ 75, “Such container images in a global repository may be available to for purchase (i.e., transacted) through the container marketplace 768, which may be an online marketplace in the form of a website or other user interface from which licenses for one or more container images may be selected and/or purchased by consumers”).
Regarding claim 7, Suarez teaches: The method of claim 1, wherein the Dockerfile metadata includes at least one of a computer architecture type and an indication if replicas are allowed (¶ 70, “the container running in the container instance 618 makes a request, which could be a first type 664A (i.e., corresponding to a first container engine type) of request or a second type 664B (i.e., corresponding to a second container engine type) of request”), and wherein the searching the plurality of container images via the Dockerfile metadata enables searching based on a characteristic of the at least one third-party compute system (¶ 119, “In 1502, the system performing the process 1500 may receive a request from a client (e.g., a client device) to access (e.g., download from, upload to, delete from, list images stored in, search the contents of, etc.) a repository assigned to a customer of a computing resource service provider”).
Regarding claim 8, Breternitz teaches: The method of claim 1, wherein the plurality of third-party compute systems includes at least a plurality of computer clusters (col. 10:48-54, “available nodes 16 from multiple data centers and/or other hardware providers are accessible by control server 12 for selection and configuration as a cluster of nodes 14 for a cloud computing system 10. For example, one or more third-party data centers (e.g., Amazon Web Services, etc.) and/or user-provided hardware may be configured for cloud computing by control server 12”).
Claims 9-11, 13, 15, 16, 19, and 20 recite commensurate subject matter as claims 1-3, 5, 7, and 8. Therefore, they are rejected for the same reasons.
Claim(s) 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Suarez and Breternitz, as applied above, and further in view of Mueller (US 2021/0406246).
Regarding claim 14, Suarez and Breternitz do not teach; however, Mueller discloses: the user Dockerfile metadata includes at least one of a GPU identifier and a CPU identifier to identify container requirements (¶ 41, “a Graphical Processors Unit (GPU) “Runner” could declare that it supports machine learning jobs, requires a specific Docker image, and has a property for the user to indicate how many GPUs to use. In contrast, a Central Processing Unit (CPU) “Runner” could declare that it supports the same machine learning jobs, but it may use a different “Docker” image and not define any user-configurable properties, as it will be appreciated by those skilled in the art.”).
It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of the user Dockerfile metadata includes at least one of a GPU identifier and a CPU identifier to identify container requirements, as taught by Mueller, in the same way to the user provided metadata, as taught by Suarez and Breternitz. Both inventions are in the field of deploying docker images, and combining them would have predictably resulted in “improved maintainability,” as indicated by Mueller (abstract).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
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, Lewis Bullock can be reached at 5712723759. 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 2199