DETAILED ACTION
1. This is a Final Office Action Correspondence in response to amendments/arguments for U.S. Application No. 19/013416 filed on November 17, 2025.
Applicant
2. Applicant is encouraged to contact the Examiner in hopes of reaching a resolution in light of compact prosecution.
Response to Arguments
3. Applicant’s arguments have been considered but are not persuasive.
A new reference is presented below to teach the amended limitations.
Double Patenting
4. The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory obviousness-type double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the conflicting application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement.
Effective January 1, 1994, a registered attorney or agent of record may sign a terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 37 CFR 3.73(b).
5. Claims 1, 2, 3, 4, 8, 9, 10, 11, 15, 16, 17 and 20 are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims 1, 6, 9, 12, 13 and 15 of U.S. Patent No. 12,229,144. Although the conflicting claims are not identical, they are not patentably distinct from each other because both applications discuss maintenance availability during conflicts.
U.S. Patent No. 12,229,144
U.S. Patent Application No. 19,013,416 (herein as ‘Patent 416’)
1
1
1
2
1
3
1
4
9
8
9
9
9
10
9
11
13
15
13
16
13
17
15
20
As to claim 1 Patent 416 teaches a system, comprising: a cluster, including one or more nodes, wherein a plurality of applications are installed on the cluster;a memory; andone or more processors in communication with the memory, wherein the one or more processors are configured to, prior to a maintenance activity associated with the one or more nodes in the cluster (Claim 1 Patent 416 discloses A system, comprising: a cluster, including one or more nodes and an application programming interface (API) server; a memory; and one or more processors in communication with the memory, wherein the one or more processors are configured to, prior to performing a maintenance activity associated with a node of the one or more nodes in the cluster);
receive a request to determine a state of maintenance availability of a first application of the plurality of applications; in response to receiving the request, retrieve deployment metadata for the plurality of applications installed on the cluster; parse the deployment metadata to identify one or more installation rules associated with the plurality of applications (Claim 1 Patent 416 discloses receive a request to determine a state of maintenance availability of the cluster, wherein a plurality of applications are installed on the cluster, and wherein the state of maintenance availability of the cluster indicates whether or not one or more applications of the plurality of applications or the cluster in its entirety is vulnerable to disruptions due to the maintenance activity; and in response to receiving the request: query the API server to retrieve deployment metadata to discover each of the plurality of applications installed on the cluster; in response to retrieving the deployment metadata, parse the deployment metadata for each of the plurality of applications to retrieve one or more installation rules associated with each of the plurality of applications);
determine a set of conflicts for the first application by determining whether a future downtime of a node in the cluster and associated with a second application of the plurality of applications would create an effect on the first application based on the one or more installation rules (Claim 1 Patent 416 discloses based on retrieving the one or more installation rules, correlate a first subset of the one or more installation rules associated with a first application of the plurality of applications with a second subset of the one or more installation rules of the plurality of applications to determine a set of conflicts for the first application, wherein determining the set of conflicts comprises determining whether a future downtime of a first node within the cluster would create an effect on the first application, wherein determining the set of conflicts further comprises determining whether a future downtime of each node within the cluster and associated with a second application of the plurality of applications would create an effect on the first application, wherein each conflict of the set of conflicts for the first application is associated with a potential disruption related to the first application caused by the maintenance activity associated with the node);
determine the state of maintenance availability of the first application based on the set of conflicts (Claim 1 Patent 416 discloses determine the state of maintenance availability based on the set of conflicts for the first application);
and provide a notification to a user comprising the state of maintenance availability of the first application and correction actions for the first application (Claim 1 Patent 416 discloses and based on determining the state of maintenance availability, output a notification to a user based on the state of maintenance availability, wherein the notification indicates whether the maintenance activity is unlikely to be successful based on the state of maintenance availability) (Claim 1 Patent 416 discloses).
As to claim 2 Patent 416 teaches wherein an installation rule of the one or more installation rules comprises a node affinity indicating that an application or one or more portions of the application is to be installed on a single node or multiple nodes (Claim 1 Patent 416 discloses in response to retrieving the deployment metadata, parse the deployment metadata for each of the plurality of applications to retrieve one or more installation rules associated with each of the plurality of applications).
As to claim 3 Patent 416 teaches wherein the set of conflicts are associated with potential disruptions related to the first application (Claim 1 Patent 416 discloses wherein determining the set of conflicts comprises determining whether a future downtime of a first node within the cluster would create an effect on the first application).
As to claim 4 Patent 416 teaches wherein the one or more processors are further configured to determine the set of conflicts for the first application by determining whether a future downtime of a first node within the cluster and associated with the first application would disrupt the first application (Claim 1 Patent 416 discloses wherein determining the set of conflicts comprises determining whether a future downtime of a first node within the cluster would create an effect on the first application, wherein determining the set of conflicts further comprises determining whether a future downtime of each node within the cluster and associated with a second application of the plurality of applications would create an effect on the first application).
As to claim 8 Patent 416 teaches 8. A method comprising, prior to a maintenance activity associated with one or more nodes in a cluster (Claim 9 Patent 416 discloses a cluster, including one or more nodes and an application programming interface (API) server; a memory; and one or more processors in communication with the memory, wherein the one or more processors are configured to, prior to performing a maintenance activity associated with a node of the one or more nodes in the cluster);
receiving a request to determine a state of maintenance availability of a first application of a plurality of applications installed on the cluster; in response to receiving the request, retrieving deployment metadata for the plurality of applications installed on the cluster; parsing the deployment metadata to identify one or more installation rules associated with the plurality of applications (Claim 9 Patent 416 discloses receive a request to determine a state of maintenance availability of the cluster, wherein a plurality of applications are installed on the cluster, and wherein the state of maintenance availability of the cluster indicates whether or not one or more applications of the plurality of applications or the cluster in its entirety is vulnerable to disruptions due to the maintenance activity; and in response to receiving the request: query the API server to retrieve deployment metadata to discover each of the plurality of applications installed on the cluster; in response to retrieving the deployment metadata, parse the deployment metadata for each of the plurality of applications to retrieve one or more installation rules associated with each of the plurality of applications);
determining a set of conflicts for the first application by determining whether a future downtime of a node in the cluster and associated with a second application of the plurality of applications would create an effect on the first application based on the one or more installation rules (Claim 9 Patent 416 discloses wherein determining the set of conflicts comprises determining whether a future downtime of a first node within the cluster would create an effect on the first application, wherein determining the set of conflicts further comprises determining whether a future downtime of each node within the cluster and associated with a second application of the plurality of applications would create an effect on the first application, wherein each conflict of the set of conflicts for the first application is associated with a potential disruption related to the first application caused by the maintenance activity associated with the node);
determining the state of maintenance availability of the first application based on the set of conflicts (Claim 9 Patent 416 discloses determine the state of maintenance availability based on the set of conflicts for the first application);
and providing a notification to a user comprising the state of maintenance availability of the first application and correction actions for the first application (Claim 9 Patent 416 discloses and based on determining the state of maintenance availability, output a notification to a user based on the state of maintenance availability, wherein the notification indicates whether the maintenance activity is unlikely to be successful based on the state of maintenance availability); (Claim 9 Patent 416 discloses).
As to claim 9 Patent 416 teaches wherein an installation rule of the one or more installation rules comprises a node affinity indicating an application or one or more portions of the application is to be installed on a single node or multiple nodes (Claim 9 Patent 416 discloses in response to retrieving the deployment metadata, parse the deployment metadata for each of the plurality of applications to retrieve one or more installation rules associated with each of the plurality of applications).
As to claim 10 Patent 416 teaches wherein the set of conflicts are associated with potential disruptions related to the first application (Claim 9 Patent 416 discloses wherein determining the set of conflicts comprises determining whether a future downtime of a first node within the cluster would create an effect on the first application, wherein determining the set of conflicts further comprises determining whether a future downtime of each node within the cluster and associated with a second application of the plurality of applications would create an effect on the first application, wherein each conflict of the set of conflicts for the first application is associated with a potential disruption related to the first application caused by the maintenance activity associated with the node);
As to claim 11 Patent 416 teaches further comprising determining the set of conflicts for the first application by determining whether a future downtime of a first node within the cluster and associated with the first application would disrupt the first application ((Claim 9 Patent 416 discloses wherein determining the set of conflicts comprises determining whether a future downtime of a first node within the cluster would create an effect on the first application, wherein determining the set of conflicts further comprises determining whether a future downtime of each node within the cluster and associated with a second application of the plurality of applications would create an effect on the first application, wherein each conflict of the set of conflicts for the first application is associated with a potential disruption related to the first application caused by the maintenance activity associated with the node);).
As to claim 15 Patent 416 teaches a non-transitory computer-readable medium comprising program code that is executable by one or more processors for causing the one or more processors to, prior to a maintenance activity associated with one or more nodes in a cluster (Claim 13 Patent 416 discloses a memory; and one or more processors in communication with the memory, wherein the one or more processors are configured to, prior to performing a maintenance activity associated with a node of the one or more nodes in the cluster);
receive a request to determine a state of maintenance availability of a first application of a plurality of applications installed on the cluster; in response to receiving the request, retrieve deployment metadata for the plurality of applications installed on the cluster; parse the deployment metadata to identify one or more installation rules associated with the plurality of applications (Claim 13 Patent 416 discloses receive a request to determine a state of maintenance availability of the cluster, wherein a plurality of applications are installed on the cluster, and wherein the state of maintenance availability of the cluster indicates whether or not one or more applications of the plurality of applications or the cluster in its entirety is vulnerable to disruptions due to the maintenance activity; and in response to receiving the request: query the API server to retrieve deployment metadata to discover each of the plurality of applications installed on the cluster; in response to retrieving the deployment metadata, parse the deployment metadata for each of the plurality of applications to retrieve one or more installation rules associated with each of the plurality of applications);
determine a set of conflicts for the first application by determining whether a future downtime of a node in the cluster and associated with a second application of the plurality of applications would create an effect on the first application based on the one or more installation rules (Claim 13 Patent 416 discloses wherein determining the set of conflicts comprises determining whether a future downtime of a first node within the cluster would create an effect on the first application, wherein determining the set of conflicts further comprises determining whether a future downtime of each node within the cluster and associated with a second application of the plurality of applications would create an effect on the first application, wherein each conflict of the set of conflicts for the first application is associated with a potential disruption related to the first application caused by the maintenance activity associated with the node);
determine the state of maintenance availability of the first application based on the set of conflicts (Claim 13 Patent 416 discloses determine the state of maintenance availability based on the set of conflicts for the first application);
and provide a notification to a user comprising the state of maintenance availability of the first application and correction actions for the first application (Claim 13 Patent 416 discloses and based on determining the state of maintenance availability, output a notification to a user based on the state of maintenance availability, wherein the notification indicates whether the maintenance activity is unlikely to be successful based on the state of maintenance availability).
As to claim 16 Patent 416 teaches wherein an installation rule of the one or more installation rules comprises a node affinity indicating an application or one or more portions of the application is to be installed on a single node or multiple nodes, and wherein the set of conflicts are associated with potential disruptions related to the first application (Claim 13 Patent 416 discloses wherein determining the set of conflicts comprises determining whether a future downtime of a first node within the cluster would create an effect on the first application, wherein determining the set of conflicts further comprises determining whether a future downtime of each node within the cluster and associated with a second application of the plurality of applications would create an effect on the first application, wherein each conflict of the set of conflicts for the first application is associated with a potential disruption related to the first application caused by the maintenance activity associated with the node).
As to claim 17 Patent 416 teaches further comprising program code that is executable by the one or more processors for causing the one or more processors to determine the set of conflicts for the first application by determining whether a future downtime of a first node within the cluster and associated with the first application would disrupt the first application (Claim 13 Patent 416 discloses wherein determining the set of conflicts comprises determining whether a future downtime of a first node within the cluster would create an effect on the first application, wherein determining the set of conflicts further comprises determining whether a future downtime of each node within the cluster and associated with a second application of the plurality of applications would create an effect on the first application, wherein each conflict of the set of conflicts for the first application is associated with a potential disruption related to the first application caused by the maintenance activity associated with the node).
As to claim 20 Patent 416 teaches further comprising program code that is executable by the one or more processors for causing the one or more processors to determine a set of updates to the set of installation rules associated with the first application based on the set of differences, wherein the set of updates comprises at least one rule from the one or more model installation rules (Claim 15 Patent 416 discloses wherein the non-transitory computer-readable medium further comprises program code that is executable by the one or more processors to: determine a set of updates to the one or more installation rules associated with each of the plurality of applications based on the set of conflicts, wherein the set of updates include at least one rule from one or more model installation rules).
Claim Rejections - 35 USC § 103
6. 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.
7. 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.
8. Claim(s) 1-4, 8-11, 15-17 is/are rejected under 35 U.S.C. 103 as being unpatentable by Melnik et al. U.S. Patent Application Publication No. 2017/0315796 (herein as ‘Melnik’) and further in view of Fontoura et al. U.S. Patent No. 10,768,920 (herein as ‘Fontoura’) and Holzer et al. U.S. Patent Application Publication No. 2020/0133651 (herein as ‘Holzer’).
As to claim 1 Melnik teaches a system, comprising:
a cluster, including one or more nodes, wherein a plurality of applications are installed on the cluster (Par. 0079 Melnik discloses a cluster and server. Par. 0088 Melnik discloses the user has an interface);
a memory, and one or more processors in communication with the memory (Par. 0095 Melnik discloses a processor and memory);
wherein the one or more processors are configured to, prior to a maintenance activity associated with the one or more nodes in the cluster (Par. 0151 Melnik discloses the installed applications located on the groups);
receive a request to determine a state of maintenance availability of a first application of the plurality of applications (Par. 0027 and 0125 Melnik discloses the applications are stored on the group and populated with available groups);
in response to receiving the request, retrieve deployment metadata for the plurality of applications installed on the cluster (Par. 0073 Melnik discloses event data associated with type definitions. Par. 0101 Melnik discloses the dependency relationships are text information. Par. 0079 Melnik discloses searching textual information. Par. 0096 Melnik discloses the user can access and modify parameters associated with dependency relationships for applications. The dependency relationships are seen as type definitions that are seen as events, that are associated with textual information);
parse the deployment metadata to identify one or more installation rules associated with the plurality of applications (Fig. 14 and Par. 0070 Melnik discloses parsing the data to be processed. Par. 0117 Melnik discloses the rules are used for applications to be installed to resolve conflicts. Par. 0127 Melnik discloses during the deployment phrase each application containing notifications to alert the deployment system of conflict and an option of aborting installation is provided. The notification is seen as the metadata);
Melink does not teach but Fontoura teaches determine a set of conflicts for the first application by determining whether a potential disruption of a node in the cluster and associated with a second application of the plurality of applications would create an effect on the first application based on the one or more installation rules (Col. 22 Lines 45-56 Fontoura discloses the update coordinator 508 receives requests from at least two or more tenants. The tenants are seen as first and second application. Col. 26 Lines 39-45 Fontoura discloses determining the expected downtime, that performing an update will incur on another tenant. Col. 27 59-65 Fontoura discloses the update coordinator detecting bad behavior. Detecting bad behavior that will affect tenant downtime is seen as determining a potential disruption based on rules. An example of bad behavior is approval of too many requests may degrade or interrupts execution of tenant applications. Approval of high update requests is seen as the set of conflicts for the application. The second application effecting the first application is seen as too many updates interrupts execution of tenant applications).
Melnik and Fontoura are analogous art because they are in the same field of endeavor, transaction processing. It would have been obvious to one of ordinary skill in the art, before the effective filing date, to modify the installation rules of Melnik to include the node processing of Fontoura, to allow nodes to match application demand so that the cloud tenant does not have to allocate those resources manually (Col. 1 Lines 63-66 Fontoura).
Melink teaches determine the state of maintenance availability of the first application based on the set of conflicts (Fig. 14 and Par. 0127 Melnik discloses each application containing notifications to alert the deployment system of conflict and an option of aborting installation is provided. The notification is seen as the metadata);
Melnik does not teach but Holzer teaches and provide a notification to a user comprising the state of maintenance availability of the first application and correction actions for the first application (Par. 0053 Holzer discloses the system monitoring components such as deployment models to identify potential error or risk based upon the application definition. The errors or risk are seen as state of deployment. The potential errors or risks are highlighted. Highlighting the errors or risk is seen as an output of a notification).
Melnik and Holzer are analogous art because they are in the same field of endeavor, transaction processing. It would have been obvious to one of ordinary skill in the art, before the effective filing date, to modify the installation rules of Melnik to include the identifying risk or errors of Holzer, to enhance fault tolerance of the modules. The suggestion/motivation to combine is that it would be obvious to try in order to improve performance that may occur when the user of the automation engine increases and thus a need to unlimited number of work and communication processes (Par. 0032 Holzer).
As to claim 2 Melnik in combination with Fontoura and Holzer teaches each and every limitation of claim 1.
In addition Melnik teaches wherein an installation rule of the one or more installation rules comprises a node affinity indicating that an application or one or more portions of the application is to be installed on a single node or multiple nodes (Par. 0119 Melnik discloses using the dependency rules to match applications that are compatible with existing dependencies of applications).
As to claim 3 Melnik in combination with Fontoura and Holzer teaches each and every limitation of claim 1.
In addition Melnik teaches wherein the set of conflicts are associated with potential disruptions related to the first application (Fig. 14 and Par. 0127 Melnik discloses each application containing notifications to alert the deployment system of conflicts and an option of aborting installation is provided. The notification is seen as the metadata.
As to claim 4 Melnik in combination with Fontoura and Holzer teaches each and every limitation of claim 1.
In addition Melnik teaches wherein the one or more processors are further configured to determine the set of conflicts for the first application by determining whether a potential disruption of a first node within the cluster and associated with the first application would disrupt the first application (Par. 0015 Gururaj discloses nodes assigned to the cluster. When it is determined that the first node failed, the remaining transactions are processed by node two. Node two taking over transactions is seen as effect on the first application).
As to claim 8 Melnik teaches a method comprising, prior to a maintenance activity associated with one or more nodes in a cluster:
receiving a request to determine a state of maintenance availability of a first application of a plurality of applications installed on the cluster (Par. 0027 and 0125 Melnik discloses the applications are stored on the group and populated with available groups);
in response to receiving the request, retrieving deployment metadata for the plurality of applications installed on the cluster (Par. 0073 Melnik discloses event data associated with type definitions. Par. 0101 Melnik discloses the dependency relationships are text information. Par. 0079 Melnik discloses searching textual information. Par. 0096 Melnik discloses the user can access and modify parameters associated with dependency relationships for applications. The dependency relationships are seen as type definitions that are seen as events, that are associated with textual information);
parsing the deployment metadata to identify one or more installation rules associated with the plurality of applications (Fig. 14 and Par. 0070 Melnik discloses parsing the data to be processed. Par. 0117 Melnik discloses the rules are used for applications to be installed to resolve conflicts. Par. 0127 Melnik discloses during the deployment phrase each application containing notifications to alert the deployment system of conflict and an option of aborting installation is provided. The notification is seen as the metadata);
Melink does not teach but Fontoura teaches determining a set of conflicts for the first application by determining whether a potential disruption of a node in the cluster and associated with a second application of the plurality of applications would create an effect on the first application based on the one or more installation rules (Col. 22 Lines 45-56 Fontoura discloses the update coordinator 508 receives requests from at least two or more tenants. The tenants are seen as first and second application. Col. 26 Lines 39-45 Fontoura discloses determining the expected downtime, that performing an update will incur on another tenant. Col. 27 59-65 Fontoura discloses the update coordinator detecting bad behavior. Detecting bad behavior that will affect tenant downtime is seen as determining a potential disruption based on rules. An example of bad behavior is approval of too many requests may degrade or interrupts execution of tenant applications. Approval of high update requests is seen as the set of conflicts for the application. The second application effecting the first application is seen as too many updates interrupts execution of tenant applications).
Melnik and Fontoura are analogous art because they are in the same field of endeavor, transaction processing. It would have been obvious to one of ordinary skill in the art, before the effective filing date, to modify the installation rules of Melnik to include the node processing of Fontoura, to allow nodes to match application demand so that the cloud tenant does not have to allocate those resources manually (Col. 1 Lines 63-66 Fontoura).
Melink teaches determining the state of maintenance availability of the first application based on the set of conflicts (Fig. 14 and Par. 0127 Melnik discloses each application containing notifications to alert the deployment system of conflict and an option of aborting installation is provided. The notification is seen as the metadata);
Melnik does not teach but Holzer teaches and providing a notification to a user comprising the state of maintenance availability of the first application and correction actions for the first application (Par. 0053 Holzer discloses the system monitoring components such as deployment models to identify potential error or risk based upon the application definition. The errors or risk are seen as state of deployment. The potential errors or risks are highlighted. Highlighting the errors or risk is seen as an output of a notification).
Melnik and Holzer are analogous art because they are in the same field of endeavor, transaction processing. It would have been obvious to one of ordinary skill in the art, before the effective filing date, to modify the installation rules of Melnik to include the identifying risk or errors of Holzer, to enhance fault tolerance of the modules. The suggestion/motivation to combine is that it would be obvious to try in order to improve performance that may occur when the user of the automation engine increases and thus a need to unlimited number of work and communication processes (Par. 0032 Holzer).
As to claim 9 Melnik in combination with Fontoura and Holzer teaches each and every limitation of claim 8.
In addition Melnik teaches wherein an installation rule of the one or more installation rules comprises a node affinity indicating an application or one or more portions of the application is to be installed on a single node or multiple nodes (Par. 0119 Melnik discloses using the dependency rules to match applications that are compatible with existing dependencies of applications).
As to claim 10 Melnik in combination with Fontoura and Holzer teaches each and every limitation of claim 8.
In addition Melnik teaches wherein the set of conflicts are associated with potential disruptions related to the first application (Fig. 14 and Par. 0127 Melnik discloses each application containing notifications to alert the deployment system of conflicts and an option of aborting installation is provided. The notification is seen as the metadata).
As to claim 11 Melnik in combination with Fontoura and Holzer teaches each and every limitation of claim 8.
In addition Melnik teaches further comprising determining the set of conflicts for the first application by determining whether a potential disruption of a first node within the cluster and associated with the first application would disrupt the first application (Par. 0015 Gururaj discloses nodes assigned to the cluster. When it is determined that the first node failed, the remaining transactions are processed by node two. Node two taking over transactions is seen as effect on the first application).
As to claim 15 Melnik teaches a non-transitory computer-readable medium comprising program code that is executable by one or more processors for causing the one or more processors to, prior to a maintenance activity associated with one or more nodes in a cluster (Par. 0151 Melnik discloses the installed applications located on the groups);
receive a request to determine a state of maintenance availability of a first application of a plurality of applications installed on the cluster (Par. 0027 and 0125 Melnik discloses the applications are stored on the group and populated with available groups);
in response to receiving the request, retrieve deployment metadata for the plurality of applications installed on the cluster (Par. 0073 Melnik discloses event data associated with type definitions. Par. 0101 Melnik discloses the dependency relationships are text information. Par. 0079 Melnik discloses searching textual information. Par. 0096 Melnik discloses the user can access and modify parameters associated with dependency relationships for applications. The dependency relationships are seen as type definitions that are seen as events, that are associated with textual information);
parse the deployment metadata to identify one or more installation rules associated with the plurality of applications (Fig. 14 and Par. 0070 Melnik discloses parsing the data to be processed. Par. 0117 Melnik discloses the rules are used for applications to be installed to resolve conflicts. Par. 0127 Melnik discloses during the deployment phrase each application containing notifications to alert the deployment system of conflict and an option of aborting installation is provided. The notification is seen as the metadata);
Melink does not teach but Gururaj teaches determine a set of conflicts for the first application by determining whether a potential downtime of a node in the cluster and associated with a second application of the plurality of applications would create an effect on the first application based on the one or more installation rules (Col. 22 Lines 45-56 Fontoura discloses the update coordinator 508 receives requests from at least two or more tenants. The tenants are seen as first and second application. Col. 26 Lines 39-45 Fontoura discloses determining the expected downtime, that performing an update will incur on another tenant. Col. 27 59-65 Fontoura discloses the update coordinator detecting bad behavior. Detecting bad behavior that will affect tenant downtime is seen as determining a potential disruption based on rules. An example of bad behavior is approval of too many requests may degrade or interrupts execution of tenant applications. Approval of high update requests is seen as the set of conflicts for the application. The second application effecting the first application is seen as too many updates interrupts execution of tenant applications).
Melnik and Fontoura are analogous art because they are in the same field of endeavor, transaction processing. It would have been obvious to one of ordinary skill in the art, before the effective filing date, to modify the installation rules of Melnik to include the node processing of Fontoura, to allow nodes to match application demand so that the cloud tenant does not have to allocate those resources manually (Col. 1 Lines 63-66 Fontoura).
Melink teaches determine the state of maintenance availability of the first application based on the set of conflicts (Fig. 14 and Par. 0127 Melnik discloses each application containing notifications to alert the deployment system of conflict and an option of aborting installation is provided. The notification is seen as the metadata);
Melnik does not teach but Holzer teaches and provide a notification to a user comprising the state of maintenance availability of the first application and correction actions for the first application (Par. 0053 Holzer discloses the system monitoring components such as deployment models to identify potential error or risk based upon the application definition. The errors or risk are seen as state of deployment. The potential errors or risks are highlighted. Highlighting the errors or risk is seen as an output of a notification).
Melnik and Holzer are analogous art because they are in the same field of endeavor, transaction processing. It would have been obvious to one of ordinary skill in the art, before the effective filing date, to modify the installation rules of Melnik to include the identifying risk or errors of Holzer, to enhance fault tolerance of the modules. The suggestion/motivation to combine is that it would be obvious to try in order to improve performance that may occur when the user of the automation engine increases and thus a need to unlimited number of work and communication processes (Par. 0032 Holzer).
As to claim 16 Melnik in combination with Fontoura and Holzer teaches each and every limitation of claim 15.
In addition Melnik teaches wherein an installation rule of the one or more installation rules comprises a node affinity indicating an application or one or more portions of the application is to be installed on a single node or multiple nodes, and wherein the set of conflicts are associated with potential disruptions related to the first application (Par. 0119 Melnik discloses using the dependency rules to match applications that are compatible with existing dependencies of applications).
As to claim 17 Melnik in combination with Fontoura and Holzer teaches each and every limitation of claim 15.
In addition Melnik teaches further comprising program code that is executable by the one or more processors for causing the one or more processors to determine the set of conflicts for the first application by determining whether a potential disruption of a first node within the cluster and associated with the first application would disrupt the first application (Par. 0015 Gururaj discloses nodes assigned to the cluster. When it is determined that the first node failed, the remaining transactions are processed by node two. Node two taking over transactions is seen as effect on the first application).
9. Claim(s) 5-7, 12-14 and 18-20 is/are rejected under 35 U.S.C. 103 as being unpatentable by Melnik et al. U.S. Patent Application Publication No. 2017/0315796 (herein as ‘Melnik’), Fontoura et al. U.S. Patent No. 10,768,920 (herein as ‘Fontoura’) in combination with Holzer et al. U.S. Patent Application Publication No. 2020/0133651 (herein as ‘Holzer’) and further in view of. Shivamoggi et al. U.S. Patent Application Publication No. 2020/0184367 (herein as ‘Shivamoggi’)
As to claim 5 Melnik in combination with Fontoura and Holzer teaches each and every limitation of claim 1.
In addition Melnik teaches wherein the one or more processors are further configured to:
access one or more model installation rules associated with a model installation of the first application; compare a set of installation rules associated with the first application with the one or more model installation rules to determine a difference between the first application and the model installation of the first application (Par. 0092 Melnik discloses storing the pre-deployment settings. The pre-deployment settings are seen as the installation rules. Par. 0099 Melnik discloses the pre-deployment configuration module defines the parameters that are needed to configure a particular installation. Par. 0117-0118 Melnik discloses using dependency rules to identify conflicts between application package for installation. Fig. 14 and Par. 0127 Melnik discloses each application containing notifications to alert the deployment system of conflict and an option of aborting installation is provided. The notification is seen as the metadata);
Melnik does not teach but Shivamoggi teaches determine a state of deployment for the first application based on the difference, wherein the state of deployment comprises a level of potential disruption for the first application (Par. 0037 Shivamoggi discloses vulnerabilities are associated with threats and other items. Par. 0046 Shivamoggi discloses determining that a given cluster is more vulnerable based upon a node. Determining the vulnerability of the given cluster is seen as the state maintenance availability);
Melnik and Shivamoggi are analogous art because they are in the same field of endeavor, transaction processing. It would have been obvious to one of ordinary skill in the art, before the effective filing date, to modify the installation rules of Melnik to include the identifying security data of Shivamoggi, to manage vulnerabilities. The suggestion/motivation to combine is that it would be obvious to try in order to improve performance by efficiently defending new attacks (Par. 0002 Shivamoggi).
Holzer teaches and determine the state of maintenance availability based on the set of conflicts and the state of deployment (Par. 0053 Holzer discloses the system monitoring components such as deployment models to identify potential error or risk based upon the application definition. The errors or risk are seen as state of deployment. The potential errors or risks are highlighted. Highlighting the errors or risk is seen as an output of a notification).
As to claim 6 Melnik in combination with Fontoura and Holzer teaches each and every limitation of claim 5.
In addition Melnik teaches wherein the one or more processors are further configured to: access a mapping of deviations from model rules to remedial patterns; and determine, based on the mapping and the difference, a remedial pattern for the first application (Par. 0053 Holzer discloses the system monitoring components such as deployment models to identify potential error or risk based upon the application definition. The errors or risk are seen as state of deployment. The potential errors or risks are highlighted. Highlighting the errors or risk is seen as an output of a notification).
As to claim 7 Melnik in combination with Fontoura and Holzer teaches each and every limitation of claim 5.
In addition Melnik teaches wherein the one or more processors are further configured to: determine a set of updates to the set of installation rules associated with the first application based on the difference, wherein the set of updates comprises at least one rule from the one or more model installation rules (Par. 0108 Melnik discloses rules are updated that determine which portions of the source application are allocated to the application packages).
As to claim 12 Melnik in combination with Fontoura and Holzer teaches each and every limitation of claim 8.
In addition Melnik teaches further comprising: accessing one or more model installation rules associated with a model installation of the first application; comparing a set of installation rules associated with the first application with the one or more model installation rules to determine a difference between the first application and the model installation of the first application (Par. 0092 Melnik discloses storing the pre-deployment settings. The pre-deployment settings are seen as the installation rules. Par. 0099 Melnik discloses the pre-deployment configuration module defines the parameters that are needed to configure a particular installation. Par. 0117-0118 Melnik discloses using dependency rules to identify conflicts between application package for installation. Fig. 14 and Par. 0127 Melnik discloses each application containing notifications to alert the deployment system of conflict and an option of aborting installation is provided. The notification is seen as the metadata);
Melnik does not teach but Shivamoggi teaches determining a state of deployment for the first application based on the difference, wherein the state of deployment comprises a level of potential disruption for the first application (Par. 0037 Shivamoggi discloses vulnerabilities are associated with threats and other items. Par. 0046 Shivamoggi discloses determining that a given cluster is more vulnerable based upon a node. Determining the vulnerability of the given cluster is seen as the state maintenance availability);
Melnik and Shivamoggi are analogous art because they are in the same field of endeavor, transaction processing. It would have been obvious to one of ordinary skill in the art, before the effective filing date, to modify the installation rules of Melnik to include the identifying security data of Shivamoggi, to manage vulnerabilities. The suggestion/motivation to combine is that it would be obvious to try in order to improve performance by efficiently defending new attacks (Par. 0002 Shivamoggi).
Holzer teaches and determining the state of maintenance availability based on the set of conflicts and the state of deployment (Par. 0053 Holzer discloses the system monitoring components such as deployment models to identify potential error or risk based upon the application definition. The errors or risk are seen as state of deployment. The potential errors or risks are highlighted. Highlighting the errors or risk is seen as an output of a notification).
As to claim 13 Melnik in combination with Fontoura and Holzer teaches each and every limitation of claim 12.
In addition Melnik teaches further comprising: accessing a mapping of deviations from model rules to remedial patterns; and determining, based on the mapping and the difference, a remedial pattern for the first application (Par. 0053 Holzer discloses the system monitoring components such as deployment models to identify potential error or risk based upon the application definition. The errors or risk are seen as state of deployment. The potential errors or risks are highlighted. Highlighting the errors or risk is seen as an output of a notification).
As to claim 14 Melnik in combination with Fontoura and Holzer teaches each and every limitation of claim 12.
In addition Melnik teaches further comprising: determining a set of updates to the set of installation rules associated with the first application based on the difference, wherein the set of updates comprises at least one rule from the one or more model installation rules (Par. 0108 Melnik discloses rules are updated that determine which portions of the source application are allocated to the application packages).
As to claim 18 Melnik in combination with Fontoura and Holzer teaches each and every limitation of claim 15.
In addition Melnik teaches further comprising program code that is executable by the one or more processors for causing the one or more processors to:
access one or more model installation rules associated with a model installation of the first application; compare a set of installation rules associated with the first application with the one or more model installation rules to determine a set of differences between the first application and the model installation of the first application (Par. 0092 Melnik discloses storing the pre-deployment settings. The pre-deployment settings are seen as the installation rules. Par. 0099 Melnik discloses the pre-deployment configuration module defines the parameters that are needed to configure a particular installation. Par. 0117-0118 Melnik discloses using dependency rules to identify conflicts between application package for installation. Fig. 14 and Par. 0127 Melnik discloses each application containing notifications to alert the deployment system of conflict and an option of aborting installation is provided. The notification is seen as the metadata);
Melnik does not teach but Shivamoggi teaches determine a state of deployment for the first application based on the set of differences, wherein the state of deployment comprises a level of potential disruption for the first application (Par. 0037 Shivamoggi discloses vulnerabilities are associated with threats and other items. Par. 0046 Shivamoggi discloses determining that a given cluster is more vulnerable based upon a node. Determining the vulnerability of the given cluster is seen as the state maintenance availability);
Melnik and Shivamoggi are analogous art because they are in the same field of endeavor, transaction processing. It would have been obvious to one of ordinary skill in the art, before the effective filing date, to modify the installation rules of Melnik to include the identifying security data of Shivamoggi, to manage vulnerabilities. The suggestion/motivation to combine is that it would be obvious to try in order to improve performance by efficiently defending new attacks (Par. 0002 Shivamoggi).
Holzer teaches and determine the state of maintenance availability based on the set of conflicts and the state of deployment (Par. 0053 Holzer discloses the system monitoring components such as deployment models to identify potential error or risk based upon the application definition. The errors or risk are seen as state of deployment. The potential errors or risks are highlighted. Highlighting the errors or risk is seen as an output of a notification).
As to claim 19 Melnik in combination with Fontoura and Holzer teaches each and every limitation of claim 18.
In addition Melnik teaches further comprising program code that is executable by the one or more processors for causing the one or more processors to: access a mapping of deviations from model rules to remedial patterns; and determine, based on the mapping and the difference, a remedial pattern for the first application (Par. 0053 Holzer discloses the system monitoring components such as deployment models to identify potential error or risk based upon the application definition. The errors or risk are seen as state of deployment. The potential errors or risks are highlighted. Highlighting the errors or risk is seen as an output of a notification).
As to claim 20 Melnik in combination with Fontoura and Holzer teaches each and every limitation of claim 18.
In addition Melnik teaches further comprising program code that is executable by the one or more processors for causing the one or more processors to determine a set of updates to the set of installation rules associated with the first application based on the set of differences, wherein the set of updates comprises at least one rule from the one or more model installation rules (Par. 0108 Melnik discloses rules are updated that determine which portions of the source application are allocated to the application packages).
Conclusion
10. 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 JERMAINE A MINCEY whose telephone number is (571)270-5010. The examiner can normally be reached 8am EST until 5pm 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, Ann J Lo can be reached at (571) 272-9767. 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.
/J.A.M/ January 26, 2026Examiner, Art Unit 2159