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 21st, 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 20th, 2025. In this office action:
Claims 1-20 are pending.
Claims 1-20 are rejected.
Summary of Previous Office Action
In the Non-Final Office Action mailed on May 20th, 2025:
Claims 6, 7, 10, and 11 were objected because of informalities.
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 August 20th, 2025 have been entered.
Claims 1, 3, 5-7, 10-12, 14, 16-17, and 19 have been amended.
The previously raised claim objections are withdrawn for claims 6, 7, 10, and 11 in light of the amendments.
Response to Arguments
Applicant Arguments/Remarks (Pages 10/14 to 12-/14), filed on August 20th, 2025, have been fully considered by the Examiner, but are not persuasive.
Applicant’s argument 1:
The Applicant argues the following:
“While Applicant respectfully disagrees with the rejection, Applicant submits that Yousouf has not been shown to teach or suggest at least the amended claim language. While Yousouf describes defining "an outage status level," the cited portion of Yousouf has not been shown to disclose or suggest "identifying a selection of a flag from 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, wherein the flag is associated with a first entity running at the cloud platform including the multiple availability zones," as recited by amended claim 1.
In particular, "a scale including, for example, status levels "ok," "warning," "critical," and "fatal," as taught by the cited portion of Yousouf is different from, and does not disclose or suggest "a set of flags that are each associated with a respective one of a plurality of entities running at a cloud platform including the multiple availability zones," as recited in amended claim 1.
Kothari has not been shown to cure the above-described deficiencies of Yousouf in disclosing this feature. Indeed, the cited portion of Kothari merely discusses a GUI which "may include an application status dashboard that shows a visual indication of a status of each application." At paragraph 0075.
"[A] status of each application" as taught by the cited portion of Kothari is different from, and does not disclose or suggest, "a set of flags that are each associated with a respective one of a plurality of entities running at a cloud platform including the multiple availability zones," as recited in amended claim 1.
Since neither Yousouf nor Kothari discloses or suggests the flag(s) as claimed, their combination also fails to provide the flag(s) as claimed, let alone features that relate to the flag(s) as recited in amended claim 1.”
Examiner’s response to Argument 1:
The Examiner respectfully disagrees.
Yousouf discloses 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)).
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).
Yousouf discloses 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 (Yousouf, See Parag. [0175-0176]). Kothari discloses 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 ... (Kothari, Parag. [0075]).
Therefore, 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]).
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 claimed flag(s) is/are equivalent to the visual indication(s) of a status of each application (claimed entity), as taught by Kothari, where Kothari discloses that each colored visual indication status is associated with a respective application (a respective one of a plurality of entities).
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.
Applicant’s Argument 2:
The Applicant argues the following:
In particular, the cited combination does not disclose or suggest "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," nor does their combination disclose or suggest" identifying other instances of the applications running at one or more second segments of a second zone of the cloud platform, the one or more second segments associated with recovering the outage at the first segments of the first zone." Therefore, Applicant respectfully asserts that the cited references, whether alone or in combination, have not been shown to teach, suggest, or otherwise disclose each and every element of amended independent claim 1.
Examiner’s response to Argument 2:
The Examiner respectfully disagrees.
Yousouf discloses 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); [and]
identifying other instances of the applications running at one or more second segments of a second zone of the cloud platform, the one or more second segments associated with recovering the outage at the first segments 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]. Examiner’s interpretation: The entities running on segment(s) at the second zone (other instances of the applications running at one or more second segments of a second zone), which are associated with recovering the outage at the particular segment (first segment) of the first zone, are identified).
Note: The same response applies to independent claims 12 and 17.
Claim Objections
Claim 5 and 16 are objected to because of the following informality:
“... initiating the recovery procedure comprises determining a new process flow to reconfigure a previous process flow including a first instance of the instances of applications running at the first segment ...” should read (Examiner’s suggestion) “... 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 ...”
Claim 6 is objected to because of the following informalities:
“... wherein the new process flow excludes the instances of applications running at the first segment ... disabling services provided by the instances of applications running at the first segment ...” should read (Examiner’s suggestion) “... wherein the new process flow excludes the instances of the applications running at the first segment ... disabling services provided by the instances of the applications running at the first segment ...”
Claim 7 is objected to because of the following informality:
“... wherein the new process flow excludes the instances of applications running at the first segment ...” should read (Examiner’s suggestion) “... wherein the new process flow excludes the instances of the applications running at the first segment ...”
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.
Claims 1-20 are 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 1 recites the phrase “the first segments” in "identifying other instances of the applications running at one or more second segments of a second zone of the cloud platform, the one or more second segments associated with recovering the outage at the first segments of the first zone." The phrase “the first segments” has never been introduced in claim 1. There is insufficient antecedent basis for this limitation in the claim.
Claim 1 recites “… identify an outage at a first segment of one or more segments of a first zone of the cloud platform …” Therefore, for the purpose of examination, the Examiner interprets the limitation as "identifying other instances of the applications running at one or more second segments of a second zone of the cloud platform, the one or more second segments associated with recovering the outage at the first segment of the first zone.”
Claims 2-11 are rejected under 35 U.S.C. 112(b) as they depend on the rejected claim 1.
Claim 12 recites the phrase “the first segments” in "identifying other instances of the applications running at one or more second segments of a second zone of the cloud platform, the one or more second segments associated with recovering the outage at the first segments of the first zone." The phrase “the first segments” has never been introduced in claim 12. There is insufficient antecedent basis for this limitation in the claim.
Claim 12 recites “… identify an outage at a first segment of one or more segments of a first zone of the cloud platform …” Therefore, for the purpose of examination, the Examiner interprets the limitation as "identifying other instances of the applications running at one or more second segments of a second zone of the cloud platform, the one or more second segments associated with recovering the outage at the first segment of the first zone.”
Claims 13-16 are rejected under 35 U.S.C. 112(b) as they depend on the rejected claim 12.
Claim 17 recites the phrase “the first segments” in "identifying other instances of the applications running at one or more second segments of a second zone of the cloud platform, the one or more second segments associated with recovering the outage at the first segments of the first zone." The phrase “the first segments” has never been introduced in claim 17. There is insufficient antecedent basis for this limitation in the claim.
Claim 17 recites “… identify an outage at a first segment of one or more segments of a first zone of the cloud platform …” Therefore, for the purpose of examination, the Examiner interprets the limitation as "identifying other instances of the applications running at one or more second segments of a second zone of the cloud platform, the one or more second segments associated with recovering the outage at the first segment of the first zone.”
Claims 18-20 are rejected under 35 U.S.C. 112(b) as they depend on the rejected claim 17.
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);
identifying other instances of the applications running at one or more second segments of a second zone of the cloud platform, the one or more second segments associated with recovering the outage at the first segments 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]. Examiner’s interpretation: The entities running on segment(s) at the second zone (other instances of the applications running at one or more second segments of a second zone), which are associated with recovering the outage at the particular segment (first segment) of the first zone, are identified); and
in response to identifying the other instances of the applications running at the one or more second segments of the second zone associated with recovering the outage, initiating a recovery procedure to reconfigure communication flows at the cloud platform (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 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 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 the one or more second segments of the 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 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 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 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);
identifying other instances of the applications running at one or more second segments of a second zone of the cloud platform, the one or more second segments associated with recovering the outage at the first segments 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]. Examiner’s interpretation: The entities running on segment(s) at the second zone (other instances of the applications running at one or more second segments of a second zone), which are associated with recovering the outage at the particular segment (first segment) of the first zone, are identified); and
in response to identifying the other instances of the applications running at the one or more second segments of the second zone associated with recovering the outage, initiating a recovery procedure to reconfigure communication flows at the cloud platform (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 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);
identifying other instances of the applications running at one or more second segments of a second zone of the cloud platform, the one or more second segments associated with recovering the outage at the first segments 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]. Examiner’s interpretation: The entities running on segment(s) at the second zone (other instances of the applications running at one or more second segments of a second zone), which are associated with recovering the outage at the particular segment (first segment) of the first zone, are identified); and
in response to identifying the other instances of the applications running at the one or more second segments of the second zone associated with recovering the outage, initiating a recovery procedure to reconfigure communication flows at the cloud platform (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 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:
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