DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on August 8th, 2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
This office action is responsive to response filed on August 8th, 2025. In this office action:
Claims 1-4, 6-11, 13-18, and 20-21 are pending.
Claims 1-4, 6-11, 13-18, and 20-21 are rejected.
Summary of Previous Office Action
In the Non-Final Office Action mailed on May 8th, 2025:
Claims 1, 4, 6, 8, 11-13, 15, and 18-20 were objected because of informalities.
Claims 7 and 14 were rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 1-2, 6-9, 13-16 and 20 were rejected under 35 U.S.C. 103 as being unpatentable over Youssouf et al. (Pub. No. US 2022/0255821), hereinafter Youssouf; in view of Sampath et al. (Pub. No. US 2015/0317194), hereinafter Sampath.
Claims 3-4, 10-11, and 17-18 were rejected under 35 U.S.C. 103 as being unpatentable over Youssouf et al. (Pub. No. US 2022/0255821), hereinafter Youssouf; in view of Sampath et al. (Pub. No. US 2015/0317194), hereinafter Sampath; and further in view of Jindal et al. (Pub. No. US 2022/0229746), hereinafter Jindal.
Claim 5, 12, and 19 were objected to.
Response to Amendment
The amendments filed on August 8th, 2025 have been entered.
Claims 1, 3-4, 6-8, 10-11, 13-15, 17-18, and 20 have been amended.
Claims 5, 12, and 19 have been canceled.
Claim 21 has been added.
The previously raised claim objections for claims 1, 4, 6, 8, 11-13, 15, and 18-20 are withdrawn in light of the amendments.
The previously raised 35 U.S.C. 112(b) rejection for claims 7 and 14 is withdrawn in light of the amendments.
Response to Arguments
Applicant Arguments/Remarks, filed on August 8th, 2025, have been fully considered by the Examiner.
Regarding Applicant’s arguments for the 35 U.S.C. 103 rejection, in pages 11-12/13, that Yousouf and Sampath, whether alone or in combination, have not been shown to teach or suggest each and every element of the amended claims as required by law.
In response, the Examiner respectfully disagrees.
The Examiner notes that Applicant’s amendments change the scope of the claim(s), and the amended claim(s) necessitate new grounds of rejection, as presented in this Office Action (See Claim Rejections - 35 USC § 103 section below).
Regarding the limitation “ ... in response to receiving the notification, activatingthe load balancer monitor of the first entity, wherein the execution plan comprises steps to be performed by the load balancer monitor to distribute requests sent to the first entity to the second entity registered at the load balancer monitor” argued by the Applicant (See page 11/13), and in response to Applicant’s argument that “The Office Action at page 6 acknowledges that Yousouf does not disclose the limitation that relates to "an execution plan" and instead relies on a portion of Sampath to allege that Sampath discloses "an execution plan," the Examiner notes that Applicant’s amendments change the scope of the limitation above; and the limitation above is now rejected over Youssouf et al. (Pub. No. US 2022/0255821) as presented in this Office Action (See Claim Rejections - 35 USC § 103 section below).
Claim Objections
Claims 1, 8, and 15 are objected to because of the following informalities:
“... wherein the selection of the flag is received to trigger a recovery for the first entity ...” should read (Examiner’s suggestion) “... wherein the notification for the selection of the flag is received to trigger a recovery for the first entity ...”
“... executing, by the load balancer monitor, the generated execution plan to reconfigure communication flows at the cloud platform associated with the first entity so that requests sent to the first entity are distributed to the second entity to perform the recovery ...” should read (Examiner’s suggestion) “... executing, by the load balancer monitor, the generated execution plan to reconfigure communication flows at the cloud platform associated with the first entity so that the requests sent to the first entity are distributed to the second entity to perform the recovery ...”
Claims 7, 14, and 21 are objected to because of the following informalities:
“... wherein each type of a cloud component is associated with instances of the respective type that each run at a respective zone of the multiple availability zones” should read (Examiner’s suggestion) “... wherein each type of a cloud component is associated with instances of [[a respective component type that each run at a respective zone of the multiple availability zones”
Appropriate correction(s) is/are required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 11 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 11 recites the term “the entity” in "sending an instruction by the central service and to a second load balancer defined for the cloud platform to restrict network access to the entity at the first zone" and “reconfiguring previously defined communication flow towards the entity ...” The term “the entity” has never been introduced in the instant claim or in claims 8 and 10 on which the instant claim depends. Therefore, there is insufficient antecedent basis for this limitation in the claim.
For the purpose of examination, the Examiner interprets the claim as:
“ ... sending an instruction by the central service and to a second load balancer defined for the cloud platform to restrict network access to the second set of entities [[
reconfiguring previously defined communication flow towards the second set of entities [[set of entities [[
terminating execution of the second set of entities at the first zone and activating execution of [[the corresponding set of entities to the second set of entities at the second zone of the cloud platform.”
Examiner’s note: The Examiner’s interpretation is based on claims 4 and 18.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 3-4, 8, 10-11, 15, and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Yousouf et al. (Pub. No. US 2022/0255821), hereinafter Youssouf; in view of Jindal et al. (Pub. No. US 2022/0229746), hereinafter Jindal.
Claim 1. Yousouf discloses [a] computer-implemented method, comprising:
creating, by a first load balancer of a cloud platform including multiple availability zones (See Parag. [0105]; cloud platform 210 is defined with multiple availability zones), a load balancer monitor for monitoring a health status of a first entity of a first type (See Parag. [0107]; a consumer (e.g., a platform service) (first load balancer) that is interested in information about the health status of the cloud platform 210 and/or when an outage is detected can be duly notified by the health service 220. See Parag. [0216]; the consumer can request to be subscribed for notifications of changes of the health status; the customer can register to receive notifications (creating a load balancer monitor for monitoring a health status). See Parag. [0029]; the consumer may be an application management service running on the cloud platform and managing workload and processing of requests by different applications and services (load balancer). See Parag. [0139]; the application management service requests a health status of network connectivity of the cloud platform that includes a health status of the application segment (first entity of a first type) part of the cloud platform. See Parag. [0140]; the requests sent from the application management service may be sent automatically and in a preconfigured periodic manner … See also Parag. [0131]. Examiner’s interpretation: The Examiner reasonably interprets the consumer, which manages workload and processing of requests by different applications, as a load balancer. In addition, the Examiner reasonably interprets the consumer registering/subscribing to periodically receive the health status, as equivalent to creating, by the consumer, a balancer monitor for monitoring a health status), wherein the first entity is running at a first zone at the cloud platform (See Parag. [0162]; The first cloud platform includes the network segments that are correspondingly defined for the plurality of availability zones of the first cloud platform. For example, every availability zone of the first cloud platform has a core segment, a service segment, an application segment, and a database segment. See Parag. [0174]; based on determining the health status, a network outage at a network segment from the network segments of at least one of the plurality of availability zones can be identified Examiner’s interpretation: The Examiner reasonably interprets “application segment” as the first entity of a first type, where the application segment is running at one availability zone (a first zone at the cloud platform));
receiving, at the load balancer monitor, a notification for a selection of a flag from a set of flags defined at the cloud platform (See Parag. [0139-0140]; the requests sent from the application management service may be sent automatically and in a preconfigured periodic manner (i.e., time periods) … the application management service receives the current health status (flag) of the application network segment for the network connectivity of the cloud platform. See Parag. [0125]; identify corresponding statuses (set of flags) for different network segments of the cloud platform; the health status may include an inbound connectivity status for the application segment, an outbound connectivity status for the application segment, and an internal status for the application segment; Based on determining the health status for the application segment, a health status of an application running in the application segment can be determined as corresponding to the health status of the application segments … See Parag. [0216]; the customer (i.e., application management service) can register to receive notifications. See Parag. [0036]; The notification to the registered application can be provided to include the determined current health status. See also Parag. [0131]. Examiner’s interpretation: The Examiner reasonably interprets a selection of a flag from a set of flags as determining a health status from a plurality of statuses), wherein the selection of the flag is received to trigger a recovery for the first entity, the first entity being mapped to the flag (See Parag. [0175]; based on the determined health status and the collected structured data, an outage can be identified as associated with a particular segment of the segments of an availability zone of the cloud platform … in response to determining that there is an outage, a particular or corresponding scope of the outage can be determined. The scope of the outage can define limited network segments from the cloud platform for outbound and inbound connections. In response to evaluating the scope of the outage, an outage status level can be determined. The outage status level can be determined from a predefined set of levels ... in response to determining the outage status level, corresponding actions for an entity running on the cloud platform that is affected by the outage can be determined. The actions can include countermeasures related to the execution of the entity to provide services by the entities affected by the outage. Examiner’s interpretation: The determined status (flag) triggers actions (e.g., countermeasures) for recovery);
in response to receiving the notification, activating the load balancer monitor to generate an execution plan for the recovery of the first entity, wherein the execution plan comprises steps to be performed by the load balancer monitor to distribute requests sent to the first entity to the second entity (See Parag. [0132]; the consumer may include logic to evaluate the received data about the health status (receiving the notification) of the cloud platform and provide information for changes in the health status to relevant entities in the cloud platform and/or to an orchestrator service, which, for example, may provide instructions for affected entities to stop execution and offload service requests to other instances (second entity) running at a different network segment or at a different region or zone (distribute requests sent to the first entity to the second entity) where network outages are not limiting the services. See Parag. [0087-0089] [0139-0141] [0158] [0173]); and
executing, by the load balancer monitor, the generated execution plan to reconfigure communication flows at the cloud platform associated with the first entity so that requests sent to the first entity are distributed to the second entity to perform the recovery (See Parag. [0132]; the consumer may include logic to evaluate the received data about the health status of the cloud platform and provide information for changes in the health status to relevant entities in the cloud platform and/or to an orchestrator service, which, for example, may provide instructions for affected entities to stop execution and offload service requests (communication flows) to other instances (second entity) running at a different network segment or at a different region or zone where network outages are not limiting the services (reconfigure communication flows at the cloud platform). See Parag. [0158]; a failover process can activate a secondary instance(s) in one of the remaining AZ(s) for an application instance in an AZ having an “AZ Down” outage status. By activating the secondary instance, the cloud platform can continue to function without the downtime reflecting on the service level of the cloud platform. See also Parag. [0129] [0135-0140] [0177]).
Yousouf further disclose a second entity corresponding to the first entity and running at a second zone at the cloud platform (See Parag. [0173]; The internal zone accessibility status is related to connections between entities running at a network segment of the network segments of a first zone from the plurality of availability zones and entities running at a network segment of the network segments of a second zone of the plurality of availability zones of the first cloud platform. For example, the status may be between entities running in the application segments at two availability zones. See Parag. [0141]; the cloud platform that hosts the applications may be defined in multiple availability zones (AZs) that are located at different locations. In such instances, if a network disruption is experienced at one availability zone, another availability zone may be unaffected and proceed to provide services; an application that is deployed in a multiple availability zone cloud platform may be deployed to have separate instances of the application running at different availability zones. See also Parag. [0087-0089] [0132] [0158] [0173]); but Yousouf doesn’t explicitly disclose registering, at the load balancer monitor, [the] second entity corresponding to the first entity and running at a second zone at the cloud platform; [and] the second entity registered at the load balancer monitor.
However, Jindal discloses registering, at the load balancer monitor, a second entity corresponding to the first entity and running at a second zone at the cloud platform; [and] the second entity registered at the load balancer monitor (See Parag. [0037]; an orchestrator module 106 (the load balancer monitor) can interact with any one or more of a set of primary site entities 108 (e.g., the shown entities E1 and E2) (first entity) and any one or more of a set of secondary site entities 110 (e.g., the shown entities E3 and E4) (a second entity corresponding to the first entity and running at a second zone) that are configured to interact in disaster recovery scenarios … (see the Example in Parag. [0060]). See Parag. [0071]; the replacement entity selection module 107 (i.e., within the orchestrator module 106, See Fig. 1C) may ingest deployment information from any/all of either or both of the primary site entities and the secondary site entities … See Parag. [0031]; An orchestrator module monitors (the load balancer monitor) the various clusters pertaining to the recovery plans. Upon detection of a possible failure, the orchestrator module will use a particular witness service to arbitrate for a leader cluster/node according to the terms of any applicable recovery plan. See Parag. [0032] [0066]; “cloud platform.” See Parag. [0090]; any individual disaster recovery plan may specify one or more of, an “Availability Zone”, an “Entity Type” or a “Compound Type” … The fields and values can be stored in a manner so as to make them individually accessible. See also Parag. [0031] [0069-0070] [0077-0078] [0083] [0090] [0097-0098] [0102] [0118-0127], Fig. 1, and Fig. 2B2. Examiner’s interpretation: The Examiner reasonably interprets the replacement entity selection module 107 (i.e., within the orchestrator module 106) (the load balancer monitor) that ingest deployment information from the primary site entities and the secondary site entities (a second entity) to be equivalent to registering, at the load balancer monitor, a second entity corresponding to the first entity and running at a second zone).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the consumer/application management service running on the cloud platform for managing workload and processing of requests by different applications and services, taught by Yousouf, to registering a second entity corresponding to the first entity and running at a second zone at the cloud platform, as taught by Jindal. This would be convenient to provide high availability computing architectures, and more particularly for selecting a witness service when implementing a recovery plan (Jindal, Parag. [0002]).
Claim 3. Yousouf in view of Jindal discloses [t]he method of claim 1,
Yousouf discloses the method further comprising: configuring a second set of entities of a second type of entities for recovery at a central service to manage outages associated with the second type of entities at the cloud platform (See Parag. [0132]; the consumer (platform service, See Parag. [0107]) (central service) may include logic to evaluate the received data about the health status of the cloud platform and provide information for changes in the health status to relevant entities (a second set of entities) in the cloud platform and/or to an orchestrator service, which, for example, may provide instructions for affected entities (configuring second set of entities) to stop execution and offload service requests to other instances running at a different network segment or at a different region or zone where network outages are not limiting the services. See also Parag. [0092]; the cloud platform includes multiple segments including a core segment 221, a services segment 225, a database (DB) segment 230, and an applications segment 235. The segments part of the cloud platform are network segments that are associated with entities of different type running at the cloud platform. See Parag. [0124]; entities are installed and run at each of the plurality of network segments … See also Parag. [0141] [0158] [0173]. Examiner’s interpretation: Yousouf teaches that the cloud platform includes different network segments that are associated with entities of different type (including second set of entities of a second type of entities), and when entity/entities (in this case: second set of entities) are associated with outage(s) (e.g., at a first zone) other entities (e.g., at another zone) are configured to take over for recovery).
Claim 4. Yousouf in view of Jindal discloses [t]he method of claim 3,
Yousouf further discloses:
sending an instruction by the central service and to a second load balancer defined for the cloud platform to restrict network access to the second set of entities at the first zone (See Parag. [0132]; the consumer (platform service, See Parag. [0107]) (the central service) may include logic to evaluate the received data about the health status of the cloud platform and provide information for changes in the health status to relevant entities in the cloud platform and/or to an orchestrator service (a second load balancer), which, for example, may provide instructions for affected entities (the second set of entities) to stop execution and offload service requests to other instances running at a different region or zone where network outages are not limiting the services. See also Parag. [0079] [0129]. Examiner’s interpretation: The Examiner reasonably interprets “restrict network access to the second set of entities at the first zone” as providing instructions (orchestrator service) for the affected entities (i.e., at a first zone) to stop execution (i.e., orchestrator service performs load balancing));
reconfiguring previously defined communication flow towards the second set of entities to a corresponding set of entities at the second zone of the cloud platform (See Parag. [0132]; provide instructions for affected entities (the second set of entities) to stop execution and offload service requests (reconfiguring previously defined communication flow) to other instances (a corresponding set of entities) running at a different region or zone where network outages are not limiting the services. See also Parag. [0158]); and
terminating execution of the second set of entities at the first zone and activating execution of the corresponding set of entities to the second set of entities at the second zone of the cloud platform (See Parag. [0132]; provide instructions for affected entities to stop execution (terminating execution of the second set of entities at the first zone) and offload service requests to other instances (the corresponding set of entities) running at a different region or zone where network outages are not limiting the services (activating execution of the corresponding set of entities to the second set of entities at the second zone of the cloud platform). See also Parag. [0158]; a failover process can activate a secondary instance(s) in one of the remaining AZ(s) for an application instance in an AZ having an “AZ Down” outage status).
Claim 8. Yousouf discloses [a] system comprising:
one or more processors; and one or more computer-readable memories coupled to the one or more processors and having instructions stored thereon that are executable by the one or more processors to perform operations (See Parag. [0054]; a system comprising at least one process and a memory communicatively coupled to the at least one processor where the memory stores instructions that when executed cause the at least one processor to perform the operations) comprising:
creating, by a first load balancer of a cloud platform including multiple availability zones (See Parag. [0105]; cloud platform 210 is defined with multiple availability zones), a load balancer monitor for monitoring a health status of a first entity of a first type (See Parag. [0107]; a consumer (e.g., a platform service) (first load balancer) that is interested in information about the health status of the cloud platform 210 and/or when an outage is detected can be duly notified by the health service 220. See Parag. [0216]; the consumer can request to be subscribed for notifications of changes of the health status; the customer can register to receive notifications (creating a load balancer monitor for monitoring a health status). See Parag. [0029]; the consumer may be an application management service running on the cloud platform and managing workload and processing of requests by different applications and services (load balancer). See Parag. [0139]; the application management service requests a health status of network connectivity of the cloud platform that includes a health status of the application segment (first entity of a first type) part of the cloud platform. See Parag. [0140]; the requests sent from the application management service may be sent automatically and in a preconfigured periodic manner … See also Parag. [0131]. Examiner’s interpretation: The Examiner reasonably interprets the consumer, which manages workload and processing of requests by different applications, as a load balancer. In addition, the Examiner reasonably interprets the consumer registering/subscribing to periodically receive the health status, as equivalent to creating, by the consumer, a balancer monitor for monitoring a health status), wherein the first entity is running at a first zone at the cloud platform (See Parag. [0162]; The first cloud platform includes the network segments that are correspondingly defined for the plurality of availability zones of the first cloud platform. For example, every availability zone of the first cloud platform has a core segment, a service segment, an application segment, and a database segment. See Parag. [0174]; based on determining the health status, a network outage at a network segment from the network segments of at least one of the plurality of availability zones can be identified Examiner’s interpretation: The Examiner reasonably interprets “application segment” as the first entity of a first type, where the application segment is running at one availability zone (a first zone at the cloud platform));
receiving, at the load balancer monitor, a notification for a selection of a flag from a set of flags defined at the cloud platform (See Parag. [0139-0140]; the requests sent from the application management service may be sent automatically and in a preconfigured periodic manner (i.e., time periods) … the application management service receives the current health status (flag) of the application network segment for the network connectivity of the cloud platform. See Parag. [0125]; identify corresponding statuses (set of flags) for different network segments of the cloud platform; the health status may include an inbound connectivity status for the application segment, an outbound connectivity status for the application segment, and an internal status for the application segment; Based on determining the health status for the application segment, a health status of an application running in the application segment can be determined as corresponding to the health status of the application segments … See Parag. [0216]; the customer (i.e., application management service) can register to receive notifications. See Parag. [0036]; The notification to the registered application can be provided to include the determined current health status. See also Parag. [0131]. Examiner’s interpretation: The Examiner reasonably interprets a selection of a flag from a set of flags as determining a health status from a plurality of statuses), wherein the selection of the flag is received to trigger a recovery for the first entity, the first entity being mapped to the flag (See Parag. [0175]; based on the determined health status and the collected structured data, an outage can be identified as associated with a particular segment of the segments of an availability zone of the cloud platform … in response to determining that there is an outage, a particular or corresponding scope of the outage can be determined. The scope of the outage can define limited network segments from the cloud platform for outbound and inbound connections. In response to evaluating the scope of the outage, an outage status level can be determined. The outage status level can be determined from a predefined set of levels ... in response to determining the outage status level, corresponding actions for an entity running on the cloud platform that is affected by the outage can be determined. The actions can include countermeasures related to the execution of the entity to provide services by the entities affected by the outage. Examiner’s interpretation: The determined status (flag) triggers actions (e.g., countermeasures) for recovery);
in response to receiving the notification, activating the load balancer monitor to generate an execution plan for the recovery of the first entity, wherein the execution plan comprises steps to be performed by the load balancer monitor to distribute requests sent to the first entity to the second entity (See Parag. [0132]; the consumer may include logic to evaluate the received data about the health status (receiving the notification) of the cloud platform and provide information for changes in the health status to relevant entities in the cloud platform and/or to an orchestrator service, which, for example, may provide instructions for affected entities to stop execution and offload service requests to other instances (second entity) running at a different network segment or at a different region or zone (distribute requests sent to the first entity to the second entity) where network outages are not limiting the services. See Parag. [0087-0089] [0139-0141] [0158] [0173]); and
executing, by the load balancer monitor, the generated execution plan to reconfigure communication flows at the cloud platform associated with the first entity so that requests sent to the first entity are distributed to the second entity to perform the recovery (See Parag. [0132]; the consumer may include logic to evaluate the received data about the health status of the cloud platform and provide information for changes in the health status to relevant entities in the cloud platform and/or to an orchestrator service, which, for example, may provide instructions for affected entities to stop execution and offload service requests (communication flows) to other instances (second entity) running at a different network segment or at a different region or zone where network outages are not limiting the services (reconfigure communication flows at the cloud platform). See Parag. [0158]; a failover process can activate a secondary instance(s) in one of the remaining AZ(s) for an application instance in an AZ having an “AZ Down” outage status. By activating the secondary instance, the cloud platform can continue to function without the downtime reflecting on the service level of the cloud platform. See also Parag. [0129] [0135-0140] [0177]).
Yousouf further disclose a second entity corresponding to the first entity and running at a second zone at the cloud platform (See Parag. [0173]; The internal zone accessibility status is related to connections between entities running at a network segment of the network segments of a first zone from the plurality of availability zones and entities running at a network segment of the network segments of a second zone of the plurality of availability zones of the first cloud platform. For example, the status may be between entities running in the application segments at two availability zones. See Parag. [0141]; the cloud platform that hosts the applications may be defined in multiple availability zones (AZs) that are located at different locations. In such instances, if a network disruption is experienced at one availability zone, another availability zone may be unaffected and proceed to provide services; an application that is deployed in a multiple availability zone cloud platform may be deployed to have separate instances of the application running at different availability zones. See also Parag. [0087-0089] [0132] [0158] [0173]); but Yousouf doesn’t explicitly disclose registering, at the load balancer monitor, [the] second entity corresponding to the first entity and running at a second zone at the cloud platform; [and] the second entity registered at the load balancer monitor.
However, Jindal discloses registering, at the load balancer monitor, a second entity corresponding to the first entity and running at a second zone at the cloud platform; [and] the second entity registered at the load balancer monitor (See Parag. [0037]; an orchestrator module 106 (the load balancer monitor) can interact with any one or more of a set of primary site entities 108 (e.g., the shown entities E1 and E2) (first entity) and any one or more of a set of secondary site entities 110 (e.g., the shown entities E3 and E4) (a second entity corresponding to the first entity and running at a second zone) that are configured to interact in disaster recovery scenarios … (see the Example in Parag. [0060]). See Parag. [0071]; the replacement entity selection module 107 (i.e., within the orchestrator module 106, See Fig. 1C) may ingest deployment information from any/all of either or both of the primary site entities and the secondary site entities … See Parag. [0031]; An orchestrator module monitors (the load balancer monitor) the various clusters pertaining to the recovery plans. Upon detection of a possible failure, the orchestrator module will use a particular witness service to arbitrate for a leader cluster/node according to the terms of any applicable recovery plan. See Parag. [0032] [0066]; “cloud platform.” See Parag. [0090]; any individual disaster recovery plan may specify one or more of, an “Availability Zone”, an “Entity Type” or a “Compound Type” … The fields and values can be stored in a manner so as to make them individually accessible. See also Parag. [0031] [0069-0070] [0077-0078] [0083] [0090] [0097-0098] [0102] [0118-0127], Fig. 1, and Fig. 2B2. Examiner’s interpretation: The Examiner reasonably interprets the replacement entity selection module 107 (i.e., within the orchestrator module 106) (the load balancer monitor) that ingest deployment information from the primary site entities and the secondary site entities (a second entity) to be equivalent to registering, at the load balancer monitor, a second entity corresponding to the first entity and running at a second zone).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the consumer/application management service running on the cloud platform for managing workload and processing of requests by different applications and services, taught by Yousouf, to registering a second entity corresponding to the first entity and running at a second zone at the cloud platform, as taught by Jindal. This would be convenient to provide high availability computing architectures, and more particularly for selecting a witness service when implementing a recovery plan (Jindal, Parag. [0002]).
Claim 10 is taught by Yousouf in view of Jindal as described for claim 3.
Claim 11 is taught by Yousouf in view of Jindal as described for claim 4.
Claim 15. Youssouf discloses [a] non-transitory, computer-readable medium coupled to one or more processors and having instructions stored thereon which, when executed by the one or more processors, cause the one or more processors to perform operations (See Parag. [0054]; a non-transitory computer-readable medium storing instructions which, when executed, cause at least one processor to perform the operations) comprising:
creating, by a first load balancer of a cloud platform including multiple availability zones (See Parag. [0105]; cloud platform 210 is defined with multiple availability zones), a load balancer monitor for monitoring a health status of a first entity of a first type (See Parag. [0107]; a consumer (e.g., a platform service) (first load balancer) that is interested in information about the health status of the cloud platform 210 and/or when an outage is detected can be duly notified by the health service 220. See Parag. [0216]; the consumer can request to be subscribed for notifications of changes of the health status; the customer can register to receive notifications (creating a load balancer monitor for monitoring a health status). See Parag. [0029]; the consumer may be an application management service running on the cloud platform and managing workload and processing of requests by different applications and services (load balancer). See Parag. [0139]; the application management service requests a health status of network connectivity of the cloud platform that includes a health status of the application segment (first entity of a first type) part of the cloud platform. See Parag. [0140]; the requests sent from the application management service may be sent automatically and in a preconfigured periodic manner … See also Parag. [0131]. Examiner’s interpretation: The Examiner reasonably interprets the consumer, which manages workload and processing of requests by different applications, as a load balancer. In addition, the Examiner reasonably interprets the consumer registering/subscribing to periodically receive the health status, as equivalent to creating, by the consumer, a balancer monitor for monitoring a health status), wherein the first entity is running at a first zone at the cloud platform (See Parag. [0162]; The first cloud platform includes the network segments that are correspondingly defined for the plurality of availability zones of the first cloud platform. For example, every availability zone of the first cloud platform has a core segment, a service segment, an application segment, and a database segment. See Parag. [0174]; based on determining the health status, a network outage at a network segment from the network segments of at least one of the plurality of availability zones can be identified Examiner’s interpretation: The Examiner reasonably interprets “application segment” as the first entity of a first type, where the application segment is running at one availability zone (a first zone at the cloud platform));
receiving, at the load balancer monitor, a notification for a selection of a flag from a set of flags defined at the cloud platform (See Parag. [0139-0140]; the requests sent from the application management service may be sent automatically and in a preconfigured periodic manner (i.e., time periods) … the application management service receives the current health status (flag) of the application network segment for the network connectivity of the cloud platform. See Parag. [0125]; identify corresponding statuses (set of flags) for different network segments of the cloud platform; the health status may include an inbound connectivity status for the application segment, an outbound connectivity status for the application segment, and an internal status for the application segment; Based on determining the health status for the application segment, a health status of an application running in the application segment can be determined as corresponding to the health status of the application segments … See Parag. [0216]; the customer (i.e., application management service) can register to receive notifications. See Parag. [0036]; The notification to the registered application can be provided to include the determined current health status. See also Parag. [0131]. Examiner’s interpretation: The Examiner reasonably interprets a selection of a flag from a set of flags as determining a health status from a plurality of statuses), wherein the selection of the flag is received to trigger a recovery for the first entity, the first entity being mapped to the flag (See Parag. [0175]; based on the determined health status and the collected structured data, an outage can be identified as associated with a particular segment of the segments of an availability zone of the cloud platform … in response to determining that there is an outage, a particular or corresponding scope of the outage can be determined. The scope of the outage can define limited network segments from the cloud platform for outbound and inbound connections. In response to evaluating the scope of the outage, an outage status level can be determined. The outage status level can be determined from a predefined set of levels ... in response to determining the outage status level, corresponding actions for an entity running on the cloud platform that is affected by the outage can be determined. The actions can include countermeasures related to the execution of the entity to provide services by the entities affected by the outage. Examiner’s interpretation: The determined status (flag) triggers actions (e.g., countermeasures) for recovery);
in response to receiving the notification, activating the load balancer monitor to generate an execution plan for the recovery of the first entity, wherein the execution plan comprises steps to be performed by the load balancer monitor to distribute requests sent to the first entity to the second entity (See Parag. [0132]; the consumer may include logic to evaluate the received data about the health status (receiving the notification) of the cloud platform and provide information for changes in the health status to relevant entities in the cloud platform and/or to an orchestrator service, which, for example, may provide instructions for affected entities to stop execution and offload service requests to other instances (second entity) running at a different network segment or at a different region or zone (distribute requests sent to the first entity to the second entity) where network outages are not limiting the services. See Parag. [0087-0089] [0139-0141] [0158] [0173]); and
executing, by the load balancer monitor, the generated execution plan to reconfigure communication flows at the cloud platform associated with the first entity so that requests sent to the first entity are distributed to the second entity to perform the recovery (See Parag. [0132]; the consumer may include logic to evaluate the received data about the health status of the cloud platform and provide information for changes in the health status to relevant entities in the cloud platform and/or to an orchestrator service, which, for example, may provide instructions for affected entities to stop execution and offload service requests (communication flows) to other instances (second entity) running at a different network segment or at a different region or zone where network outages are not limiting the services (reconfigure communication flows at the cloud platform). See Parag. [0158]; a failover process can activate a secondary instance(s) in one of the remaining AZ(s) for an application instance in an AZ having an “AZ Down” outage status. By activating the secondary instance, the cloud platform can continue to function without the downtime reflecting on the service level of the cloud platform. See also Parag. [0129] [0135-0140] [0177]).
Yousouf further disclose a second entity corresponding to the first entity and running at a second zone at the cloud platform (See Parag. [0173]; The internal zone accessibility status is related to connections between entities running at a network segment of the network segments of a first zone from the plurality of availability zones and entities running at a network segment of the network segments of a second zone of the plurality of availability zones of the first cloud platform. For example, the status may be between entities running in the application segments at two availability zones. See Parag. [0141]; the cloud platform that hosts the applications may be defined in multiple availability zones (AZs) that are located at different locations. In such instances, if a network disruption is experienced at one availability zone, another availability zone may be unaffected and proceed to provide services; an application that is deployed in a multiple availability zone cloud platform may be deployed to have separate instances of the application running at different availability zones. See also Parag. [0087-0089] [0132] [0158] [0173]); but Yousouf doesn’t explicitly disclose registering, at the load balancer monitor, [the] second entity corresponding to the first entity and running at a second zone at the cloud platform; [and] the second entity registered at the load balancer monitor.
However, Jindal discloses registering, at the load balancer monitor, a second entity corresponding to the first entity and running at a second zone at the cloud platform; [and] the second entity registered at the load balancer monitor (See Parag. [0037]; an orchestrator module 106 (the load balancer monitor) can interact with any one or more of a set of primary site entities 108 (e.g., the shown entities E1 and E2) (first entity) and any one or more of a set of secondary site entities 110 (e.g., the shown entities E3 and E4) (a second entity corresponding to the first entity and running at a second zone) that are configured to interact in disaster recovery scenarios … (see the Example in Parag. [0060]). See Parag. [0071]; the replacement entity selection module 107 (i.e., within the orchestrator module 106, See Fig. 1C) may ingest deployment information from any/all of either or both of the primary site entities and the secondary site entities … See Parag. [0031]; An orchestrator module monitors (the load balancer monitor) the various clusters pertaining to the recovery plans. Upon detection of a possible failure, the orchestrator module will use a particular witness service to arbitrate for a leader cluster/node according to the terms of any applicable recovery plan. See Parag. [0032] [0066]; “cloud platform.” See Parag. [0090]; any individual disaster recovery plan may specify one or more of, an “Availability Zone”, an “Entity Type” or a “Compound Type” … The fields and values can be stored in a manner so as to make them individually accessible. See also Parag. [0031] [0069-0070] [0077-0078] [0083] [0090] [0097-0098] [0102] [0118-0127], Fig. 1, and Fig. 2B2. Examiner’s interpretation: The Examiner reasonably interprets the replacement entity selection module 107 (i.e., within the orchestrator module 106) (the load balancer monitor) that ingest deployment information from the primary site entities and the secondary site entities (a second entity) to be equivalent to registering, at the load balancer monitor, a second entity corresponding to the first entity and running at a second zone).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the consumer/application management service running on the cloud platform for managing workload and processing of requests by different applications and services, taught by Yousouf, to registering a second entity corresponding to the first entity and running at a second zone at the cloud platform, as taught by Jindal. This would be convenient to provide high availability computing architectures, and more particularly for selecting a witness service when implementing a recovery plan (Jindal, Parag. [0002]).
Claim 17 is taught by Yousouf in view of Jindal as described for claim 3.
Claim 18 is taught by Yousouf in view of Jindal as described for claim 4.
Claims 2, 6-7, 9, 13-14, 16, and 20-21 are rejected under 35 U.S.C. 103 as being unpatentable over Yousouf et al. (Pub. No. US 2022/0255821), hereinafter Youssouf; in view of Jindal et al. (Pub. No. US 2022/0229746), hereinafter Jindal; and further in view of Kothari et al. (Pub. No. US 2022/0091947), hereinafter Kothari.
Claim 2. Yousouf in view of Jindal discloses [t]he method of claim 1,
Yousouf further discloses wherein the flag is selected to identify an outage at the cloud platform (See Parag. [0175]; based on the determined health status (flag) and the collected structured data, an outage can be identified as associated with a particular segment of the segments of an availability zone of the cloud platform. See also Parag. [0139-0140]).
Yousouf in view of Jindal doesn’t explicitly disclose wherein each flag of the set of flags is mapped to an entity from entities defined for the cloud platform.
However, Kothari discloses wherein each flag of the set of flags is mapped to an entity from entities defined for the cloud platform (See Parag. [0075]; GUI may include an application status dashboard that shows a visual indication of a status of each application (an entity from entities), e.g., a green colored indication indicative of an operational or nominal status, a yellow colored indication indicative of one or relatively minor (e.g., non-critical) issues or incidents, and a red colored indication indicative of one or more critical issues or incidents … See Parag. [0007]; determining one or more cross-regional dependencies and traffic flow of an application in a first region of a cloud environment, wherein the one or more cross-regional dependencies include a dependency of the application in the first region of the cloud environment to one or more applications in at least one other region of the cloud environment … Examiner’s interpretation: The Examiner interprets each flag of the set of flags as each colored indication status of the set of colored indications statuses for applications (entities)).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify health statuses (flags), taught by Yousouf in view of Jindal, such that each flag of the set of flags is mapped to an entity from entities defined for the cloud platform, as taught by Kothari. This would be convenient to performing an extreme technical recovery exercise on a cloud infrastructure (Kothari, Parag. [0006]).
Claim 6. Yousouf in view of Jindal and Kothari discloses [t]he method of claim 2,
Yousouf further discloses wherein the entity is defined as one of: a zone segment of the cloud platform, a cloud component running at a segment of a zone of the cloud platform, a zone of the multiple availability zones of the cloud platform, or a load balancer defined for multiple zones of the cloud platform (See Parag. [0162]; The first cloud platform includes the network segments that are correspondingly defined for the plurality of availability zones of the first cloud platform. For example, every availability zone of the first cloud platform has a core segment, a service segment, an application segment, and a database segment (a zone segment of the cloud platform). See Parag. [0141] [0175-0177] and See also Fig. 7).
Claim 7. Yousouf in view of Jindal and Kothari discloses [t]he method of claim 2,
Yousouf further discloses wherein the entities defined for the cloud platform include different cloud component types including applications, services, and databases (See Parag. [0092]; The segments part of the cloud platform are network segments that are associated with entities of different type running at the cloud platform. See Parag. [0141]; A cloud platform with a multiple availability zones (AZs) cloud platform architecture may be configured to provide proper synchronization between entities (e.g., services, applications, and databases) distributed at different AZs), wherein each type of a cloud component is associated with instances of the respective type that each run at a respective zone of the multiple availability zones (See Parag. [0141]; an application that is deployed in a multiple availability zone cloud platform may be deployed to have separate instances of the application running at different availability zones. The multiple availability zone cloud architecture of a cloud platform may be a hidden implementation such that it cannot be seen by or determined by an end-user of an application. A cloud platform with a multiple availability zones cloud platform architecture may be configured to provide proper synchronization between entities (e.g., services, applications, and databases) distributed at different AZs. In those cases, when one of the AZs becomes inaccessible (e.g., because of a network outage or because of another reason), the entities that are associated to those entities running in the inaccessible AZ can continue to function undisturbed in another AZ that is still accessible. See Parag. [0154]; the entity may be a database that runs with multiple instances at different AZs. See also Parag. [0132] [0170] [0276]).
Claim 9 is taught by Yousouf in view of Jindal and Kothari as described for claim 2.
Claim 13 is taught by Yousouf in view of Jindal and Kothari as described for claim 6.
Claim 14 is taught by Yousouf in view of Jindal and Kothari as described for claim 7.
Claim 16 is taught by Yousouf in view of Jindal and Kothari as described for claim 2.
Claim 20 is taught by Yousouf in view of Jindal and Kothari as described for claim 6.
Claim 21 is taught by Yousouf in view of Jindal and Kothari as described for claim 7.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Benjamin et al. (Pub. No. US 2021/0311655) – Related art in the area of performance control in a cloud computing environment, (Abstract; System and method for performance control in a cloud computing environment uses dependency hierarchy between software entities executing in the cloud computing environment and operational status of each of the software entities executing in the cloud computing environment. Using the dependency hierarchy between the software entities and the operational status of each of the software entities, a scaling operation is performed to the virtual computing instances such that a service-level objective (SLO) of the cloud computing environment satisfies a predetermined threshold).
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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABDELBASST TALIOUA whose telephone number is (571)272-4061. The examiner can normally be reached on Monday-Thursday 7:30 am - 5:30 pm.
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, Oscar Louie can be reached on 571-270-1684. 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 https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Abdelbasst Talioua/Examiner, Art Unit 2445