CTNF 19/006,466 CTNF 82187 Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. DETAILED ACTION 1. This action is in response to the application filed on 31 December 2024. Claims 1-20 are presently pending for examination. Information Disclosure Statement 2. The information disclosure statement (IDS) submitted on 12/31/2024 and 04/09/2025 has being considered by the examiner. Double Patenting 08-33 AIA 3. The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg , 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman , 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi , 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum , 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel , 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington , 418 F.2d 528, 163 USPQ 644 (CCPA 1969). A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA. A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b). The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13. The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA/25, or PTO/AIA/26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer. Claims 1, 8 and 15 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims of copending application no. 18/531957. Although the claims at issue are not identical, they are not patentably distinct from each other because both sets of claims are directed to recovery procedures of red button service based on received red flag statuses. It would have been obvious to modify the claims in 18/531957 in the new set of instant claims in order to seek broader patent protection of the new claims. Claim Rejections - 35 USC § 103 07-20-aia AIA 4. 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. 07-21-aia AIA 5. Claim (s) 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Parmar et al., U. S. Patent Publication No. 2023/0107518 in view of Meagher et al., U. S. Patent Publication No. 2018/0062915 . Regarding claim 1, Parmar discloses a computer-implemented method, comprising: receiving a selection of a flag from a set of flags defined at a cloud platform including multiple availability zones, wherein the flag is selected to identify an outage at a first zone of the cloud platform (see Parmar, ¶ [0040] and [0080]; outages are detected using status indicators); determining an instance of an entity running at the first zone of the cloud platform (see Parmar, ¶ [0044]-[0045]; affected components in the zone is determined); determining a state mode of running instances of the entity at the cloud platform (see Parmar, ¶ [0046] and [0049]; components status is determined); in response to determining the state mode, executing a recovery procedure for the instance of the entity running at the first zone (see Parmar, ¶ [0057]-[0058] and [0080]; recovery procedure is performed); and in response to the determined rules, executing the recovery procedure determined based on to the state mode of running instances of the entity to reconfigure subsequent communication directed to the entity to another one or more instances running at one or more other zones of the cloud platform (see Parmar, ¶ [0047] and [0057]; failed components are reconfigured and replaced). Although Parmar discloses the invention substantially as claimed, it does not explicitly disclose the use of rules to determine recovery. Meagher teaches cloud-based service outage detection system that among other things teach the use of rules to determine recovery (see Meagher, ¶ [0049] and [0056]). It would have been obvious to one of ordinary skill in the art before the effective filling date of the invention to incorporate the teachings of Meagher with that of Parmar in order to ensure consistency, and compliance in restoring systems and operations after an outage incident. Regarding claim 2, Parmar-Meagher teaches wherein the selection of the flag is received to trigger the recovery procedure for instances running at the first zone of the cloud platform and mapped to the flag (see Parmar, ¶ [0058] and [0080]). Regarding claim 3, Parmar-Meagher teaches wherein a plurality of entities is running on the cloud platform, wherein each entity is running with one or more instances distributed over one or more availability zones, and 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 Parmar, ¶ [0035] and [0048]). Regarding claim 4, Parmar-Meagher teaches wherein the plurality of entities includes different cloud component types including applications, services, and databases, 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 Parmar, ¶ [0025] and [0044]). Regarding claim 5, Parmar-Meagher teaches wherein each cloud component type of an entity is associated with a respective state mode of running instances of entities of the type, wherein a state mode of a cloud component type is either an active-active mode or an active-passive mode (see Parmar, ¶ [0071]). Regarding claim 6, Parmar-Meagher teaches wherein, when the state mode of running instances of the entity is determined to be an active-passive mode, the determined rules for executing the recovery procedure include rules for reconfiguring the subsequent communication by executing a failover procedure to redirect the subsequent communication directed to the entity to an instance of the entity running in another zone of the cloud platform that is not associated with the selected flag (see Parmar, ¶ [0081] and Meagher, ¶ [0056]). Same motivation utilized in claim 1 applies equally as well to claim 6. Regarding claim 7, Parmar-Meagher teaches wherein, when the state mode of running instance of the entity is determined to an active-active state, the determined rules for executing the recovery procedure include rules for reconfiguring the subsequent communication by transmitting requests for services from the entity only to other one or more instances running at one or more zones of the cloud platform, the other one or more zones not being associated with the selected flag (see Parmar, ¶[0071] and Meagher, ¶ [0049]). Same motivation utilized in claim 1 applies equally as well to claim 7. Regarding claim 8, Parmar 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 comprising: receiving a selection of a flag from a set of flags defined at a cloud platform including multiple availability zones, wherein the flag is selected to identify an outage at a first zone of the cloud platform (see Parmar, ¶ [0040] and [0080]; outages are detected using status indicators); determining an instance of an entity running at the first zone of the cloud platform (see Parmar, ¶ [0044]-[0045]; affected components in the zone is determined); determining a state mode of running instances of the entity at the cloud platform (see Parmar, ¶ [0046] and [0049]; components status is determined); in response to determining the state mode, executing a recovery procedure for the instance of the entity running at the first zone (see Parmar, ¶ [0057]-[0058] and [0080]; recovery procedure is performed); and in response to the determined rules, executing the recovery procedure determined based on to the state mode of running instances of the entity to reconfigure subsequent communication directed to the entity to another one or more instances running at one or more other zones of the cloud platform (see Parmar, ¶ [0047] and [0057]; failed components are reconfigured and replaced). Although Parmar discloses the invention substantially as claimed, it does not explicitly disclose the use of rules to determine recovery. Meagher teaches cloud-based service outage detection system that among other things teach the use of rules to determine recovery (see Meagher, ¶ [0049] and [0056]). It would have been obvious to one of ordinary skill in the art before the effective filling date of the invention to incorporate the teachings of Meagher with that of Parmar in order to ensure consistency, and compliance in restoring systems and operations after an outage incident. Regarding claim 9, Parmar-Meagher teaches wherein the selection of the flag is received to trigger the recovery procedure for instances running at the first zone of the cloud platform and mapped to the flag (see Parmar, ¶ [0058] and [0080]). Regarding claim 10, Parmar-Meagher teaches wherein a plurality of entities is running on the cloud platform, wherein each entity is running with one or more instances distributed over one or more availability zones, and 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 Parmar, ¶ [0035] and [0048]). Regarding claim 11, Parmar-Meagher teaches wherein the plurality of entities includes different cloud component types including applications, services, and databases, 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 Parmar, ¶ [0025] and [0044]). Regarding claim 12, Parmar-Meagher teaches wherein each cloud component type of an entity is associated with a respective state mode of running instances of entities of the type, wherein a state mode of a cloud component type is either an active-active mode or an active-passive mode (see Parmar, ¶ [0071]). Regarding claim 13, Parmar-Meagher teaches wherein, when the state mode of running instances of the entity is determined to be an active-passive mode, the determined rules for executing the recovery procedure include rules for reconfiguring the subsequent communication by executing a failover procedure to redirect the subsequent communication directed to the entity to an instance of the entity running in another zone of the cloud platform that is not associated with the selected flag (see Parmar, ¶ [0081] and Meagher, ¶ [0056]). Same motivation utilized in claim 8 applies equally as well to claim 13. Regarding claim 14, Parmar-Meagher teaches wherein, when the state mode of running instance of the entity is determined to an active-active state, the determined rules for executing the recovery procedure include rules for reconfiguring the subsequent communication by transmitting requests for services from the entity only to other one or more instances running at one or more zones of the cloud platform, the other one or more zones not being associated with the selected flag (see Parmar, ¶[0071] and Meagher, ¶ [0049]). Same motivation utilized in claim 8 applies equally as well to claim 14. Regarding claim 15, Parmar 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 comprising: receiving a selection of a flag from a set of flags defined at a cloud platform including multiple availability zones, wherein the flag is selected to identify an outage at a first zone of the cloud platform (see Parmar, ¶ [0040] and [0080]; outages are detected using status indicators); determining an instance of an entity running at the first zone of the cloud platform (see Parmar, ¶ [0044]-[0045]; affected components in the zone is determined); determining a state mode of running instances of the entity at the cloud platform; in response to determining the state mode, executing a recovery procedure for the instance of the entity running at the first zone (see Parmar, ¶ [0057]-[0058] and [0080]; recovery procedure is performed); and in response to the determined rules, executing the recovery procedure determined based on to the state mode of running instances of the entity to reconfigure subsequent communication directed to the entity to another one or more instances running at one or more other zones of the cloud platform (see Parmar, ¶ [0047] and [0057]; failed components are reconfigured and replaced). Although Parmar discloses the invention substantially as claimed, it does not explicitly disclose the use of rules to determine recovery. Meagher teaches cloud-based service outage detection system that among other things teach the use of rules to determine recovery (see Meagher, ¶ [0049] and [0056]). It would have been obvious to one of ordinary skill in the art before the effective filling date of the invention to incorporate the teachings of Meagher with that of Parmar in order to ensure consistency, and compliance in restoring systems and operations after an outage incident. Regarding claim 16, Parmar-Meagher teaches wherein the selection of the flag is received to trigger the recovery procedure for instances running at the first zone of the cloud platform and mapped to the flag (see Parmar, ¶ [0058] and [0080]). Regarding claim 17, Parmar-Meagher teaches wherein a plurality of entities is running on the cloud platform, wherein each entity is running with one or more instances distributed over one or more availability zones, and 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 Parmar, ¶ [0035] and [0048]). Regarding claim 18, Parmar-Meagher teaches wherein the plurality of entities includes different cloud component types including applications, services, and databases, 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 Parmar, ¶ [0025] and [0044]). Regarding claim 19, Parmar-Meagher teaches wherein each cloud component type of an entity is associated with a respective state mode of running instances of entities of the type, wherein a state mode of a cloud component type is either an active-active mode or an active-passive mode (see Parmar, ¶ [0071]). Regarding claim 20, Parmar-Meagher teaches wherein, when the state mode of running instances of the entity is determined to be an active-passive mode, the determined rules for executing the recovery procedure include rules for reconfiguring the subsequent communication by executing a failover procedure to redirect the subsequent communication directed to the entity to an instance of the entity running in another zone of the cloud platform that is not associated with the selected flag (see Parmar, ¶[0071] and Meagher, ¶ [0056]). Same motivation utilized in claim 15 applies equally as well to claim 20 . 12-57 AIA Prior Art of Record 07-96 AIA 6. The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure. Please refer to form PTO-892 (Notice of Reference Cited) for a list of relevant prior art . a) US 20210383404 A1 is directed to a method for overcoming a partial failure of an application in a telephony communication system are provided. The method includes: receiving information indicating that a first application has experienced a partial failure; receiving, from each of a plurality of applications, metadata that relates to a corresponding ordered priority of partitions, a corresponding Availability Zone from among a plurality of Availability Zones in which the respective application is located, and a corresponding instance index within the corresponding Availability Zone; sorting the received metadata with respect to the corresponding Availability Zone and with respect to the corresponding instance index; and reassigning, based on a result of the sorting, the first application to an instance index within the Availability Zone in which the first application is located such that a number of the partitions within instance indexes in the corresponding Availability Zone is balanced. b) US 20210133183 A1 is directed to availability zone failures where each region can include multiple (e.g., two or more) availability zones (AZs) connected to one another via a private high-speed network, for example a fiber communication connection. An AZ may provide an isolated failure domain including one or more data center facilities with separate power, separate networking, and separate cooling from those in another AZ. Preferably, AZs within a region are positioned far enough away from one other that a same natural disaster (or other failure-inducing event) should not affect or take more than one AZ offline at the same time. c) US 20200328941 A1 is directed to a system for mapping cloud-based resource modifications in which application that obtains instructions to modify a computing resource provided by the remote computing system and, based on the instructions, generates and transmits, to the remote computing system, a request to modify the computing resource. The application receives, from the remote computing system, a response indicating a modification to the computing resource and selects a discovery pattern configured to verify the modification by obtaining attributes associated therewith. The application obtains, from the remote computing system, the attributes by executing the discovery pattern and determines, based on the attributes, that the modification has been completed according to the instructions. Based on this determination, the application updates the mapping to indicate the modification and stores, in the persistent storage, the mapping as updated . Conclusion 07-101 7. Any inquiry concerning this communication or earlier communications from the examiner should be directed to MOHAMED IBRAHIM whose telephone number is (571)270-1132 . The examiner can normally be reached on Monday through Friday from 9:30AM to 6:00PM . If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, John Follansbee can be reached on 571-272-3964 . The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. 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 . /Mohamed Ibrahim/ Primary Examiner, Art Unit 2444 Application/Control Number: 19/006,466 Page 2 Art Unit: 2444 Application/Control Number: 19/006,466 Page 3 Art Unit: 2444 Application/Control Number: 19/006,466 Page 4 Art Unit: 2444 Application/Control Number: 19/006,466 Page 5 Art Unit: 2444 Application/Control Number: 19/006,466 Page 6 Art Unit: 2444 Application/Control Number: 19/006,466 Page 7 Art Unit: 2444 Application/Control Number: 19/006,466 Page 8 Art Unit: 2444 Application/Control Number: 19/006,466 Page 9 Art Unit: 2444 Application/Control Number: 19/006,466 Page 10 Art Unit: 2444 Application/Control Number: 19/006,466 Page 11 Art Unit: 2444 Application/Control Number: 19/006,466 Page 12 Art Unit: 2444 Application/Control Number: 19/006,466 Page 13 Art Unit: 2444
Prosecution Insights