DETAILED ACTION
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 Amendments
Claims 1-20 are amended. Claims 2, 5, 6, 9, 10, 13, 16 and 19 are objected to for having allowable subject matter. Claims 1-20 are pending.
Response to Arguments
Applicant’s arguments, see Remarks, filed on 6/8/2026 have been fully considered.
Claim Rejections under 35 U.S.C. 103
Claims 1, 3-4, 8, 11, 12, 15, 17 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Tarasov et al. (US 2022/0147378), hereinafter Tarasov in view of Suarez et al. (US 2017/0177877), hereinafter Suarez.
Claims 1, 8 and 15 are amended as follows:
“..identify a request for artifact data at a first container registry in the first region, the first container registry having a proxy service that uses a distributed hash table for accessing a mapping between a key that uniquely identifies the artifact data and a region having a copy of the artifact data, wherein the distributed hash table is used to share the mapping between container registries;
determine that the artifact data is locally unavailable;
based on the determination that the artifact data is locally unavailable, identify, using the distributed hash table, a peer container registry in the second region that has a copy of the artifact data and send a request to the peer container registry for the copy of the artifact data” (Emphasis added)
On page 9 of the Remarks, Applicant argues the combined prior art fails to teach the amended features recited in the claims. Applicant’s arguments are persuasive, therefore, a new ground of rejection is made in light of the amendment.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 2-4, 8, 9, 11, 12, 15, 17 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Tarasov et al. (US 2022/0147378), hereinafter Tarasov in view of Suarez et al. (US 2017/0177877), hereinafter Suarez further in view of Bhutani et al. (US 2021/0342294), hereinafter Bhutani.
As for claim 1, Tarasov teaches a system for proxying requests for artifact data from a first location of a cloud service to a second location of the cloud service (Fig. 1, Computer System 12; paragraphs [0027] describe a system performed by processor and logic integrated with the processor and executed by the processor to receive a request to create a container; retrieve a manifest for a container image of the container; and mount a file system for the container, utilizing the manifest; paragraphs [0048]-[0049] describe a cloud computing environment), the system comprising:
a processor for executing instructions (paragraph [0029] describes a processor that executes program instructions); and
a computer storage medium for storing the instructions (paragraph [0029] describes a computer readable storage medium storing program instructions), the instructions causing the processor to (paragraph [0029] describes the processor executing the program instructions to perform a method):
identify a request for artifact data (paragraph [0076] describes a request to access data within a container image (construed as artifact data – see also paragraph [0067]) of a container is identified by a file system mounted for a container; paragraph [0092] further describes a request for a specific file within a software package);
determine that the artifact data is locally unavailable (paragraph [0080] describes a determining that the manifest for the image indicates that the data is not stored locally at the cache);
based on the determination that the artifact data is locally unavailable, identify a peer content store in the second location that has a copy of the artifact data and send a request to the peer content store for the copy of the artifact data (paragraphs [0079]-[0080] describe in response to determining that the manifest for the image indicates that the data is not stored locally at the cache, the data may be retrieved from a content store which is physically separate from the node of the cluster, and is accessed via a communications network);
receive the artifact data from the peer content store (paragraph [0080] describes the data in association with the container image is retrieved from the content store).
Tarasov fails to teach
wherein a request is at a container registry in a first region;
wherein a container image is artifact;
a content store is a peer container registry;
a first container registry having a proxy service that uses a distributed hash table for accessing a mapping between a key that uniquely identifies artifact data and a region having a copy of the artifact data, wherein the distributed hash table is used to share the mapping between container registries;
wherein a peer container registry is identified using the distributed hash table;
store artifact data to a local datastore.
Suarez discloses
wherein a request is at a container registry in a first region (paragraph [0035] describes a request to retrieve a container image and a container registry front-end service queries a registry metadata service to obtain a list of storage locations for the container image; paragraph [0092] describes storage locations i.e. container registries that are located on servers in different geographic regions);
wherein a container image is artifact (paragraph [0097] describes a customer uploads a set of build artifacts. A managed source control service forwards the set of build artifacts to the automated build service builds a container image in accordance with the build file and the container engine type that the set of build artifacts have been configured for or specified);
a content store is a peer container registry (paragraph [0092] describes container registries can be physically located in servers in different geographic regions. The servers are storages that function as container registries);
store artifact data to a local datastore (paragraph [0093] describes the content delivery network hosts software images on the servers throughout the various geographic regions by copying the content from a server in one geographic region to a server in another geographic region. Customers of the computing resource service provider are able to obtain content from the servers most geographically proximate to the customer which is construed as storing the software images at local servers).
One of ordinary skill in the art before the effective filing date of the claimed invention would have recognized the ability to utilize the teachings of Suarez for copying container image to different servers in multiple geographic regions. The teachings of Suarez, when implemented in the Tarasov system, will allow one of ordinary skill in the art to quickly obtain container images. One of ordinary skill in the art would be motivated to utilize the teachings of Suarez in the Tasarov system in order to provide a container image that customer can download the container image from a server in that locates in a geographic regions of the customer which is more quickly than downloading the container image from a server located in a remote geographic region.
The combined system of Tarasov and Suarez fails to teach
a first container registry having a proxy service that uses a distributed hash table for accessing a mapping between a key that uniquely identifies artifact data and a region having a copy of the artifact data, wherein the distributed hash table is used to share the mapping between container registries;
wherein a peer container registry is identified using the distributed hash table.
Bhutani discloses
a first container registry having a proxy service that uses a distributed hash table for accessing a mapping between a key that uniquely identifies artifact data and a region having a copy of the artifact data (paragraphs [0042]-[0043] describe a log-structured deduplication file system divides ingested stream of data into segments. The segment of data is hashed using a cryptographic hash, the output of the hashing algorithm is the fingerprint which uniquely describes that segment of data in the storage system. An index of all the fingerprints is maintained in the system and are fetched before any new data is written down. New segments are packed into a container along with fingerprints and appended as a log; paragraphs [0045]-[0047] and [0065] describe data containers include metadata section which stores fingerprints. Each container includes a metadata section that describes the fingerprints and their location in the container, then regions of data. Each data container may be associated with a corresponding metadata container. The metadata container may include references, pointers, fingerprints, identifiers, or other information that can be used to locate a corresponding data container residing at a cloud storage service and data segments within the data container. A metadata container includes metadata for multiple data containers; paragraphs [0077]-[0078] and [0080]-[0081] describe the metadata containers are further mirrored or replicated to the first cloud storage service. The metadata containers include references to the data containers and are identified by container IDs. A fingerprint index is maintained to map fingerprints of the segment to container IDs; paragraph [0091] describes a request is received to read a file, the fingerprint index is consulted or examined to identify a container ID associated with a data container storing one or more segments of the file. The container ID is compared to a checkpoint, based on the comparison, the data container having the relevant segment is accessed from the cloud storage device), wherein the distributed hash table is used to share the mapping between container registries (paragraphs [0042]-[0043] describe an index of all the fingerprints is maintained in the system and are fetched before any new data is written down. The index is referred to as a fingerprint index);
wherein a peer container registry is identified using the distributed hash table (paragraph [0045] describes a data container includes a metadata section, the metadata section stores fingerprints. The data section stores segments corresponding to the fingerprints stored in the metadata section; paragraph [0084] describes new metadata containers associated with the new data containers are generated. The new metadata containers include references to the new data containers. The new metadata containers are stored locally and written to the log; paragraph [0091] describes the fingerprint index is updated to map fingerprints of the live and now migrated segments to the new container IDs. A request is received to read a file. The fingerprint index is consulted or examined to identify a container ID associated with a data containers storing one or more segments of the file. The container ID is compared to the checkpoint, based on the comparison, the data container having the relevant segments is accessed from the first cloud storage service or second cloud storage service).
One of ordinary skill in the art before the effective filing date of the claimed invention would have recognized the ability to utilize the teachings of Bhutani for generating and storing an index associates fingerprints of file segments to container numbers of containers. The teachings of Bhutani, when implemented in the Tarasov and Suarez system, will allow one of ordinary skill in the art to access data that is located at or moved to a destination. One of ordinary skill in the art would be motivated to utilize the teachings of Bhutani in the Tarasov and Suarez system in order to allow for efficiently tracking the location of data residing in the cloud.
As for claim 2, the combined system of Tarasov, Suarez and Bhutani teaches wherein the first container registry and the peer container registry has a proxy service that shares the distributed hash table with the first container registry (Bhutani: paragraph [0043] describes new segments are packed into a container along with fingerprints and appended as a log (i.e. peer container registry); Fig. 4; paragraph [0065] describes a storage server that stores a fingerprint index that shows fingerprints and a container log which contains multiple containers).
One of ordinary skill in the art before the effective filing date of the claimed invention would have recognized the ability to utilize the teachings of Bhutani for generating and storing an index associates fingerprints of file segments to container numbers of containers. The teachings of Bhutani, when implemented in the Tarasov and Suarez system, will allow one of ordinary skill in the art to access data that is located at or moved to a destination. One of ordinary skill in the art would be motivated to utilize the teachings of Bhutani in the Tarasov and Suarez system in order to allow for efficiently tracking the location of data residing in the cloud.
As for claim 3, the combined system of Tarasov, Suarez and Bhutani teaches wherein the first region is a first partition of cloud resources located in a first geographic region and the second region is a second partition of cloud resources located in a second geographic region that is distinct from the first geographic region (Tasarov: paragraphs [0079]-[0080] describes a cache (i.e. local) and a remote datastore; Suarez: paragraph [0092] describes multiple geographic regions that store container images; Bhutani: paragraphs [0041]-[0044] describe a deduplication engine is responsible for deduplicating data entering the deduplication file system. The file system is a log-structured deduplication file system. The log-structured deduplication file system divides the ingested stream of data into segments. Each cloud tier stores the user data in the cloud storage and maintains the metadata on the local storage that describes the data stored in the cloud provider; paragraph [0065] describes a tiered storage system. There is a storage server, a source cloud and a destination cloud).
One of ordinary skill in the art before the effective filing date of the claimed invention would have recognized the ability to utilize the teachings of Bhutani for generating and storing an index associates fingerprints of file segments to container numbers of containers. The teachings of Bhutani, when implemented in the Tarasov and Suarez system, will allow one of ordinary skill in the art to access data that is located at or moved to a destination. One of ordinary skill in the art would be motivated to utilize the teachings of Bhutani in the Tarasov and Suarez system in order to allow for efficiently tracking the location of data residing in the cloud.
.
As for claim 4, the combined system of Tasarov, Suarez and Bhutani teaches wherein the request is received from a client in the first region via an application programming interface (API) provided by the first container registry (Suarez: paragraphs [0023] and [0028] describe a system comprises a front-end service that provides a plurality of application interfaces for performing operations with the container registry; paragraph [0042] describes the container registry proxy functions at a proxy for communications between a container engine and APIs of the container front-end service. The container registry front-end service is a set of APIs and endpoints that are made accessible to customers of the computing resource service provider. The customers may call the APIs and endpoints through the container proxy; Tasarov: paragraph [0076] describes a request to access data within a container image); and
in response to the receiving of the artifact data, forwarding the artifact data to the client (Suarez: paragraph [0040] describes a container registry proxy is responsible for communicating with the container registry front-end service to store container images in the repositories of a storage service and serves container images from the storage service to container instances of customers; paragraph [0130] and [0133] describe a server for receiving requests and serving content in response to the requests, each server includes storage medium storing instructions that, as a result of execution by a processor of the server, allow the server to perform its intended functions).
One of ordinary skill in the art before the effective filing date of the claimed invention would have recognized the ability to utilize the teachings of Suarez for implementing a container registry API. The teachings of Suarez, when implemented in the Tarasov and Bhutani system, will allow one of ordinary skill in the art to enable customers to upload or retrieve container images from a container registry. One of ordinary skill in the art would be motivated to utilize the teachings of Suarez in the Tasarov and Bhutani system in order to offer a service that provides a plurality of APIs for performing with a container registry.
As for claim 8, Tasarov teaches a computerized method comprising:
receiving a request for artifact data (paragraph [0076] describes a request to access data within a container image (construed as artifact data – see also paragraph [0067]) of a container is identified by a file system mounted for a container; paragraph [0092] further describes a request for a specific file within a software package);
determining that the artifact data is locally unavailable (paragraph [0080] describes a determining that the manifest for the image indicates that the data is not stored locally at the cache); and
identifying a peer content store in a second region that has a copy of the artifact data and sending a request to the peer content store for the copy of the artifact data (paragraphs [0079]-[0080] describe in response to determining that the manifest for the image indicates that the data is not stored locally at the cache, the data may be retrieved from a content store which is physically separate from the node of the cluster, and is accessed via a communications network);
receiving the artifact data from the peer content store (paragraph [0080] describes the data in association with the container image is retrieved from the content store).
Tasarov fails to teach
wherein a request is at a first container registry in a first region of a cloud service from a client at the first region;
wherein a container image is artifact;
wherein a content store is a container registry;
wherein a first container registry having a proxy service that uses a distributed hash table for accessing a mapping between a key that uniquely identifies artifact data and a region having a copy of the artifact data, wherein the distributed hash table is used to share the mapping between container registries;
wherein a peer container registry is identified using the distributed hash table;
forwarding the artifact data to the client.
Suarez discloses
wherein a request is at a first container registry in a first region of a cloud service from a client at the first region (paragraph [0035] describes a request to retrieve a container image; paragraph [0042] describes the container registry proxy functions at a proxy for communications between a container engine and APIs of the container front-end service. The container registry front-end service is a set of APIs and endpoints that are made accessible to customers of the computing resource service provider. The customers may call the APIs and endpoints through the container proxy; paragraph; paragraph [0092] describes container registries can be located in different geographic regions; paragraph [0105] describes the region refers to a location of the repository, which maybe a location within a data center, or a virtual location);
wherein a container image is artifact (paragraph [0097] describes a customer uploads a set of build artifacts. A managed source control service forwards the set of build artifacts to the automated build service builds a container image in accordance with the build file and the container engine type that the set of build artifacts have been configured for or specified);
wherein a content store is a container registry (paragraph [0092] describes container registries can be physically located in servers in different geographic regions. The servers are storages that function as container registries);
forwarding the artifact data to the client (paragraph [0040] describes a container registry proxy is responsible for communicating with the container registry front-end service to store container images in the repositories of a storage service and serves container images from the storage service to container instances of customers).
One of ordinary skill in the art before the effective filing date of the claimed invention would have recognized the ability to utilize the teachings of Suarez for copying container image to different servers in multiple geographic regions. The teachings of Suarez, when implemented in the Tarasov system, will allow one of ordinary skill in the art to quickly obtain container images. One of ordinary skill in the art would be motivated to utilize the teachings of Suarez in the Tasarov system in order to provide a container image that customer can download the container image from a server in that locates in a geographic regions of the customer which is more quickly than downloading the container image from a server located in a remote geographic region.
The combined system of Tarasov and Suarez fails to teach
a first container registry having a proxy service that uses a distributed hash table for accessing a mapping between a key that uniquely identifies artifact data and a region having a copy of the artifact data, wherein the distributed hash table is used to share the mapping between container registries;
wherein a peer container registry is identified using the distributed hash table.
Bhutani discloses
a first container registry having a proxy service that uses a distributed hash table for accessing a mapping between a key that uniquely identifies artifact data and a region having a copy of the artifact data (paragraphs [0042]-[0043] describe a log-structured deduplication file system divides ingested stream of data into segments. The segment of data is hashed using a cryptographic hash, the output of the hashing algorithm is the fingerprint which uniquely describes that segment of data in the storage system. An index of all the fingerprints is maintained in the system and are fetched before any new data is written down. New segments are packed into a container along with fingerprints and appended as a log; paragraphs [0045]-[0047] and [0065] describe metadata containers, the metadata section stores fingerprints. Each container includes a metadata section that describes the fingerprints and their location in the container, then regions of data. Each data container may be associated with a corresponding metadata container. The metadata container may include references, pointers, fingerprints, identifiers, or other information that can be used to locate a corresponding data container residing at a cloud storage service and data segments within the data container. In a specific embodiment, a metadata container includes metadata for multiple data containers; paragraphs [0077]-[0078] and [0080]-[0081] describe the metadata containers are further mirrored or replicated to the first cloud storage service. The metadata containers include references to the data containers and are identified by container IDs. A fingerprint index is maintained to map fingerprints of the segment to container IDs; paragraph [0091] describes a request is received to read a file, the fingerprint index is consulted or examined to identify a container ID associated with a data container storing one or more segments of the file. The container ID is compared to the checkpoint, based on the comparison, the data container having the relevant segment is accessed from the cloud storage device), wherein the distributed hash table is used to share the mapping between container registries (paragraphs [0042]-[0043] describe an index of all the fingerprints is maintained in the system and are fetched before any new data is written down. The index is referred to as a fingerprint index);
wherein a peer container registry is identified using the distributed hash table (paragraph [0045] describes a data container includes a metadata section, the metadata section stores fingerprints. The data section stores segments corresponding to the fingerprints stored in the metadata section; paragraph [0084] describes new metadata containers associated with the new data containers are generated. The new metadata containers include references to the new data containers. The new metadata containers are stored locally and written to the log; paragraph [0091] describes the fingerprint index is updated to map fingerprints of the live and now migrated segments to the new container IDs. A request is received to read a file. The fingerprint index is consulted or examined to identify a container ID associated with a data containers storing one or more segments of the file. The container ID is compared to the checkpoint, based on the comparison, the data container having the relevant segments is accessed from the first cloud storage service or second cloud storage service).
One of ordinary skill in the art before the effective filing date of the claimed invention would have recognized the ability to utilize the teachings of Bhutani for generating and storing an index associates fingerprints of file segments to container numbers of containers. The teachings of Bhutani, when implemented in the Tarasov and Suarez system, will allow one of ordinary skill in the art to access data that is located at or moved to a destination. One of ordinary skill in the art would be motivated to utilize the teachings of Bhutani in the Tarasov and Suarez system in order to allow for efficiently tracking the location of data residing in the cloud.
As for claim 9, the combined system of Tarasov, Suarez and Bhutani teaches wherein the distributed hash table is implemented by both the first container registry and the peer container registry (Bhutani: paragraph [0043] describes new segments are packed into a container along with fingerprints and appended as a log (i.e. peer container registry); Fig. 4; paragraph [0065] describes a storage server that stores a fingerprint index that shows fingerprints and a container log which contains multiple containers).
One of ordinary skill in the art before the effective filing date of the claimed invention would have recognized the ability to utilize the teachings of Bhutani for generating and storing an index associates fingerprints of file segments to container numbers of containers. The teachings of Bhutani, when implemented in the Tarasov and Suarez system, will allow one of ordinary skill in the art to access data that is located at or moved to a destination. One of ordinary skill in the art would be motivated to utilize the teachings of Bhutani in the Tarasov and Suarez system in order to allow for efficiently tracking the location of data residing in the cloud.
As for claim 11, the combined system of Tasarov, Suarez and Bhutani teaches wherein the first region is a first partition of cloud resources in a first geographic region and the second region is a second partition of cloud resources located in a geographic region that is distinct from the first geographic region (Tasarov: paragraphs [0079]-[0080] describes a cache (i.e. local) and a remote datastore; Suarez: paragraph [0092] describes multiple geographic regions that store container images; Bhutani: paragraphs [0041]-[0044] describe a deduplication engine is responsible for deduplicating data entering the deduplication file system. The file system is a log-structured deduplication file system. The log-structured deduplication file system divides the ingested stream of data into segments. Each cloud tier stores the user data in the cloud storage and maintains the metadata on the local storage that describes the data stored in the cloud provider; paragraph [0065] describes a tiered storage system. There is a storage server, a source cloud and a destination cloud).
One of ordinary skill in the art before the effective filing date of the claimed invention would have recognized the ability to utilize the teachings of Bhutani for generating and storing an index associates fingerprints of file segments to container numbers of containers. The teachings of Bhutani, when implemented in the Tarasov and Suarez system, will allow one of ordinary skill in the art to access data that is located at or moved to a destination. One of ordinary skill in the art would be motivated to utilize the teachings of Bhutani in the Tarasov and Suarez system in order to allow for efficiently tracking the location of data residing in the cloud.
As for claim 12, the combined system of Tasarov, Suarez and Bhutani teaches wherein the request is received from the client in the first region via an application programming interface (API) provided by the first container registry; and
in response to the receiving of the artifact data, the artifact data is forwarded to the client via the API (Suarez: paragraphs [0023] and [0028] describe a system comprises a front-end service that provides a plurality of application interfaces for performing operations with the container registry; paragraph [0042] describes the container registry proxy functions at a proxy for communications between a container engine and APIs of the container front-end service. The container registry front-end service is a set of APIs and endpoints that are made accessible to customers of the computing resource service provider. The customers may call the APIs and endpoints through the container proxy; Tasarov: paragraph [0076] describes a request to access data within a container image), and, in response to the receiving of the artifact data, forwarding the artifact data to the client (Suarez: paragraph [0040] describes a container registry proxy is responsible for communicating with the container registry front-end service to store container images in the repositories of a storage service and serves container images from the storage service to container instances of customers).
One of ordinary skill in the art before the effective filing date of the claimed invention would have recognized the ability to utilize the teachings of Suarez for implementing a container registry API. The teachings of Suarez, when implemented in the Tarasov and Bhutani system, will allow one of ordinary skill in the art to enable customers to upload or retrieve container images from a container registry. One of ordinary skill in the art would be motivated to utilize the teachings of Suarez in the Tasarov and Bhutani system in order to offer a service that provides a plurality of APIs for performing with a container registry.
As for claims 15, 17 and 18, these claims listed all the same elements of claims 8, 11 and 12, respectively, but in a computer storage medium (Tasarov: paragraph [0029] describes the processor executing the program instructions to perform a method), the instructions causing the processor to perform operations (Tasarov: paragraph [0029] describes the processor executing the programs instructions to perform a method). Therefore, the supporting rational of the rejection to claims 8, 11 and 12 applies equally as well to claims 15, 17 and 18, respectively.
Claims 7, 14 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Tarasov (US 2022/0147378) in view of Suarez (US 2017/0177877) and Bhutani (US 2021/0342294) further in view of Sharma et al. (US 2022/0131852), hereinafter Sharma.
As for claim 7, the combined system of Tasarov, Suarez and Bhutani fails to teach wherein the artifact data is a package of data conformant to Open Container Initiative (OCI) standards for container artifacts and the first container registry supports OCI application programming interface (API) specifications.
Sharma discloses
wherein the artifact data is a package of data conformant to Open Container Initiative (OCI) standards for container artifacts and the first container registry supports OCI application programming interface (API) specifications (paragraph [0044] describes web applications and microservices (e.g. REST APIs) are packaged in the form of containers to produce an Open Container Initiative (OCI) format image (e.g., a Docker container image)).
One of ordinary skill in the art before the effective filing date of the claimed invention would have recognized the ability to utilize the teachings of Sharma packaging a container image that conforms with an OCI format. The teachings of Sharma, when implemented in the Tarasov, Suarez and Bhutani system, will allow one of ordinary skill in the art to execute a container-based application. One of ordinary skill in the art would be motivated to utilize the teachings of in the Sharma in the Tarasov, Suarez and Bhutani system in order to include information that is able to provide tracking a distribution process, such as by updating associated metadata during the distribution process.
As for claim 14, the combined system of Tasarov, Suarez and Bhutani fails to teach wherein the artifact data is a package of data conformant to Open Container Initiative (OCI) standards for container artifacts and the first container registry supports OCI application programing interface (API) specifications.
Sharma discloses
wherein the artifact data is a package of data conformant to Open Container Initiative (OCI) standards for container artifacts and the first container registry supports OCI application programming interface (API) specifications (paragraph [0044] describes web applications and microservices (e.g. REST APIs) are packaged in the form of containers to produce an Open Container Initiative (OCI) format image (e.g., a Docker container image)).
One of ordinary skill in the art before the effective filing date of the claimed invention would have recognized the ability to utilize the teachings of Sharma packaging a container image that conforms with an OCI format. The teachings of Sharma, when implemented in the Tarasov, Suarez and Bhutani system, will allow one of ordinary skill in the art to execute a container-based application. One of ordinary skill in the art would be motivated to utilize the teachings of in the Sharma in the Tarasov, Suarez and Bhutani system in order to include information that is able to provide tracking a distribution process, such as by updating associated metadata during the distribution process.
As for claim 20, the claim lists all the same elements of claim 7, but in a computer storage medium encoding instructions for execution by a processor (Tasarov: paragraph [0029] describes the processor executing the program instructions to perform a method), causes the processor to perform functions to carry out the steps of rather than system form. Therefore, the supporting rationale of the rejection to claim 7 applies equally as well to claim 20.
Allowable Subject Matter
Claims 5, 6, 10, 13, 16 and 19 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
As for claim 5, the claim recites the limitations “5. The system of claim 1 wherein the instructions further cause the processor to generate the request based on a prediction from a machine learning (ML) model, the prediction being based on patterns of events in log data.”
As for claim 6, the claim recites the limitations “6. The system of claim 1 wherein the instructions further cause the processor to:
identify an initial peer container registry in in a third region as a potential source for the copy of the artifact data;
send an initial request to the initial peer container registry for the copy of the artifact data; and
receive a response from the initial peer container registry indicating it is not able to send the copy of the artifact data, the response from the initial peer container registry further identifying the peer container registry as having the artifact data, the identification of the peer container registry in the second region as having the copy of the artifact data being based on the response from the initial peer container registry.”
As for claim 10, the claim recites the limitations “The method of claim 9, wherein the identifying of the peer container registry comprises:
determining that the first container registry does not have the mapping;
determining, based on a value of the key and an identifier of a second peer container registry, that the second peer container registry is likely to have the mapping;
sending a message including the key to the second peer container registry; and
receiving the mapping in a response to the message, the response being from the second peer container registry, the mapping identifying the peer container registry.”
The combined system of Tasarov, Suarez and Bhutani teaches a request for a container image and the manifest for the image indicates that the data is not stored locally at a cache (Tasarov: paragraphs [0076] and [0082]). The combined system of Tasarov and Suarez fails to teach the above cited limitations.
Claim 13 is method claim of system claim 6, therefore, claim 13 includes allowable subject matter
Claim 19 are computer product claims of system claim 5, therefore, claim 19 includes allowable subject matter.
Conclusions
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Piccinini et al. (US 2019/0250835) teach sharing of data among containers running on virtualized operating systems
Frandzel et al. (US 8,315,984) teach system and method for on-the-fly elimination of redundant data
Featonby et al. (US 11,573,816 B1) teach prefetching and managing container images using cluster manifest
Khobragade et al. (US 2025/0061090) teach cloud capacity scaling with high readable capacity in metadata space constrained deduplication systems.
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 L. T N. whose telephone number is (571)272-1013. The examiner can normally be reached M & Th 5:30 am - 2:30 pm EST.
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, TONIA DOLLINGER can be reached at 571-272-4170. 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.
/L. T. N/
Examiner, Art Unit 2459
/TONIA L DOLLINGER/Supervisory Patent Examiner, Art Unit 2459
Prosecution Insights