DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . This office action is in response to Applicant’s response filed 12/15/2025.
The instant application having application No. 18/341,574 filed on June 6, 2023, presents claims 1-20 for examination. The instant application is a continuation of the application having application No. 17/153,534 (now issued patent 11,720,345) filed on January 20, 2021.
Terminal Disclaimer
The terminal disclaimer filed on 5/16/2025 disclaiming the terminal portion of any patent granted on this application which would extend beyond the expiration date of prior patent number 11,720,345 has been reviewed and is accepted. The terminal disclaimer has been recorded.
Status of the Claims
Claims 1, 5, and 15 are amended, claims 1-20 are currently pending in the application.
Response to Amendment
(A). Regarding claim objections: Applicant’s amendments to claims appropriately addressed the objection to claim 5, the objection is withdrawn.
(B). Regarding 35 U.S.C. § 101 rejection: The 101 abstract idea rejections to Claims 8-14 are withdrawn in view of amendments to claims.
(C). Regarding art rejection: In regards to pending claims, Applicant's amendments necessitated further search, and new grounds of rejections are presented in the following art rejection.
Examiner Notes
Examiner cites particular columns, paragraphs, figures and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
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 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.
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 of this title, 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 and 5 are rejected under 35 U.S.C. 103 as being unpatentable over Parees et al. (US 20170249141 A1, hereinafter “Parees”, cited from IDS filed 6/26/2023) in view of Mueller et al. (US 20110239190 A1, hereinafter “Mueller”) and Vaddi et al. (US 20200409680 A1, hereinafter “Vaddi”).
With respect to claim 1 (Currently amended), Parees discloses A method comprising:
determining, by a processing device executing an instance of a service within a container of a computing environment and by a daemon of the container, whether a code update for the service is available [at a central repository of the computing environment] (e.g. Fig. 4. Para [0073], “… an instance of an application image in a container is executed. …”. para [0075], “… the modification to the source code is identified via the application framework utilized in the instance. …” wherein the application framework reads on a daemon of the container);
performing, by the daemon of the container and via a hot reload, a modification of the instance of the servicey overlaying the code update over a base image corresponding to the service] (e.g. Fig. 4, step 440, para [0076], “… the identified modification to the source code is applied, via the application framework, to the source code during runtime of the instance in the container.” This paragraph suggests that there is a background process in the application framework that applies the identified modification to the source code during runtime of the instance in the container, therefore, applying modification to the source code via the application framework during runtime of the instance in the container suggests the daemon of the container in the application framework).
Parees does not appear to explicitly disclose
…, (whether a code update for the service is available) at a central repository of the computing environment;
in response to determining that the code update for the service is available, retrieving, by the daemon of the container and by a pull request, the code update for the service from the central repository; and
(performing, by the daemon of the container and via a hot reload, a modification of the instance of the service)y overlaying the code update over a base image corresponding to the service.
However, in analogous art, Mueller discloses
(performing, by the daemon of the container and via a hot reload, a modification of the instance of the service) by overlaying the code update over a base image corresponding to the service (e.g. para [0045], “FIG. 2 illustrates an example of overlay according to one embodiment. In this example, object 130 of the application 100 is overlaid by overlaid object 200. Both users 110 and 120 may use application 100 with overlaid object 200 overlaying or replacing original application object 130 when executing application 100. Application 100 may be modified by the vendor without affecting overlaid object 200, and users 110 and 120 may continue to use customized
application 100 with overlaid object 200 even after an update by the vendor to application 100 modifies the application object 130.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Parees and the invention of Mueller because it provides techniques for configuring the software application to execute in a computer system using the first overlaid object instead of the first base object, so that the customer can apply an update to get the fixes and additional functionality of the new version from the supplier but still preserve the customer's customizations. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of providing techniques for configuring the software application to execute in a computer system using the first overlaid object instead of the first base object, so that the customer can apply an update to get the fixes and additional functionality of the new version from the supplier but still preserve the customer's customizations as suggested by Mueller (see para [0004-0008]).
Parees as modified by Mueller does not appear to explicitly disclose
…, (whether a code update for the service is available) at a central repository of the computing environment;
in response to determining that the code update for the service is available, retrieving, by the daemon of the container and by a pull request, the code update for the service from the central repository;
However, this is taught in analogous art, Vaddi (e.g. para [0052], “At block 406, the repository node is requested for the updated version of the application code. At block 408, the updated version of the application code is received in response to the request. …” wherein the repository node reads on a central repository of the computing device. Para [0054], “In an example, the steps at blocks 402-410 may be performed in response to execution of a set of instructions in a container image from which the container is instantiated. The container image may be, for example, the container image 108. The set of instructions may be, for example, the first set of instructions 106.” Wherein execution of a set of instructions 106 suggests the daemon of the container.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the invention of Vaddi because it provides techniques for testing changes to application code corresponding to container-based application with minimal expenditure of time and network resources. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of providing techniques for testing changes to application code corresponding to container-based application with minimal expenditure of time and network resources as suggested by Vaddi (see para [0012]).
With respect to claim 5 (Currently amended), Parees discloses wherein is associated with a local file system of the container of the instance of the service (e.g. Fig. 4, step 440, para [0076], “… the identified modification to the source code is applied, via the application framework, to the source code during runtime of the instance in the container.”).
Claims 2-4, 6, 15, 16, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Parees in view of Mueller and Vaddi and Kalaskar et al. (US 20200334027 A1, hereinafter “Kalaskar”).
With respect to claim 2 (Original), Parees as modified by Mueller and Vaddi discloses The method of claim 1, but does not appear to explicitly disclose wherein determining whether the code update for the service is available is in response to determining that the instance of the service has been accessed. However, this is taught in analogous art, Kalaskar (e.g. para [0007], “… Accordingly, performing automated upgrades of services based on a predetermined sequence that factors the interdependencies between the services can reduce complications with service upgrades.” Para [0008], “… Patches and upgrades can become available for the different types of software services used to create the systems of the virtualized computing environment. One implementation of the virtualized computing environment can include a life cycle manager that can manage the deployment, upgrades, and configuration of the different software-based systems and services.” where considering the interdependencies between the services and creating the systems clearly show determining that the instance of the service has been accessed as claimed.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the invention of Kalaskar because it provides techniques for automating service upgrades within the computing infrastructure of a software-defined data center (SDDC) while considering the interdependencies between the services. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of providing techniques for automating service upgrades within the computing infrastructure of a software-defined data center (SDDC) while considering the interdependencies between the services as suggested by Kalaskar (see para [0007]).
With respect to claim 3 (Original), Parees as modified by Mueller and Vaddi discloses The method of claim 1, but does not appear to explicitly disclose wherein the computing environment comprises a cluster of host computing devices executing a high performance computing workload. However, this is taught in analogous art, Kalaskar (e.g. para [0015], “… the computing services 114 can include those that provide a public cloud computing environment, a private cloud computing environment, or a hybrid cloud computing environment (a combination of a public and private cloud computing environment). …” where combination of public and private cloud computing environment is a cluster of host computing system, e.g. para [0019], “… In some examples, the hypervisor can be installed on a host 118 to support a virtual machine execution space within which one or more virtual machines can be concurrently instantiated and executed. … without degrading performance of a virtualization or cloud computing environment.” This paragraph discloses that host computing devices executing a high performance workload. For motivation to combine, please refer to office action regarding claim 2 above).
With respect to claim 4 (Previously presented), Parees as modified by Mueller and Vaddi discloses Kalaskar discloses The method of claim 1, but does not appear to explicitly disclose wherein the service executes in an isolated execution environment. However, this is taught in analogous art, Kalaskar (e.g. para [0020], “… in some examples, the computing services 114 can be implemented in computing containers. Each of the containers can include a self-contained execution environment having its own CPU, memory, block input/output (I/O), and network resources which are isolated from other containers. …” For motivation to combine, please refer to office action regarding claim 2 above).
With respect to claim 6 (Previously presented), Parees as modified by Mueller and Vaddi discloses Kalaskar discloses The method of claim 1, but does not appear to explicitly disclose wherein determining whether a code update for the service is available comprises determining whether metadata of the central repository indicates that the code update is stored at the central repository. However, this is taught in analogous art, Kalaskar (e.g. para [0024], “The data store 121 can include an upgrade bundle 124 and an upgrade status log 127. The upgrade bundle 124 includes a bundle of upgrades and patches for software services associated with a software-based system of the data center. The upgrade bundle 124 can include version data 130, a manifest 133, and upgrade executables 136. …” wherein an upgrade status log, a manifest reads on the metadata of the central repository as claimed. For motivation to combine, please refer to office action regarding claim 2 above).
With respect to claim 15 (Currently amended), Parees discloses A non-transitory computer-readable storage medium including instructions that, when executed by a processing device, cause the processing device to (e.g. Fig. 7):
determine, by the processing device, that a code update for a service of a computing environment is available at [a centralized repository] (e.g. Fig. 4. Para [0073], “… an instance of an application image in a container is executed. …”. para [0075], “… the modification to the source code is identified via the application framework utilized in the instance. …”);
update, by the processing device and via a hot reload, each of [the plurality of instances of the service] in view of the code update for the service [retrieved from the centralized repository by overlaying the code update over a base image corresponding to the service] (e.g. Fig. 4, step 440).
Parees does not appear to explicitly disclose
…, (that a code update for a service of a computing environment is available) at a centralized repository;
retrieve, by a daemon of a container of each of a plurality of instances of the service and by a pull request, the code update for the service from the centralized repository;
(update, by the processing device and via a hot reload, each of) the plurality of instances of the service (in view of the code update for the service) retrieved from the centralized repository by overlaying the code update over a base image corresponding to the service.
However, in analogous art, Mueller discloses
(update, by the processing device and via a hot reload, each of) [the plurality of instances of the service] (in view of the code update for the service) [retrieved from the centralized repository] by overlaying the code update over a base image corresponding to the service (e.g. para [0045], “FIG. 2 illustrates an example of overlay according to one embodiment. In this example, object 130 of the application 100 is overlaid by overlaid object 200. Both users 110 and 120 may use application 100 with overlaid object 200 overlaying or replacing original application object 130 when executing application 100. Application 100 may be modified by the vendor without affecting overlaid object 200, and users 110 and 120 may continue to use customized
application 100 with overlaid object 200 even after an update by the vendor to application 100 modifies the application object 130.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Parees and the invention of Mueller because it provides techniques for configuring the software application to execute in a computer system using the first overlaid object instead of the first base object, so that the customer can apply an update to get the fixes and additional functionality of the new version from the supplier but still preserve the customer's customizations. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of providing techniques for configuring the software application to execute in a computer system using the first overlaid object instead of the first base object, so that the customer can apply an update to get the fixes and additional functionality of the new version from the supplier but still preserve the customer's customizations as suggested by Mueller (see para [0004-0008]).
Parees as modified by Mueller does not appear to explicitly disclose
…, (that a code update for a service of a computing environment is available) at a centralized repository;
retrieve, by a daemon of a container of each of a plurality of instances of the service and by a pull request, the code update for the service from the centralized repository;
(update, by the processing device and via a hot reload, each of) the plurality of instances of the service (in view of the code update for the service) retrieved from the centralized repository (by overlaying the code update over a base image corresponding to the service).
However, in analogous art, Vaddi discloses
…, (that a code update for a service of a computing environment is available) at a centralized repository (e.g. Fig. 5, Repository Node 512);
retrieve, by a daemon of a container of each of a plurality of instances of the service and by a pull request, the code update for the service from the centralized repository (e.g. para [0052], “At block 406, the repository node is requested for the updated version of the application code. At block 408, the updated version of the application code is received in response to the request. …” wherein the repository node reads on a central repository of the computing device. Para [0054], “In an example, the steps at blocks 402-410 may be performed in response to execution of a set of instructions in a container image from which the container is instantiated. The container image may be, for example, the container image 108. The set of instructions may be, for example, the first set of instructions 106.” Wherein the set of instructions 106 reads on the daemon of the container.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Parees and the invention of Vaddi because it provides techniques for testing changes to application code corresponding to container-based application with minimal expenditure of time and network resources. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of providing techniques for testing changes to application code corresponding to container-based application with minimal expenditure of time and network resources as suggested by Vaddi (see para [0012]).
Parees as modified by Mueller and Vaddi does not appear to explicitly disclose
(update, by the processing device and via a hot reload), each of the plurality of instances of the service in view of the code update for the service retrieved from the centralized repository (…).
However, this is taught in analogous art, Kalaskar discloses (e.g. Fig. 3, steps 315-324 loop).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the invention of Kalaskar because it provides techniques for automating service upgrades within the computing infrastructure of a software-defined data center (SDDC) while considering the interdependencies between the services. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of providing techniques for automating service upgrades within the computing infrastructure of a software-defined data center (SDDC) while considering the interdependencies between the services as suggested by Kalaskar (see para [0007]).
With respect to claim 16 (Previously presented), Parees as modified by Mueller, Vaddi and Kalaskar discloses The non-transitory computer-readable storage medium of claim 15, Vaddi discloses wherein to determine that the code update for the service is available, the instructions, when executed by the processing device, cause the processing device to determine that the code update for the service is available at periodic intervals (e.g. para [0015], “… The first set of instructions may enable detecting updates to the application code in the code storage location, for example, by periodic polling,. …” For motivation to combine, please refer to office action regarding claim 15 above.)
With respect to claim 18 (Previously presented), Parees as modified by Mueller, Vaddi and Kalaskar discloses The non-transitory computer-readable storage medium of claim 15, Kalaskar discloses wherein to retrieve the code update from the centralized repository, the instructions, when executed by the processing device, cause the processing device to:
download the code update from the centralized repository to the container of each of the plurality of instances of the service (e.g. para [0020], “… Each of the containers can include a self-contained execution environment having its own CPU, memory, block input/output (I/O), and network resources which are isolated from other containers. In some examples, a single one of the containers can implement a single one of the computing services 114.”. For motivation to combine, please refer to office action regarding to claim 15 above).
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Parees in view of Mueller and Vaddi as applied to claim 1, in further view of Tank et al. (US 20210248205 A1, hereinafter “Tank” cited from IDS filed 6/26/2023).
With respect to claim 7 (Previously presented), Parees as modified by Mueller and Vaddi discloses The method of claim 6, but does not appear to explicitly disclose wherein the metadata of the central repository comprises a signature of the code update. However, this is taught in an analogous art, Tank (e.g. para [0061], “… In some implementations, the resource identifier 235 can access the content delivery network 215 using one or more default authentication policies. For example, the resource identifier may contact a trusted computing device or service to receive one or more authentication certificates. These authentication certificates may be signed to ensure the authenticity of the resource identifier 235 or the layout service 205. …”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the authentication process of Tank because it provides security protection of the IT property by only allow authenticated users to access the property. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of providing security protection of the IT property as suggested by Tank (see para [0061]).
Claims 8-11 are rejected under 35 U.S.C. 103 as being unpatentable over Kalaskar et al. (US 20200334027 A1, hereinafter “Kalaskar”) in view of Vaddi et al. (US US 20200409680 A1, hereinafter “Vaddi”).
With respect to claim 8 (Previously presented), Kalaskar discloses A system comprising:
a plurality of host machines executing one or more instances of a service for a computing workload, the one or more instances of the service being within one or more containers (e.g. para [0007], “… As upgrades and patches become available for services and other types of applications installed on host devices within a data center, data center operators can request an upgrade of the installed services. …” para [0020], “One or more computing services 114 can be provided through execution of an application or service on one or more of the virtual machines. … the computing services 114 can be implemented in computing containers. …”); and
a central code repository communicatively coupled to the plurality of host machines, the central code repository comprising a processing device to (e.g. Fig. 1, Computing Environment 103, wherein Data Store(s) 121 which reads on the central code repository is coupled with management service 145 which comprises a processing device, see para [0038-0050]);
receive modifications to the service (e.g. para [0040-41], “… In some examples, the life cycle manager 139 can provide the third-party upgrade manager 142 with the upgrade bundle 124, …”);
publish the modifications to the service to be available to the one or more instances of the service (e.g. para [0032], “The management console 148 can provide an administrative interface for configuring the operation of individual components in the networked environment 100. For instance, the management console 148 can provide an administrative interface for the management service 145. As an example, the management console 148 can provide a user interface to allow notify an administrative user of available upgrades associated with computing services or resources of the networked environment 100. The management console 148 can also provide a user interface to allow the administrative user to request upgrades and view the status associated with the requested upgrades. …”);
Kalaskar does not appear to explicitly disclose in response to receiving a pull request to retrieve the modifications to the service from one of the one or more instances of the service, provide the modifications to the service to one or more daemons of the one or more instances of the service. However, this is taught in analogous art, Vaddi (e.g. para [0052], “At block 406, the repository node is requested for the updated version of the application code. At block 408, the updated version of the application code is received in response to the request. …” Para [0054], “In an example, the steps at blocks 402-410 may be performed in response to execution of a set of instructions in a container image from which the container is instantiated. The container image may be, for example, the container image 108. The set of instructions may be, for example, the first set of instructions 106.” Wherein execution of the set of instructions 106 reads on the daemon of the container.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Parees and the invention of Vaddi because it provides techniques for testing changes to application code corresponding to container-based application with minimal expenditure of time and network resources. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of providing techniques for testing changes to application code corresponding to container-based application with minimal expenditure of time and network resources as suggested by Vaddi (see para [0012]).
With respect to claim 9 (Original), Kalaskar discloses wherein the central code repository comprises a continuously running code repository accessible by each of the one or more instances of the service (e.g. para [0019], “… The computing systems 106 can be scalable, meaning that the computing systems 106 in the networked environment 100 can increase or decrease dynamically to include or remove hosts 118, switches 15, GPUs, power sources, and other components, without degrading performance of a virtualization or cloud computing environment.” where the network services dynamically changing without degrading performance clearly shows continuously running code repository accessible by the instance of the service because all the codes in form of data are stored in the repository (see para [0023-0024]).
With respect to claim 10 (Original), Kalaskar discloses wherein the modifications to the service comprise one or more code changes for the service pushed to the central code repository from a developer system (e.g. para [0024], “The data store 121 can include an upgrade bundle 124 and an upgrade status log 127. The upgrade bundle 124 includes a bundle of upgrades and patches for software services associated with a software-based system of the data center. …” wherein upgrades and patches read on code changes and stored in data store indicates pushed to the central code repository).
With respect to claim 11 (Previously presented), Kalaskar as modified by Vaddi discloses The system of claim 8, Kalaskar further discloses wherein the modifications are associated with an access location of the service, and wherein the [pull] request to retrieve the modifications comprises the access location of the modifications (e.g. Fig. 3, steps 303 and 306, para [0040], “At step 306, the life cycle manager 139 can retrieve the upgrade bundle 124 associated with the requested upgrade from the data store 121. …” apparently the request comprises the access location). And Vaddi discloses the [pull] request (e.g. para [0052, 0054] as cited above for claim 8. For motivation to combine, please refer to office action regarding claim 8).
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Kalaskar in view of Vaddi as applied to claim 8, in further view of Tank et al. (US 20210248205 A1, hereinafter “Tank” cited from IDS filed 6/26/2023)
With respect to claim 12 (Original), Kalaskar as modified by Vaddi discloses The system of claim 8, Kalaskar discloses wherein to publish the modifications, the processing device is to:
[store a signature of the modifications as metadata associated with the modifications], the metadata being accessible by each of the one or more instances of the service (e.g. para [0024-0026]), but does not appear to explicitly disclose store a signature of the modifications as metadata associated with the modifications, However, this is taught in an analogous art, Tank (e.g. para [0061], “… In some implementations, the resource identifier 235 can access the content delivery network 215 using one or more default authentication policies. For example, the resource identifier may contact a trusted computing device or service to receive one or more authentication certificates. These authentication certificates may be signed to ensure the authenticity of the resource identifier 235 or the layout service 205. …”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the authentication process of Tank because it provides security protection of the IT property by only allow authenticated users to access the property. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of providing security protection of the IT property as suggested by Tank (see para [0061]).
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Kalaskar in view of Vaddi and Tank as applied to claim 12, in further view of Zeavelou et al. (US 11093321 B1, hereinafter “Zeavelou” cited from IDS filed 6/26/2023)
With respect to claim 13 (Original), Kalaskar as modified by Vaddi and Tank discloses The system of claim 12, Tank discloses the signature associated with the modification, but does not appear to explicitly disclose wherein the signature comprises a checksum of the modifications. However, this is taught in analogous art, Zeavelou (e.g. col 12, lines 28-39, “… The method may initiate the installation of the update after performing verification, such as using a checksum or signature verification or other suitable processes and may require a reboot of the information handling system. …”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the invention of Zeavelou because it provides techniques to verify the update using a checksum to ensure the update is authentic. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of ensuring the update is authentic as suggested by Zeavelou (e.g. col 12, lines 28-39).
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Kalaskar in view of Vaddi and Tank as applied to claim 12, in further view of Buczkowski (US 20200110591 A1, hereinafter “Buczkowski”)
With respect to claim 14 (Previously presented), Kalaskar as modified by Vaddi and Tank discloses The system of claim 12, but does appear to explicitly disclose wherein to store the signature of the modifications as the metadata, the processing device is to:
store the signature in a configuration map (configMap) associated with the plurality of host machines and the central code repository However, this is taught in analogous art, Buczkowski (e.g. para [0035], “Embodiments of the present invention automatically generates the configuration profile 145 for installation of the software application 115. The configuration profile 145 is uniquely identified by use of the UUID key 147, which is used to manage the configuration profile 145 in the installation target platform 103
subsequent to installing the software application 115. The UUID keys 147
corresponding to respective configuration profiles 145 are stored in the system
configuration database 150, and utilized to manage a collection of configuration profiles for a multiple instances of the installation target platform 103 as an ecosystem of macOS devices, rather than a random collection of individual devices that requires respective management schemes. …” wherein the UUID reads on the signature.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the invention of Buczkowski because it supports the system configuration database storing the UUID keys to search and identify previously installed configuration profile corresponding to previous versions of the same software application, and improves the security of the device with the configuration profile by certifying the configuration profile and by preventing end user access and modification. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of improving the security of the device as suggested by Buczkowski (see para [0114]).
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Parees in view of Mueller, Vaddi and Kalaskar as applied to claim 15, in further view of Williams (US 20080133922 A1, hereinafter “Williams”).
With respect to claim 17 (Previously presented), Parees as modified by Mueller, Vaddi and Kalaskar discloses The non-transitory computer-readable storage medium of claim 15, but does not appear to explicitly disclose wherein to determine that the code update for the service is available, the instructions, when executed by the processing device, cause the processing device to:
access metadata associated with the centralized repository, the access metadata comprising a signature of the code update; and
determine that the signature of the code update indicates that the code update is stored at the centralized repository.
However, in analogous art, Williams discloses
access metadata associated with the centralized repository, the access metadata comprising a signature of the code update (e.g. para [0035], “… The root directory digital signature metadata may be transmitted to a server that determines the availability of an update for the device by using the digital signature metadata to access a database. …”); and
determine that the signature of the code update indicates that the code update is stored at the centralized repository (e.g. para [0035], “… For example, there may be a relatively limited number of file configurations that have been provided by the manufacturer and each of these configurations will be associated with a unique digital signature metadata value for the root directory. Upon receipt of a known digital signature metadata for the root directory, the server will be able to identify whether an update is available and what that update consists of. …”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the invention of Williams because it provides an efficient mechanism for identifying the present file configuration of the embedded system which may be used in any of a variety of ways to identify the update that should be used by the embedded system. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of providing an efficient mechanism for identifying the update that should be used as suggested by Williams (see para [0017]).
Claims 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Parees in view of Mueller, Vaddi and Kalaskar as applied to claim 15, in further view of Qureshi et al. (US 9916233 B1, hereinafter “Qureshi”).
With respect to claim 19 (Previously presented), Parees as modified by Mueller, Vaddi and Kalaskar discloses The non-transitory computer-readable storage medium of claim 15, but does not appear to explicitly disclose wherein the instructions, when executed by the processing device, further cause the processing device to:
perform a snapshot of each of the plurality of instances of the service prior to updating each of the plurality of instances of the service. However, this is taught in analogous art, Qureshi (e.g. col 21, lines 48-67, “… For example, it may be advantageous to retain the previously active container for some minimum retention period (or even indefinitely), or until a second software update
becomes available, as a hedge against a situation in which issues arise with the
software package that were not discovered during testing. ...” wherein retaining previously active container reads on performing a snapshot.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the invention of Qureshi because it provides techniques for improving the field of software deployment, by, for a computing device targeted to receive a software update, taking advantage of unused or idle resources on the computing device to perform testing of the software update on the computing device in order to closely replicate how the software update will actually perform when made live. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of providing techniques for improving the field of software deployment, by, for a computing device targeted to receive a software update, taking advantage of unused or idle resources on the computing device to perform testing of the software update on the computing device in order to closely replicate how the software update will actually perform when made live as suggested by Qureshi (see col 3, lines 45-60).
With respect to claim 20 (Previously presented), Parees as modified by Mueller, Vaddi, Kalaskar and Qureshi discloses The non-transitory computer-readable storage medium of claim 19, Qureshi further discloses wherein the instructions, when executed by the processing device, further cause the processing device to:
monitor performance of each of the plurality of instances of the service (e.g. col 20, lines 55-63, “… The deployment agent may also be responsible for monitoring the health and status (e.g., “idle,” “ready to receive update,” etc.) of the device, …” wherein health and status read on performance); and
in response to a detection a performance regression of the service associated with the code update, revert each of the plurality of instances of the service to a previous state in view of the snapshot of each of the plurality of instances of the service (e.g. col 21, lines 48-67, “… it may be advantageous to retain the previously active container for some minimum retention period (or even indefinitely), or until a second software update becomes available, as a hedge against a situation in which issues arise with the software
package that were not discovered during testing. In such a situation, the deployment service may send a rollback notification to the device, and, in response, a deployment agent on the device may cause the previously active container to be quickly re-activated to be the active container on the device (rendering the new active container inactive), and the device may be thereby rolled back to its previous state before the software package was installed. ...” For motivation to combine, please refer to office action regarding claim 19).
Response to Arguments
Applicant's arguments with respect to art rejections filed 12/15/2025 have been fully considered but they are not persuasive.
At p7 second from the last paragraph of the Remarks, Applicant argued with respect to “by a daemon of the container” that “it is submitted that Parees and Vaddi, alone or in combination, have not been shown to suggest "by a daemon of the container" as recited in claim 1.”
Examiner respectfully disagrees, because, Parees teaches “the modification to the source code is identified via the application framework utilized in the instance”, see para [0075], and “the identified modification to the source code is applied, via the application framework, to the source code during runtime of the instance in the container.” See para [0076]. This paragraph suggests that there is a background process in the application framework that applies the identified modification to the source code during runtime of the instance in the container, therefore, applying modification to the source code via the application framework during runtime of the instance in the container suggests the daemon of the container in the application framework.
At p7 last to p8 first paragraph of the Remarks, Applicant argued with respect to the new amendment feature that the cited references “Parees and Vaddi, alone or in combination, have to not been shown to suggest "performing, by the daemon of the container and via a hot reload, a modification of the instance of the service by overlaying the code update over a base image corresponding to the service" as recited in amended claim 1.”
Examiner respectfully disagrees and points out that this argument is moot upon new ground of rejections made in the office action above because the newly cited reference Mueller teaches the new amendment feature.
At p8 second paragraph of the Remarks, Applicant argued that “Per the foregoing, withdrawal of the rejection of claim 1 is requested. Dependent claim 5 is believed to be allowable at least by virtue of its dependency from base claim 1. Accordingly, withdrawal of the rejection is requested.”
Examiner respectfully disagrees, because as explained above, Parees teaches the daemon of the container, the newly cited reference Mueller teaches the new amendment feature, claim 1 is rejected, claim 5 is similarly rejected.
At p8 last paragraph to p10 of the Remarks, Applicant argued that other independent claims 8 and 15 recite similar features in claim 1, and are therefore allowable, and all other dependent claims are allowable because they depend from their respective independent claims 1, 8, or 15.
Examiner respectfully disagrees, because, as explained above, claim 1 is rejected, all other claims are similarly rejected.
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 Zengpu Wei whose telephone number is 571-270-1302. The examiner can normally be reached on Monday to Friday from 8:00AM to 5:00 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bradley Teets, can be reached on 571-272-3338. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://portal.uspto.gov/external/portal. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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.
/ZENGPU WEI/
Examiner, Art Unit 2197
/BRADLEY A TEETS/Supervisory Patent Examiner, Art Unit 2197