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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on March 24th, 2026 has been entered.
In this office action:
Claims 1-20 are pending.
Claims 1-20 are rejected.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on May 27th, 2026 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Summary of Previous Office Action
In the Final Office Action mailed on December 29th, 2025:
Claims 5-7 and 16 were objected because of informalities.
Claims 1-20 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-9 and 12-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 Kothari et al. (Pub. No. US 2022/0091947), hereinafter Kothari.
Claim 10 was rejected under 35 U.S.C. 103 as being unpatentable over Youssouf et al. (Pub. No. US 2022/0255821), hereinafter Youssouf; in view of Kothari et al. (Pub. No. US 2022/0091947), hereinafter Kothari; and further in view of Gao et al. (Pub. No. US 2023/0048513), hereinafter Gao.
Claim 11 was rejected under 35 U.S.C. 103 as being unpatentable over Youssouf et al. (Pub. No. US 2022/0255821), hereinafter Youssouf; in view of Kothari et al. (Pub. No. US 2022/0091947), hereinafter Kothari; and further in view of Sampath et al. (Pub. No. US 2015/0317194), hereinafter Sampath.
Response to Amendment
The amendments filed on March 24th, 2026 have been entered.
Claims 1, 5-7, 12, and 16-17 have been amended.
The previously raised claim objections are withdrawn for claims 5-7 and 16 in light of the amendments.
The previously raised 35 U.S.C. 112(b) rejections are withdrawn for claims 1-20 in light of the amendments.
Response to Arguments
Applicant Arguments/Remarks regarding Claim Rejection – 35 U.S.C. 103, filed on March 24th, 2026, have been fully considered by the Examiner, but are not persuasive.
Applicant’s argument:
The Applicant argues the following (Applicant Arguments/Remarks; Pages 1-3):
Applicant respectfully submits that, the cited reference has not been shown to teach or suggest "determining one or more entities ... for the cloud platform associated with recovering the outage at the first segment, the first segment corresponding to the selected flag" as recited in claim 1.
Further, Youssouf has not been shown to teach or suggest "identifying other instances of the applications corresponding to the determined instances of the applications running at the first segment, wherein the other instances are running at at least one of the one or more determined entities associated with recovering the outage at the first segment of the first
zone," as recited in amended claim 1 ...
Examiner’s response to Argument:
The Examiner respectfully disagrees.
The amended independent claim is still disclosed by Yousouf as the following:
determining one or more entities from the plurality of entities defined for the cloud platform associated with recovering the outage at the first segment, the first segment corresponding to the selected flag, wherein the one or more entities are associated with other zones of the cloud platform (See Parag. [0141]; cloud platforms experience problems and downtime due to disruptions in network connectivity. In some instances, to prevent prolonged downtimes of cloud applications, 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. In some instances, 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. For example, an entity, such as an application, can execute a process that depends on executing a cloud service. If the cloud service's execution is affected by an outage in the AZ where the cloud service is requested to run, the application can continue to function and request that the cloud service executes at one of the remaining AZs not affected by the outage);
identifying other instances of the applications corresponding to the determined instances of the applications running at the first segment, wherein the other instances are running at at least of the one or more determined entities associated with recovering the outage at the first segment of the first zone (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 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 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 … 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 also Parag. [0141])
In addition, as previously described in the Examiner’s response to Argument 1 in the Final Office action, mailed on December 29th, 2025, the Examiner has reasonably interpreted the claimed flag(s) as an outage status visual indication to signal a particular condition/level associated with an outage. Therefore, the claimed flag(s) is/are reasonably interpreted to be equivalent to the “outage status level(s),” taught by Yousouf, that could be presented as color-coded levels, which are different colors that are a standardized way to "flag" or “indicate” specific outage condition(s)/level(s). In addition, the Examiner’s interpretation of the claimed flag(s) is consistent with Applicant’s specification. For example. the specification teaches, in at least Parag. [0127], that “red flag statuses can identify that an outage is associated with the respective components with which the flag is associated … a red flag status can be defined for a component that is a service, application or a database running at a particular zone of the cloud platform. In some more examples, the red flag status can be defined for a segment of a zone of the cloud platform, for example, for a network segment that is dedicated for running databases, applications, or services.”
Note: The same response applies to independent claims 12 and 17.
Claim Objections
Claim 1, 12, and 17 are objected to because of the following informality:
“... in response to identifying the other instances of the applications running at the one or more determined entities with recovering the outage, initiating a recovery procedure ...” should read (Examiner’s suggestion) “... in response to identifying the other instances of the applications running at the one or more determined entities associated with recovering the outage, initiating a recovery procedure ...”
Appropriate correction(s) is/are required.
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-9 and 12-20 are rejected under 35 U.S.C. 103 as being unpatentable over Youssouf et al. (Pub. No. US 2022/0255821), hereinafter Youssouf; in view of Kothari et al. (Pub. No. US 2022/0091947), hereinafter Kothari.
Claim 1. Yousouf discloses [a] computer-implemented method, comprising:
identifying a selection of a flag from a set of flags (See Parag. [0175-0176]; 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 … In response to evaluating the scope of the outage, an outage status level (flag) can be determined. The outage status level can be determined from a predefined set of levels. The predefined set of status levels can be defined as a scale including, for example, status levels “ok,” “warning,” “critical,” and “fatal,” although alternative and/or additional levels of an outage can be used, including numerical or color-coded levels. See also Parag. [0155] [0161] and Fig. 7. Examiner’s interpretation: The Examiner interprets “identifying a selection of a flag from a set of flags” as determining the status level from a predefined set of levels), wherein the flag is associated with a first entity running at the cloud platform including the multiple availability zones (See Parag. [0177]; in response to determining the outage status level (flag), corresponding actions for an entity (a first entity) running on the cloud platform that is affected by the outage can be determined. See Parag. [0161]; determining a health status of network connectivity of a multiple availability zone cloud platform (cloud platform including multiple availability zones)), wherein the flag is selected to identify an outage at a first segment of one or more segments of a first zone of the cloud platform (See Parag. [0175-0177]; an outage can be identified as associated with a particular segment of the segments (a first segment of one or more segments) of an availability zone of the cloud platform (a first zone of the cloud platform); the outage can be associated with an internal outage between entities running at that segment and entities running at another segment of the same availability zone … in response to determining that there is an outage, a particular or corresponding scope of the outage can be determined … In response to evaluating the scope of the outage, an outage status level (flag) can be determined … See also Parag. [0022] [0174]);
in response to the selection of the flag, determining instances of applications running at the first segment of the first zone of the cloud platform (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 … See Parag. [0175-0177]; 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 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. See Parag. [0087-0089]; the cloud environment can include multiple segments (e.g., an application network segment) … The cloud environment 106 may be configured to include multiple availability zones where one application may include multiple instances running in corresponding multiple availability zones … 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 ... See Parag. [0173]; entities running at a network segment of the network segment network segments of a first zone from the plurality of availability zones. See Parag. [0087-0089] [0139-0140] [0175-0177] [0228] [0241-0242] [0258] [0271] [0293] [0302]. Examiner’s interpretation: The entities taught by Yousouf are equivalent to applications. Therefore, in response to determining the outage status level associated with a particular segment of an availability zone of the cloud platform, entities (instances of applications) are determined);
determining one or more entities from the plurality of entities defined for the cloud platform associated with recovering the outage at the first segment, the first segment corresponding to the selected flag, wherein the one or more entities are associated with other zones of the cloud platform (See Parag. [0141]; cloud platforms experience problems and downtime due to disruptions in network connectivity. In some instances, to prevent prolonged downtimes of cloud applications, 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. In some instances, 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. For example, an entity, such as an application, can execute a process that depends on executing a cloud service. If the cloud service's execution is affected by an outage in the AZ where the cloud service is requested to run, the application can continue to function and request that the cloud service executes at one of the remaining AZs not affected by the outage);
identifying other instances of the applications corresponding to the determined instances of the applications running at the first segment, wherein the other instances are running at at least of the one or more determined entities associated with recovering the outage at the first segment of the first zone (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 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 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 … 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 also Parag. [0141]); and
in response to identifying the other instances of the applications running at the one or more determined entities with recovering the outage, initiating a recovery procedure to reconfigure communication flows at the cloud platform so that process flows directed to the determined instances of the applications running at the first segment are redirected to the other instances of the applications (See Parag. [0132]; provide instructions for affected entities to stop execution and offload service requests (communication flows) to other instances (other instances of the applications) 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 Parag. [0141]; ... 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. For example, an entity, such as an application, can execute a process that depends on executing a cloud service. If the cloud service's execution is affected by an outage in the AZ where the cloud service is requested to run, the application can continue to function and request that the cloud service executes at one of the remaining AZs not affected by the outage ... See also Parag. [0129] [0135-0138] [0140] [0177]).
Yousouf doesn’t explicitly disclose the set of flags that are each associated with a respective one of a plurality of entities running at a cloud platform including multiple availability zones.
However, Kothari discloses a set of flags that are each associated with a respective one of a plurality of entities running at a cloud platform including multiple availability zones (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 (a cloud platform including multiple availability zones) … See Parag. [0075]; GUI may include an application status dashboard that shows a visual indication of a status of each application (one of a plurality of 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 … Examiner’s interpretation: The Examiner reasonably interprets each flag of the set of flags as each colored indication of the set of colored indications, where the colored indications are associated with applications (plurality of entities) running at the cloud including multiple regions).
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 each outage status level, taught by Yousouf, to be associated with a respective one of a plurality of entities running at a cloud platform including multiple availability zones, as taught by Kothari. This would be convenient to performing an extreme technical recovery exercise on a cloud infrastructure (Kothari, Parag. [0006]).
Claim 2. Yousouf in view of Kothari discloses [t]he method of claim 1,
Yousouf further discloses wherein each entity from the plurality of entities 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. [0092]; The segments part of the cloud platform are network segments that are associated with entities of different type running at the cloud platform. One entity running at one segment may be communicatively coupled to another entity in another segment, and can consume provided services and/or data (a cloud component running at a segment of a zone of the cloud platform). See Parag. [0175-0177]; 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. [0141] and Fig. 7).
Claim 3. Yousouf in view of Kothari discloses [t]he method of claim 1,
Yousouf further discloses wherein the selection of the flag indicates modification of a health status of the first entity associated with the flag to a critical state (See Parag. [0141]; To be able to address network outages identified at different AZs, a monitoring framework (FIGS. 2, 3, 4, 5, and 6) can be implemented to monitor, evaluate, and report health status information about AZs, corresponding network segments, and corresponding status for different network connectivity types. See Parag. [0176-0177]; 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 (e.g., critical) … 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. See Parag. [0196]; if the inbound connectivity of the first availability zone is with a status level “critical,” then the inbound connectivity status level can be determined by further evaluations that can be performed to determine whether the availability zone is further isolated from other availability zones or not, and can be defined as a final status of either “warning” or as updated to “critical” … See Parag. [0037] [0081] [0106] [0115] [0132] [0140] [0195-0196] [0235]), and wherein identifying the other instances of the applications comprises identifying the other instances of the applications based on an evaluation of the critical state of the first entity associated with the flag at an orchestrator component running for the cloud platform to manage communication flows (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 to other instances (the other instances of the applications) running at a different network segment or at a different region or zone where network outages are not limiting the services. See Parag. [0170]; “application instance.” See also Parag. [0087-0089] [0141] [0158] [0170] [0175-0177] [0183]. Examiner’s interpretation: In response to evaluating the scope of the outage, an outage status level (e.g., critical) can be determined, and the status is evaluated to provide instructions for affected entities to stop execution and offload service requests to other instances (other instances of the applications)).
Claim 4. Yousouf in view of Kothari discloses [t]he method of claim 1,
Yousouf further discloses wherein the plurality of entities includes 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 a respective component type that each run at a respective zone of the multiple availability zones (See Parag. [0132]; provide instructions for affected 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 Parag. [0154]; the entity may be a database that runs with multiple instances at different AZs. See Parag. [0170]; “application instance.” See Parag. [0276]; “database instance.” See also Parag. [0141]).
Claim 5. Yousouf in view of Kothari discloses [t]he method of claim 1,
Yousouf further discloses wherein initiating the recovery procedure comprises determining a new process flow to reconfigure a previous process flow including a first instance of the instances of the applications running at the first segment of the first zone of the cloud platform, wherein the new process flow includes a corresponding second instance of the other instances to replace the first instance, the corresponding second instance running at one of one or more second segments of a second zone (See Parag. [0132]; provide instructions for affected 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 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 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. See Parag. [0170]; “application instance.” See also Parag. [0087-0089] [0129] [0135-0138] [0140-0141] [0177]. Examiner’s interpretation: The secondary instance (corresponding second instance of the other instances) is to replace an application instance in an AZ having an “AZ Down” outage status (the first instance), where the secondary instance is running at a network segment of the network segments of a second zone).
Claim 6. Yousouf in view of Kothari discloses [t]he method of claim 5,
Yousouf further discloses wherein initiating the recovery procedure comprises:
using the new process flow to replace a previous process flow including the first segment associated with the flag, wherein the new process flow excludes the instances of the applications running at the first segment associated with the flag (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 to other instances running at a different network segment or at a different region or zone where network outages are not limiting the services (the new process flow excludes the instances of applications running at the first segment associated with the flag). 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 Parag. [0170]; “application instance.” See also Parag. [0087-0089] [0129] [0135-0136] [0140] [0173-0177]); and
disabling services provided by the instances of the applications running at the first segment associated with the flag and redirecting requests to be received by the other instances of the applications running at the one or more second segments of the second zone (See Parag. [0132]; provide instructions for affected entities to stop execution (disabling services provided by the instances) 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 (redirecting requests to be received by the other instances). See Parag. [0170]; “application instance.” See also Parag. [0087-0089] [0129] [0135-0136] [0140] [0173-0177]).
Claim 7. Yousouf in view of Kothari discloses [t]he method of claim 5,
Yousouf further discloses wherein the new process flow excludes the instances of the applications running at the first segment associated with the flag and includes process flows that include only the other instances of the applications running at the one or more second segments of the second zone (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 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 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 Parag. [0170]; “application instance.” See also Parag. [0087-0089] [0129] [0135-0136] [0140] [0170] [0173-0177]).
Claim 8. Yousouf in view of Kothari discloses [t]he method of claim 1,
Yousouf discloses the method further comprising: configuring flags at the cloud platform, where each flag, when triggered, generates an event associated with an outage at one or more entities at the cloud platform (See Parag. [0175-0177]; in response to determining that there is an outage, a particular or corresponding scope of the outage can be determined … In response to evaluating the scope of the outage, an outage status level (flag) can be determined. The outage status level can be determined from a predefined set of levels. The predefined set of status levels can be defined as a scale including, for example, status levels “ok,” “warning,” “critical,” and “fatal,” … 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).
Claim 9. Yousouf in view of Kothari discloses [t]he method of claim 1,
Yousouf further discloses wherein the plurality of entities defined at the cloud platform are configured to monitor events associated with triggered flags from the set of flags and initiate recovery procedures corresponding to entities associated with the triggered flags (See Parag. [0161-0177]; FIG. 8 is a flow chart for an example method 800 for determining a health status of network connectivity of a multiple availability zone cloud platform; The method 800 can be executed by different entities (the plurality of entities defined at the cloud platform) of the monitoring framework discussed at FIG. 7 … based on determining the health status at 830, a network outage at a network segment from the network segments of at least one of the plurality of availability zones can be identified … in response to determining that there is an outage, a particular or corresponding scope of the outage can be determined … In response to evaluating the scope of the outage, an outage status level (flag) 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. See also Parag. [0135]. Examiner’s note: The method 800 can be executed by different entities (the plurality of entities defined at the cloud platform)).
Claim 12. 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:
identifying a selection of a flag from a set of flags (See Parag. [0175-0176]; 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 … In response to evaluating the scope of the outage, an outage status level (flag) can be determined. The outage status level can be determined from a predefined set of levels. The predefined set of status levels can be defined as a scale including, for example, status levels “ok,” “warning,” “critical,” and “fatal,” although alternative and/or additional levels of an outage can be used, including numerical or color-coded levels. See also Parag. [0155] [0161] and Fig. 7. Examiner’s interpretation: The Examiner interprets “identifying a selection of a flag from a set of flags” as determining the status level from a predefined set of levels), wherein the flag is associated with a first entity running at the cloud platform including the multiple availability zones (See Parag. [0177]; in response to determining the outage status level (flag), corresponding actions for an entity (a first entity) running on the cloud platform that is affected by the outage can be determined. See Parag. [0161]; determining a health status of network connectivity of a multiple availability zone cloud platform (cloud platform including multiple availability zones)), wherein the flag is selected to identify an outage at a first segment of one or more segments of a first zone of the cloud platform (See Parag. [0175-0177]; an outage can be identified as associated with a particular segment of the segments (a first segment of one or more segments) of an availability zone of the cloud platform (a first zone of the cloud platform); the outage can be associated with an internal outage between entities running at that segment and entities running at another segment of the same availability zone … in response to determining that there is an outage, a particular or corresponding scope of the outage can be determined … In response to evaluating the scope of the outage, an outage status level (flag) can be determined … See also Parag. [0022] [0174]);
in response to the selection of the flag, determining instances of applications running at the first segment of the first zone of the cloud platform (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 … See Parag. [0175-0177]; 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 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. See Parag. [0087-0089]; the cloud environment can include multiple segments (e.g., an application network segment) … The cloud environment 106 may be configured to include multiple availability zones where one application may include multiple instances running in corresponding multiple availability zones … 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 ... See Parag. [0173]; entities running at a network segment of the network segment network segments of a first zone from the plurality of availability zones. See Parag. [0087-0089] [0139-0140] [0175-0177] [0228] [0241-0242] [0258] [0271] [0293] [0302]. Examiner’s interpretation: The entities taught by Yousouf are equivalent to applications. Therefore, in response to determining the outage status level associated with a particular segment of an availability zone of the cloud platform, entities (instances of applications) are determined);
determining one or more entities from the plurality of entities defined for the cloud platform associated with recovering the outage at the first segment, the first segment corresponding to the selected flag, wherein the one or more entities are associated with other zones of the cloud platform (See Parag. [0141]; cloud platforms experience problems and downtime due to disruptions in network connectivity. In some instances, to prevent prolonged downtimes of cloud applications, 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. In some instances, 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. For example, an entity, such as an application, can execute a process that depends on executing a cloud service. If the cloud service's execution is affected by an outage in the AZ where the cloud service is requested to run, the application can continue to function and request that the cloud service executes at one of the remaining AZs not affected by the outage);
identifying other instances of the applications corresponding to the determined instances of the applications running at the first segment, wherein the other instances are running at at least of the one or more determined entities associated with recovering the outage at the first segment of the first zone (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 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 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 … 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 also Parag. [0141]); and
in response to identifying the other instances of the applications running at the one or more determined entities with recovering the outage, initiating a recovery procedure to reconfigure communication flows at the cloud platform so that process flows directed to the determined instances of the applications running at the first segment are redirected to the other instances of the applications (See Parag. [0132]; provide instructions for affected entities to stop execution and offload service requests (communication flows) to other instances (other instances of the applications) 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 Parag. [0141]; ... 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. For example, an entity, such as an application, can execute a process that depends on executing a cloud service. If the cloud service's execution is affected by an outage in the AZ where the cloud service is requested to run, the application can continue to function and request that the cloud service executes at one of the remaining AZs not affected by the outage ... See also Parag. [0129] [0135-0138] [0140] [0177]).
Yousouf doesn’t explicitly disclose the set of flags that are each associated with a respective one of a plurality of entities running at a cloud platform including multiple availability zones.
However, Kothari discloses a set of flags that are each associated with a respective one of a plurality of entities running at a cloud platform including multiple availability zones (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 (a cloud platform including multiple availability zones) … See Parag. [0075]; GUI may include an application status dashboard that shows a visual indication of a status of each application (one of a plurality of 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 … Examiner’s interpretation: The Examiner reasonably interprets each flag of the set of flags as each colored indication of the set of colored indications, where the colored indications are associated with applications (plurality of entities) running at the cloud including multiple regions).
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 each outage status level, taught by Yousouf, to be associated with a respective one of a plurality of entities running at a cloud platform including multiple availability zones, as taught by Kothari. This would be convenient to performing an extreme technical recovery exercise on a cloud infrastructure (Kothari, Parag. [0006]).
Claim 13 is taught by Yousouf in view of Kothari as described for claim 2.
Claim 14 is taught by Yousouf in view of Kothari as described for claim 3.
Claim 15 is taught by Yousouf in view of Kothari as described for claim 4.
Claim 16 is taught by Yousouf in view of Kothari as described for claim 5.
Claim 17. Yousouf 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:
identifying a selection of a flag from a set of flags (See Parag. [0175-0176]; 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 … In response to evaluating the scope of the outage, an outage status level (flag) can be determined. The outage status level can be determined from a predefined set of levels. The predefined set of status levels can be defined as a scale including, for example, status levels “ok,” “warning,” “critical,” and “fatal,” although alternative and/or additional levels of an outage can be used, including numerical or color-coded levels. See also Parag. [0155] [0161] and Fig. 7. Examiner’s interpretation: The Examiner interprets “identifying a selection of a flag from a set of flags” as determining the status level from a predefined set of levels), wherein the flag is associated with a first entity running at the cloud platform including the multiple availability zones (See Parag. [0177]; in response to determining the outage status level (flag), corresponding actions for an entity (a first entity) running on the cloud platform that is affected by the outage can be determined. See Parag. [0161]; determining a health status of network connectivity of a multiple availability zone cloud platform (cloud platform including multiple availability zones)), wherein the flag is selected to identify an outage at a first segment of one or more segments of a first zone of the cloud platform (See Parag. [0175-0177]; an outage can be identified as associated with a particular segment of the segments (a first segment of one or more segments) of an availability zone of the cloud platform (a first zone of the cloud platform); the outage can be associated with an internal outage between entities running at that segment and entities running at another segment of the same availability zone … in response to determining that there is an outage, a particular or corresponding scope of the outage can be determined … In response to evaluating the scope of the outage, an outage status level (flag) can be determined … See also Parag. [0022] [0174]);
in response to the selection of the flag, determining instances of applications running at the first segment of the first zone of the cloud platform (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 … See Parag. [0175-0177]; 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 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. See Parag. [0087-0089]; the cloud environment can include multiple segments (e.g., an application network segment) … The cloud environment 106 may be configured to include multiple availability zones where one application may include multiple instances running in corresponding multiple availability zones … 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 ... See Parag. [0173]; entities running at a network segment of the network segment network segments of a first zone from the plurality of availability zones. See Parag. [0087-0089] [0139-0140] [0175-0177] [0228] [0241-0242] [0258] [0271] [0293] [0302]. Examiner’s interpretation: The entities taught by Yousouf are equivalent to applications. Therefore, in response to determining the outage status level associated with a particular segment of an availability zone of the cloud platform, entities (instances of applications) are determined);
determining one or more entities from the plurality of entities defined for the cloud platform associated with recovering the outage at the first segment, the first segment corresponding to the selected flag, wherein the one or more entities are associated with other zones of the cloud platform (See Parag. [0141]; cloud platforms experience problems and downtime due to disruptions in network connectivity. In some instances, to prevent prolonged downtimes of cloud applications, 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. In some instances, 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. For example, an entity, such as an application, can execute a process that depends on executing a cloud service. If the cloud service's execution is affected by an outage in the AZ where the cloud service is requested to run, the application can continue to function and request that the cloud service executes at one of the remaining AZs not affected by the outage);
identifying other instances of the applications corresponding to the determined instances of the applications running at the first segment, wherein the other instances are running at at least of the one or more determined entities associated with recovering the outage at the first segment of the first zone (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 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 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 … 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 also Parag. [0141]); and
in response to identifying the other instances of the applications running at the one or more determined entities with recovering the outage, initiating a recovery procedure to reconfigure communication flows at the cloud platform so that process flows directed to the determined instances of the applications running at the first segment are redirected to the other instances of the applications (See Parag. [0132]; provide instructions for affected entities to stop execution and offload service requests (communication flows) to other instances (other instances of the applications) 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 Parag. [0141]; ... 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. For example, an entity, such as an application, can execute a process that depends on executing a cloud service. If the cloud service's execution is affected by an outage in the AZ where the cloud service is requested to run, the application can continue to function and request that the cloud service executes at one of the remaining AZs not affected by the outage ... See also Parag. [0129] [0135-0138] [0140] [0177]).
Yousouf doesn’t explicitly disclose the set of flags that are each associated with a respective one of a plurality of entities running at a cloud platform including multiple availability zones.
However, Kothari discloses a set of flags that are each associated with a respective one of a plurality of entities running at a cloud platform including multiple availability zones (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 (a cloud platform including multiple availability zones) … See Parag. [0075]; GUI may include an application status dashboard that shows a visual indication of a status of each application (one of a plurality of 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 … Examiner’s interpretation: The Examiner reasonably interprets each flag of the set of flags as each colored indication of the set of colored indications, where the colored indications are associated with applications (plurality of entities) running at the cloud including multiple regions).
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 each outage status level, taught by Yousouf, to be associated with a respective one of a plurality of entities running at a cloud platform including multiple availability zones, as taught by Kothari. This would be convenient to performing an extreme technical recovery exercise on a cloud infrastructure (Kothari, Parag. [0006]).
Claim 18 is taught by Yousouf in view of Kothari as described for claim 2.
Claim 19 is taught by Yousouf in view of Kothari as described for claim 3.
Claim 20 is taught by Yousouf in view of Kothari as described for claim 4.
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Youssouf et al. (Pub. No. US 2022/0255821), hereinafter Youssouf; in view of Kothari et al. (Pub. No. US 2022/0091947), hereinafter Kothari; and further in view of Gao et al. (Pub. No. US 2023/0048513), hereinafter Gao.
Claim 10. Yousouf in view of Kothari discloses [t]he method of claim 1,
Yousouf discloses the method further comprising, before receiving the selection of the flag at the cloud platform, identifying, based on monitored data associated with a health status of the cloud platform, the outage at the cloud platform (See Parag. [0175-0176]; 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 … In response to evaluating the scope of the outage, an outage status level (flag) can be determined. The outage status level can be determined from a predefined set of levels. Examiner’s interpretation: The outage at the cloud platform is identified before and outage status level is determined), wherein the outage restrict access to services provided by the first entity associated with the flag that is selected at the cloud platform (See Parag. [0079]; A disruption in the connectivity may be associated with an outage having a given scope and affecting connections of certain type(s) associated with the cloud platform. For example, a disruption in the connectivity may be defined as an internal outage within the cloud platform, as an external outage for external accessibility of resource to and from the cloud platform, or as both external and internal outage. An internal outage may be associated with connectivity between entities running within the cloud platform, and may affect internal cloud connections. For example, an application running on the cloud platform may be restricted to access a database (i.e., entity) running on the cloud platform due to an internal outage between an application and a database segment where these instances are running. An external outage may restrict connectivity between the cloud platform and an external environment See also Parag. [0132] [0140] [0277]).
Yousouf in view of Kothari doesn’t explicitly disclose identifying the outage at the cloud platform is based on monitored data associated with a health status of the cloud platform that is input at a trained model.
However, Gao discloses identifying, based on monitored data associated with a health status of the cloud platform that is input at a trained model, the outage at the cloud platform (See Parag. [0021]; correlation module may be configured to aggregate service health incidents that correspond to a common outage within the cloud computing platform into aggregated incident information, and identify the resources and/or services impacted by an outage … the correlation module may employ machine learning techniques, pattern recognition techniques, and/or heuristic techniques to aggregate the service health incidents. Further, the machine learning models may be trained using historic service health incident information. See Parag. [0022]).
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 identifying the outage at the cloud platform, taught by Yousouf in view of Kothari, to be based on monitored data associated with a health status of the cloud platform that is input at a trained model, as taught by Gao. This would be convenient to ensure that a tenant device receives an incident notification that identifies the full scope outage, thereby permitting the tenant to adapt to the effects of the outage (Gao, Parag. [0022]).
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Youssouf et al. (Pub. No. US 2022/0255821), hereinafter Youssouf; in view of Kothari et al. (Pub. No. US 2022/0091947), hereinafter Kothari; and further in view of Sampath et al. (Pub. No. US 2015/0317194), hereinafter Sampath.
Claim 11. Yousouf in view of Kothari discloses [t]he method of claim 1,
Yousouf discloses the method further comprising:
receiving a notification that the first entity associated with the flag is running successfully at the first zone after the outage has been identified and resolved (See Parag. [0121]; entities can subscribe to receive notifications for health statuses for network connectivity of the first cloud platform. For example, an application can subscribe to received notifications for a detected outage or a resolved outage at a network segment corresponding to the application. See also Parag. [0140]; the application management service 605 may send instructions to start the execution of the application 615 if it is determined that the network connectivity of the application segment is restored); and
in response to the received notification, initiating a recovery procedure (See Parag. [0140]; in response to determining the health status of network connectivity for the application segment of the cloud platform that defines whether an entity running at the application segment can be accessed or can access other entities, resources, or data, the application management service 605 can initiate to communicate with an application 615 that is running at the application segment of the cloud platform. Based on determining the health status of network connectivity of the application segment of the cloud platform, the application management service 605 may execute a call to the application 615 to provide instructions and to manage the application based on the determined status … the application management service 605 may send instructions to start the execution of the application 615 if it is determined that the network connectivity of the application segment is restored. See also Parag. [0088] [0132]).
Yousouf in view of Kothari doesn’t explicitly disclose initiating a recovery procedure to reconfigure communication flows and define flows through entities running at the first zone of the cloud platform.
However, Sampath discloses initiating a recovery procedure to reconfigure communication flows and define flows through entities running at the first zone of the cloud platform (See Parag. [0092]; Once disaster recovery system 250 has completed processing the disaster recovery plan, the standby site becomes the new primary site. For example, after a failover or switchover operation, global redirector 206 may redirect client requests to standby site 260 (the new primary site). The client may access the same applications and data on standby site 260 that were deployed on primary site 210 immediately before the failover or switchover occurred. See Parag. [0054-0060]; The disaster recovery plan may include one or more operation plans for different disaster recovery operations that may be executed by the disaster recovery system: Switchover-to-Site-B: Reverses the roles of the primary site and the standby site such that a current standby site becomes the new primary site and the current primary site becomes the new standby; Switchback-to-Site-A: Reverses the roles of the new primary site (old standby) and the new standby site (old primary) that is applicable to a previous switchover. See Parag. [0043]; Global redirector 206 directs client requests to one of the primary site 210 or standby site 260 based on which site is active (i.e., the site that currently has a designated role as the “primary” site). See Parag. [0036]; Primary site 210 generally comprises primary site load balance 212, application platform 214, storage appliance 216, and database appliance 218 (entities running at the first zone). Examiner’s interpretation: When the primary site (first zone) becomes active after Switchback, client requests are redirected to the primary site (reconfigure communication flows)).
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 initiating the recovery procedure, taught by Yousouf in view of Kothari, to reconfigure communication flows and define flows through entities running at the first zone of the cloud platform, as taught by Sampath. This would be convenient to dynamically generating a disaster recovery plan as it takes into account the current state of deployment of a primary site, reacting to any changes that may have occurred (Sampath, Parag. [0016]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
McLarty et al. (Pub. No. US 2019/0230156) – Related art in the area of automatically discovering the status of entities associated with one or more data centers of a data center cluster, (Abstract; A method of discovering a status of entities associated with one or more data centers of a data center cluster. The method includes receiving, a request for entity data associated with one or more data centers of a data center cluster; identifying a host machine of a data center of the one or more data centers based on the request; and sending a discovery request to the host machine of the data center. The discovery request configured to cause operations comprising generating, by the host machine of the data center, entity data associated with the host machine of the data center and a second host machine of a second data center; generating display data based on the entity data; and sending the display data to the user device. The display data configured to cause the user device to display the entity data in a window of the application).
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/Primary Examiner, Art Unit 2445
Prosecution Insights