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 .
DETAILED ACTION
Double Patenting
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 §§ 706.02(l)(1) - 706.02(l)(3) 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 USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The 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/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1-9, 14-18 are rejected on the ground of nonstatutory double patenting as being unpatentable over U.S. Patent No. 12,093,733.
Although the claims at issue are not identical, they are not patentably distinct from each other because: Claims of U.S. Patent Application No. 12,093,733 as shown in the corresponding table below contains every element of Claims 1-20 of the instant application and therefore anticipates the claims.
Present Application No. 18/790,852
1, 9, 18. A system comprising: one or more processors; a memory in communication with the one or more processors storing instructions, that when executed by the one or more processors, are configured to cause the system to:
scan a plurality of distributed cloud servers to identify a plurality of distributed
cloud applications;
identify a first subgroup of the identified plurality of distributed cloud applications comprising a standard cloud environment and a second subgroup of the identified plurality of distributed cloud applications comprising a nonstandard cloud environment;
create a restore point for each distributed cloud application in the identified second subgroup;
convert each distributed cloud application in the identified second subgroup into a
standard cloud environment;
shut down each distributed cloud application of the identified second subgroup;
responsive to shutting down each distributed cloud application of the identified
second subgroup, reinitialize each distributed cloud application of the identified second subgroup at a predetermined time; and
restore each distributed cloud application of the identified second subgroup to the
nonstandard cloud environment based on the created restore points.
2. The system of claim 1, wherein converting each nonstandard cloud environment into
standard cloud environment further comprises determining whether each of the distributed cloud applications of the identified second subgroup comprise either a read-replica cloud environment or a multi-server cloud environment.
3. The system of claim 2, wherein converting each nonstandard cloud environment into a
standard cloud environment further comprises converting each multi-server cloud environment of the identified second subgroup into a single-server cloud environment.
4. The system of claim 2, wherein converting each nonstandard cloud environment into a
standard cloud environment further comprises: identifying a read replica associated with each read-replica cloud environment; and deleting the read replica associated with each read-replica cloud environment.
5. The system of claim 4, wherein identifying the read replica associated with each read-
replica cloud environment further comprises:
scanning each read replica of a plurality of existing read-replicas for a source identifier;
comparing the source identifier to a respective cloud environment identifier associated with each of the distributed cloud applications of the identified second subgroup; and matching the read replica to one of the distributed cloud applications of the identified second subgroup based on the source identifier matching the respective cloud environment identifier beyond a predetermined threshold.
6, 15. The system of claim 1, wherein:
the plurality of distributed cloud applications each comprise a scheduler configuration
file, and intermittently scanning the scheduler configuration files occurs once every fifteen minutes.
7, 16. The system of claim 6, wherein the scheduler configuration files allow the distributed cloud applications to be initialized or shutdown at a time selected from at a beginning of an hour period, 15 minutes past the hour period, 30 minutes past the hour period, or 45 minutes past the hour period.
8, 17. The system of claim 1, wherein the instructions, when executed by the one or more processors, are configured to cause the system to: shut down each distributed cloud application of the identified first subgroup based on a first plurality of predetermined shutdown schedules associated with each distributed application
of the identified first subgroup; reinitialize each distributed cloud application of the identified first subgroup at a predetermined time based on the first plurality of predetermined shutdown schedules (See claim 1 of 12,093,733);
responsive to a successful reinitialization of a respective distributed cloud application,
record a success event to a reporting database confirming that the respective distributed cloud application has been successfully reinitialized; and
responsive to a non-successful reinitialization of a respective distributed cloud application, record a failure event to the reporting database.
U.S. Patent No. 12,093,733
1. A system for managing cloud environments, comprising: one or more processors; a memory in communication with the one or more processors storing instructions, that when executed by the one or more processors are configured to cause the system to:
scan a plurality of distributed cloud servers to identify a plurality of distributed cloud applications comprising a scheduler configuration file; for each distributed cloud application of the identified plurality of distributed cloud applications, determine whether each distributed cloud application comprises a standard cloud environment or a nonstandard cloud environment;
identify a first subgroup of the identified plurality of distributed cloud applications comprising the standard cloud environment and a second subgroup of the identified plurality of distributed cloud applications comprising the nonstandard cloud environment;
shut down each distributed cloud application of the identified first subgroup based on a first plurality of predetermined shutdown schedules associated with each distributed application of the identified first subgroup; reinitialize each distributed cloud application of the identified first subgroup at a predetermined time based on the first plurality of predetermined shutdown schedules;
create a restore point for each distributed cloud application in the identified second subgroup;
convert each distributed cloud application in the identified second subgroup into a standard cloud environment;
shut down each distributed cloud application of the identified second subgroup based on a second plurality of predetermined shutdown schedules associated with each distributed application of the identified second subgroup;
responsive to shutting down each distributed cloud application of the identified second subgroup, reinitialize each distributed cloud application of the identified second subgroup at a predetermined time based on the second plurality of predetermined shutdown schedules; and
restore each distributed cloud application of the identified second subgroup to the nonstandard cloud environment based on the created restore points.
2. The system of claim 1, wherein converting each nonstandard cloud environment into standard cloud environment further comprises determining whether each of the distributed cloud applications of the identified second subgroup comprise either a read-replica cloud environment or a multi-server cloud environment.
3. The system of claim 2, wherein converting each nonstandard cloud environment into a standard cloud environment further comprises converting each multi-server cloud environment of the identified second subgroup into a single-server cloud environment.
4. The system of claim 2, wherein converting each nonstandard cloud environment into a standard cloud environment further comprises: identifying a read replica associated with each read-replica cloud environment; and deleting the read replica associated with each read-replica cloud environment.
5. The system of claim 4, wherein identifying the read replica associated with each read-replica cloud environment further comprises: scanning each read replica of a plurality of existing read-replicas for a source identifier; comparing the source identifier to a respective cloud environment identifier associated with each of the distributed cloud applications of the identified second subgroup; and matching the read replica to one of the distributed cloud applications of the identified second subgroup based on the source identifier matching the respective cloud environment identifier beyond a predetermined threshold.
6. The system of claim 1, wherein intermittently scanning the scheduler configuration files occurs once every fifteen minutes.
7. The system of claim 1, wherein the scheduler configuration files allow the distributed cloud applications to be initialized or shutdown at a time selected from at a beginning of an hour period, 15 minutes past the hour period, 30 minutes past the hour period, or 45 minutes past the hour period.
8. The system of claim 1, wherein the instructions, when executed by the one or more processors are configured to cause the system to:
responsive to a successful reinitialization of a respective distributed cloud application, record a success event to a reporting database confirming that the respective distributed cloud application has been successfully reinitialized; and
responsive to a non-successful reinitialization of a respective distributed cloud application, record a failure event to the reporting database.
Claim Rejections - 35 USC §103
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.
Claim/s 1, 6, 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Obaidi (Pub. No. US 2020/0007385) in view of Dey (Pub. No. US 2017/0185475) in further view of Dunfey (Pub. No. US. 2021/0349748).
Claim 1, 18, Obaidi teaches “a system comprising: one or more processors; a memory in communication with the one or more processors storing instructions, that when executed by the one or more processors, are configured to cause the system to ([0022] processors/memory): scan a plurality of distributed cloud servers to identify a plurality of distributed cloud applications ([0024] As illustrated in FIG. 1, the network resilience system 130 may include several components, such as a node health manager 131, an intrusion detection system 132, a machine learning (ML) anomaly detector 133, and a node restore manager 134. In an embodiment, the node health manager 131 can obtain health status messages periodically transmitted by the nodes 140.); identify a first subgroup of the identified plurality of distributed cloud applications comprising a standard cloud environment and a second subgroup of the identified plurality of distributed cloud applications comprising a nonstandard cloud environment ([0024] For example, the nodes 140 may be configured to periodically generate health status messages and transmit the health status messages to the node health manager 131. A health status message may indicate whether a node 140 is operational. If the node health manager 131 does not receive a health status message from a particular node 140 after a threshold period of time (or if the health status message indicates that the node 140 is not operational), then the node health manager 131 can notify the node restore manager 134 accordingly.); create a restore point for each distributed cloud application in the identified second subgroup ([0025] During the backup process, the separate device or the virtual computing environment 135 can run diagnostics on a backup copy to ensure the backup copy is valid and does not include any malware, viruses, or other malicious code. If the diagnostic clears, then the separate device or the virtual computing environment 135 can store the backup in the data store in an entry associated with the node 140 that was backed up.); convert each distributed cloud application in the identified second subgroup into a standard cloud environment; shut down each distributed cloud application of the identified second subgroup ([0026] Before, during, or after obtaining the most recent backup copy of the node 140 that is deemed compromised or non-operational and/or of the node(s) 140 that did not respond to the acknowledgment request, the node restore manager 134 can delete, from the virtual computing environment 135, the node 140 that is deemed compromised or non-operational and/or of the node(s) 140 that did not respond to the acknowledgment request (e.g., delete the corresponding virtual machine instances). Once deleted, the node restore manager 134 can restart the deleted nodes 140 using the obtained backup copies (e.g., restore a virtual machine instance that hosts the node 140 that is deemed compromised or non-operational using a backup copy and/or restore virtual machine instance(s) that host the node(s) 140 that did not respond to the acknowledgment request using respective backup copies). A backup copy may be an image of a virtual machine instance, and restarting a deleted node 140 can include replacing the image of the virtual machine instance that implemented the now-deleted node 140 with the backup copy image or can include starting a new virtual machine instance different from the virtual machine instance that implemented the now-deleted node 140 using the backup copy image. Alternatively, instead of or in addition to obtaining backup copies, the node restore manager 134 can restart the deleted nodes 140 using virtual machine template files (e.g., generic files that may not include network provider-specific configuration data, but that, when executed to form a virtual machine instance, implement the functionality of the deleted nodes 140). In addition, the node restore manager 134 may require a network administrator to enter different, unique passwords for each of the restarted nodes 140, may restrict what types of users can access the restarted nodes 140, may restrict what types of actions can be performed within the restarted nodes 140 (e.g., set restrictions that prevent the modification of node 140 parameters, set restrictions on which users can update node 140 software, etc.), and/or the like. Thus, the node restore manager 134 can remove a compromised or non-operational node 140 from the core network 110, replacing the compromised or non-operational version of the node 140 with a non-compromised, operational version of the node 140. Examiner notes, Dey teaches a fault may arise from experimental devices vs controlled devices and therefore would be obvious to one of ordinarily skilled in the art, the detected errors of Obaidi are from nonstandard devices [0003] An exemplary computer-implemented method can include detecting one or more faults arising from execution of application instances of a distributed mobile device application among at least a portion of multiple client devices, separating the at least a portion of the multiple client devices into (i) an experimental group and (ii) a control group, and determining one or more user controls of the distributed mobile device application related to the one or more detected faults.)”.)”.
However, the combination may not explicitly teach further limitations.
Dunfey teaches “responsive to shutting down each distributed cloud application of the identified second subgroup, reinitialize each distributed cloud application of the identified second subgroup at a predetermined time; and restore each distributed cloud application of the identified second subgroup to the nonstandard cloud environment based on the created restore points ([0056] In the example of FIG. 5, when an anomaly is detected (e.g., 505 in VM 428), virtual machine controller 430 can configure sandbox 515 to provide a secure, isolated operating environment for virtual machine 502, which is a point-in-time copy of virtual machine 528. In the one embodiment, to provide parallel restoration functionality, virtual machine controller 430 can also configure sandbox 517 to provide a second secure, isolated operating environment for virtual machine 507, which is also a point-in-time copy of virtual machine 528.)”.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Dunfey with the teachings of Obaidi, Dey in order to provide a system that teaches restoring the application to a previous version. The motivation for applying Dunfey teaching with Obaidi, Dey teaching is to provide a system that allows for examination of applications under faulty conditions. Obaidi, Dey, Dunfey are analogous art directed towards application management. Together Obaidi, Dey, Dunfey teach every limitation of the claimed invention. Since the teachings were analogous art known at the filing time of invention, one of ordinary skill could have applied the teachings of Dunfey with the teachings of Obaidi, Dey by known methods and gained expected results.
Claim 6, the combination teaches the claim, wherein Obaidi teaches “The system of claim 1, wherein: the plurality of distributed cloud applications each comprise a scheduler configuration file, and intermittently scanning the scheduler configuration files occurs once every fifteen minutes ([0026] Alternatively, instead of or in addition to obtaining backup copies, the node restore manager 134 can restart the deleted nodes 140 using virtual machine template files (e.g., generic files that may not include network provider-specific configuration data, but that, when executed to form a virtual machine instance, implement the functionality of the deleted nodes 140). [0048] At block 506, a determination is made as to whether health status and/or intrusion data are received from all nodes. If health status and/or intrusion data are received from all nodes, this may indicate that no compromised and/or non-operational nodes are detected and the compromised node detection routine 500 returns to block 504 so that the next set of health status messages and/or intrusion data can be received at a later time for evaluation. However, if health status and/or intrusion data are not received from all nodes, this may indicate that one or more nodes is compromised and/or non-operational and the compromised node detection routine 500 proceeds to block 508.)”.
Claim/s 2 is/are rejected under 35 U.S.C. 103 as being unpatentable over Obaidi, Dey, Dunfey in further view of Dake (Pub. No. US. 2004/0268157).
Claim 2, the combination may not explicitly teach the claim.
Dake teaches “the system of claim 1, wherein converting each nonstandard cloud environment into standard cloud environment further comprises determining whether each of the distributed cloud applications of the identified second subgroup comprise either a read-replica cloud environment or a multi-server cloud environment ([0013] Generally speaking the invention is concerned with restoring and monitoring power states of various modules in a multi-server, shared power environment. When a management module of the system is powered on, it determines whether a management module hot swap has occurred or whether AC power to the entire chassis has been reset. Depending upon this determination, the management module then either restores the power states of the various modules to their last known state or detects the current power states and preserves them for future use. By configuring the management module to perform this power monitoring and restoration function, the invention adds useful and potentially error reducing automation to environments characterized by multiple, interconnected systems sharing a common set of resources including power.)”.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Dake with the teachings of Obaidi, Dey, Dunfey in order to provide a system that teaches determining the environment based upon a failover. The motivation for applying Dake teaching with Obaidi, Dey, Dunfey teaching is to provide a system that allows for examination of applications under faulty conditions. Obaidi, Dey, Dunfey, Dake are analogous art directed towards application management. Together Obaidi, Dey, Dunfey, Dake teach every limitation of the claimed invention. Since the teachings were analogous art known at the filing time of invention, one of ordinary skill could have applied the teachings of Dunfey with the teachings of Obaidi, Dey, Dake by known methods and gained expected results.
Claim/s 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Obaidi (Pub. No. US 2020/0007385) in view of Dey (Pub. No. US 2017/0185475).
Claim 9, Obaidi teaches “a system for managing cloud environments, comprising: one or more processors; a memory in communication with the one or more processors storing instructions, that when executed by the one or more processors, are configured to cause the system to: scan a plurality of distributed cloud servers to identify a plurality of distributed cloud applications ([0024] As illustrated in FIG. 1, the network resilience system 130 may include several components, such as a node health manager 131, an intrusion detection system 132, a machine learning (ML) anomaly detector 133, and a node restore manager 134. In an embodiment, the node health manager 131 can obtain health status messages periodically transmitted by the nodes 140.); identify a first subgroup of the identified plurality of distributed cloud applications comprising a standard cloud environment and a second subgroup of the identified plurality of distributed cloud applications comprising a nonstandard cloud environment ([0024] For example, the nodes 140 may be configured to periodically generate health status messages and transmit the health status messages to the node health manager 131. A health status message may indicate whether a node 140 is operational. If the node health manager 131 does not receive a health status message from a particular node 140 after a threshold period of time (or if the health status message indicates that the node 140 is not operational), then the node health manager 131 can notify the node restore manager 134 accordingly.); for each distributed cloud application of the identified second subgroup: create a restore point comprising initialization parameters associated with a respective distributed cloud application ([0025] During the backup process, the separate device or the virtual computing environment 135 can run diagnostics on a backup copy to ensure the backup copy is valid and does not include any malware, viruses, or other malicious code. If the diagnostic clears, then the separate device or the virtual computing environment 135 can store the backup in the data store in an entry associated with the node 140 that was backed up.); convert the nonstandard cloud environment into a standard cloud environment; and execute a shutdown routine ([0026] Before, during, or after obtaining the most recent backup copy of the node 140 that is deemed compromised or non-operational and/or of the node(s) 140 that did not respond to the acknowledgment request, the node restore manager 134 can delete, from the virtual computing environment 135, the node 140 that is deemed compromised or non-operational and/or of the node(s) 140 that did not respond to the acknowledgment request (e.g., delete the corresponding virtual machine instances). Once deleted, the node restore manager 134 can restart the deleted nodes 140 using the obtained backup copies (e.g., restore a virtual machine instance that hosts the node 140 that is deemed compromised or non-operational using a backup copy and/or restore virtual machine instance(s) that host the node(s) 140 that did not respond to the acknowledgment request using respective backup copies). A backup copy may be an image of a virtual machine instance, and restarting a deleted node 140 can include replacing the image of the virtual machine instance that implemented the now-deleted node 140 with the backup copy image or can include starting a new virtual machine instance different from the virtual machine instance that implemented the now-deleted node 140 using the backup copy image. Alternatively, instead of or in addition to obtaining backup copies, the node restore manager 134 can restart the deleted nodes 140 using virtual machine template files (e.g., generic files that may not include network provider-specific configuration data, but that, when executed to form a virtual machine instance, implement the functionality of the deleted nodes 140). In addition, the node restore manager 134 may require a network administrator to enter different, unique passwords for each of the restarted nodes 140, may restrict what types of users can access the restarted nodes 140, may restrict what types of actions can be performed within the restarted nodes 140 (e.g., set restrictions that prevent the modification of node 140 parameters, set restrictions on which users can update node 140 software, etc.), and/or the like. Thus, the node restore manager 134 can remove a compromised or non-operational node 140 from the core network 110, replacing the compromised or non-operational version of the node 140 with a non-compromised, operational version of the node 140.) based on a plurality of second schedules associated with each distributed cloud application of the identified second subgroup ([0014] For example, the nodes can periodically transmit to the network resilience system a health status message that indicates whether the respective node is operational. If the network resilience system does not receive a health status message from a particular node after a threshold period of time, then the network resilience system can attempt to contact the node from which the health status message was not received. Examiner notes, Dey teaches a fault may arise from experimental devices vs controlled devices and therefore would be obvious to one of ordinarily skilled in the art, the detected errors of Obaidi are from nonstandard devices [0003] An exemplary computer-implemented method can include detecting one or more faults arising from execution of application instances of a distributed mobile device application among at least a portion of multiple client devices, separating the at least a portion of the multiple client devices into (i) an experimental group and (ii) a control group, and determining one or more user controls of the distributed mobile device application related to the one or more detected faults.)”.
Claim/s 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Obaidi, Dey, Dunfey in further view of Ganteaume (Pub. No. US 2019/0340190).
Claim 7, the combination may not explicitly teach the limitation.
Ganteaume teaches “the system of claim 6, wherein the scheduler configuration files allow the distributed cloud applications to be initialized or shutdown at a time selected from at a beginning of an hour period, 15 minutes past the hour period, 30 minutes past the hour period, or 45 minutes past the hour period ([0037] That is, in this example, at each hour starting at noon each Sunday, a new VM may be started)”.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Ganteaume with the teachings of Obaidi, Dey, Dunfey in order to provide a system that teaches different times of restarts. The motivation for applying Ganteaume teaching with Obaidi, Dey, Dunfey teaching is to provide a system that allows for design choice. Obaidi, Dey, Dunfey, Ganteaume are analogous art directed towards application management. Together Obaidi, Dey, Dunfey, Ganteaume teach every limitation of the claimed invention. Since the teachings were analogous art known at the filing time of invention, one of ordinary skill could have applied the teachings of Ganteaume with the teachings of Obaidi, Dey, Dunfey by known methods and gained expected results.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to WYNUEL S AQUINO whose telephone number is (571)272-7478. The examiner can normally be reached 9AM-5PM EST M-F.
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, Lewis Bullock can be reached at 571-272-3759. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/WYNUEL S AQUINO/Primary Examiner, Art Unit 2199
Prosecution Insights