DETAILED ACTION
This Office Action is sent in response to Applicant’s Communication received 02/19/2025 for application number 19/057,854. The Office hereby acknowledges receipt of the following and placed of record in file: Specification, Claims, Drawings, Abstract, Oath/Declaration, IDS, and Certified Copy of Foreign Priority Application.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Objections
Claims 1 and 5 are objected to because of the following informalities:
Claim 1, lines 3-4 recite, “a network interconnects the active system, the first standby system and an administrator terminal,” should read, “a network interconnects the active system, the first standby system, and an administrator terminal” (emphasis added). The Oxford comma clarifies that the network interconnects the active system, the first standby system, and an administrator terminal as three separate units, rather than the first standby system and the administrator terminal as one unit interconnecting with the active system.
Claim 5, lines 12-13 recite, “change, when it is determined that the one selected as the switchover destination is configured to operate normally” (emphasis added), should read, “change, when it is determined that the one selected as the switchover destination cannot operate normally” (emphasis added). Support for this objection can be found on page 15, lines 2-9.
Appropriate correction is required.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) 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 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, 6, and 7 are rejected under 35 U.S.C. 103 as being unpatentable over SAMPATH et al., US 2025/0077300 A1 (SAMPATH ‘300), in view of SAMPATH et al., US 2015/0317220 A1 (SAMPATH ‘220), further in view of LUI et al., US 2018/0025066 A1, and further in view of DORNEMANN et al., US 2017/0168903 A1.
Regarding Claim 1, SAMPATH ‘300 discloses:
A switchover control system for controlling switchover from an active system to a first standby system in a cloud system (Fig. 1 illustrates a cloud system that includes two cloud regions 110 and 120; [0029] discloses the two regions may be a primary region and a standby region (i.e. a cloud system with an active system and a standby system)),
an already activated active virtual server on which one or more active applications operate ([0061] discloses stopping one or more compute instances (i.e. a virtual server) in a primary region (i.e. the active site) stops the application in the primary region from executing during the switchover (i.e. prior to the switchover, the primary region has an already active virtual server that the active applications are operating on)),
an active database configured to read and write data based on instructions ([0054] discloses a recovery plan generator 130 generates a recovery plan for cloud resources indicated in an RPG based on characteristics (of those cloud resources) indicated in an entry for the RPG in the RPG database 116 (i.e. the active database writing RPG entry data); the recovery plan generator 130 identifies the particular type indicated in the action of the recovery template, searches an entry in RPG database 116 (i.e. database reading data for the RPG) for a cloud resource that is of the particular type, retrieves the name, identifier, and pertinent recovery data for that cloud resource from the entry, and inserts the location and name, identifier, and pertinent recovery data in a portion of that action in the recovery template, which becomes part of the resulting recovery plan),
execute virtual server activation processing for activating the first standby virtual server ([0061] discloses a launch compute instance step, which launches one or more compute instances (i.e. a virtual server) in the standby region, and may involve attaching those compute instances to an application in the standby region (i.e. activating a standby virtual server)),
execute application activation processing for activating the one or more first standby applications on the first standby virtual server ([0060] discloses bringing up or starting the application on the one or more compute instances (i.e. a virtual server), all in the standby region (i.e. activating an application on the first standby virtual servers)),
execute communication target switching processing for switching a target of communication to and from one or more client terminals from the active system to the first standby system ([0079] discloses a DNS update step in the recovery plan that involves causing a domain name service (DNS)) entry at a DNS server to be updated to replace the IP address of an application end-point in the primary region with an IP address of the recovered application end-point in the standby region (i.e. switching the target of communication from primary region to standby region)),
wherein the database setting processing, the virtual server activation processing, the application activation processing, and the communication target switching processing are included in switchover processing, and are executed in the stated order in response to reception of the execution request ([0074] discloses a user may provide input that selects a recovery plan or selects a recovery protection group (RPG) and a specific recovery operation, such as a switchover operation (i.e. an execution request is sent out); [0061] discloses in executing the switchover includes a database switchover step, which makes an existing standby database an active database and an active database a standby database (i.e. performing the database setting processing); a launch compute instance step, which launches one or more compute instances in the standby region, and may involve attaching those compute instances to an application in the standby region (i.e. performing a virtual server activation processing after setting the database); [0060] discloses that after allocating one or more compute instances, that the application on the one or more compute instances can be brought up or started (i.e. after performing a virtual server activation processing, the application is brought up for that virtual server); [0079] discloses a DNS update step in the recovery plan that involves causing a domain name service (DNS)) entry at a DNS server to be updated to replace the IP address of an application end-point in the primary region with an IP address of the recovered application end-point in the standby region (i.e. performing the communication target switching processing)).
SAMPATH ‘300 does not explicitly disclose a system in which interconnects the active system, the first standby system and an administrator terminal,
the active system deployed at an active site,
an active database configured to read and write data based on instructions from the one or more active applications;
an unactivated first standby virtual server in which one or more first standby applications are deployed, the one or more first standby applications being copies of the one or more active applications;
a first standby database which synchronizes data with the active database;
the administrator terminal deployed at a management site different from the active site,
the switchover control system being deployed at one or more sites different from the active site,
the switchover control system comprising at least one processor configured to:
receive an execution request for the switchover transmitted from the administrator terminal; and
execute database setting processing for setting the first standby database so that data synchronization between the active database and the first standby database is stopped, and so that writing data based on the instructions from the one or more first standby applications is enabled, and for setting the active database so that writing data based on the instructions from the one or more active applications is disabled.
However, SAMPATH ‘220 teaches a system in which interconnects the active system, the first standby system and an administrator terminal (Fig. 2A and Fig. 2B illustrates a switchover control system for controlling switchover from a primary site 210 (Fig. 2A) (i.e. the primary system exists within the primary site) to a standby site 260 (Fig. 2B) (i.e. the standby system exists within the standby site), where the internet 204 (Fig. 2A) and global redirector 206 interconnects the primary site 210, standby site 260, and a control console 252 (Fig. 2A) (i.e. an administrator terminal)),
the active system deployed at an active site (Fig. 2A illustrates primary site 210 that includes the components of a primary system; [0043] teaches 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) (i.e. the primary site 210 is currently the active system)),
the first standby system deployed at a first standby site different from the active site ([0025] teaches multi-tier application components running at one site (a “primary site”) may replicate data to one or more geographically different sites (“standby sites”) (i.e. the standby site is at a site different from the primary site)),
one or more first standby applications are deployed, the one or more first standby applications being copies of the one or more active applications ([0026] teaches the primary site replicates data to a standby site by sending the standby site a current copy of the data; the data that is replicated from primary site to standby site may vary and may include application data, metadata, configuration data, database data, and security data (i.e. the standby site can have current copies of the applications running in the primary site)),
a first standby database which synchronizes data with the active database (Fig. 2A and Fig. 2B illustrate database 249 (Fig. 2A) (i.e. the database inside primary site 210) and database 299 (Fig. 2B) (i.e. the database inside the standby site 260); [0026] teaches the primary site replicates data to a standby site by sending the standby site a current copy of the data; the data that is replicated from primary site to standby site may vary and may include application data, metadata, configuration data, database data, and security data (i.e. the primary site can replicate database date to the standby site); [0027] teaches replication may be performed periodically, on-demand, or continuously (i.e. the first database is synchronized with the primary database)),
the administrator terminal deployed at a management site different from the active site ([0016] teaches if the primary site becomes unavailable due to a planned or an unplanned outage, the steps of the disaster recovery plan may be processed by the disaster recovery system to perform a site switchover or failover operation; [0035] teaches a disaster recovery system 250 that comprises the management console 252 (i.e. the administrator terminal) and management host 254; the disaster recovery system 250 may be communicatively coupled to primary site 210 and standby site 260 by a leased line, one or more private networks, and/or one or more public networks, such as internet 204 (i.e. the disaster recovery system 250 can be located at a different site and can communicate to both the active site and the standby site through the network); [0043] teaches clients 202 a to 202 n represent one or more clients that may access primary site 210 and standby site 260 through Internet 204),
the switchover control system being deployed at one or more sites different from the active site ([0035] teaches a disaster recovery system 250 that comprises the management console 252 (i.e. the administrator terminal) and management host 254; the disaster recovery system 250 may be communicatively coupled to primary site 210 and standby site 260 by a leased line, one or more private networks, and/or one or more public networks, such as internet 204 (i.e. the disaster recovery system 250 can communicate to the standby site aside from the active site); [0043] teaches clients 202 a to 202 n represent one or more clients that may access primary site 210 and standby site 260 through Internet 204),
the switchover control system comprising at least one processor ([0035] teaches the disaster recovery system 250 generally comprises management console 252 and management host 254. Management console 252 includes a user interface that allows a user to monitor and administer the disaster recovery system from one location on a network. Management host 254 includes management services 255 for managing targets on primary site 210 and standby site 260, disaster recovery services 256 for managing site switchovers and/or failovers, and data repository 257 for storing management and/or disaster recovery data; the disaster recovery system 250 may be communicatively coupled to primary site 210 (i.e. the active site) and standby site 260 (i.e. the standby site) by a leased line, one or more private networks, and/or one or more public networks, such as internet 204; [0155] teaches a computer system 700 having a hardware processor 704 and main memory 706, wherein the main memory 706 causes the hardware processor 704 to perform the process steps described in the invention (i.e. the switchover control system perform)),
receive an execution request for the switchover transmitted from the administrator terminal ([0035] teaches management/control console 252 includes a user interface that allows a user to monitor and administer the disaster recovery system from one location on a network (i.e. the disaster recovery system receives an execution request from the user through the management/control console)).
Accordingly, it would have been obvious to a person having ordinary skill in the art, having the teachings of SAMPATH ‘300 and SAMPATH ‘220 before him before the effective filing date of the claimed invention, to incorporate a switchover system from a primary site to a standby with an administrator terminal as taught by SAMPATH ‘220 into a cloud switchover system between a primary site and a standby site disclosed by SAMPATH ‘300 to allow the administrator to take corrective action appropriately when a problem is encountered and reported (SAMPATH ‘220 [0018]).
The combination of SAMPATH ‘300 and SAMPATH ‘220 do not explicitly disclose an active database configured to read and write data based on instructions from the one or more active applications,
an unactivated first standby virtual server in which one or more first standby applications are deployed, the one or more first standby applications being copies of the one or more active applications;
execute database setting processing for setting the first standby database so that data synchronization between the active database and the first standby database is stopped, and so that writing data based on the instructions from the one or more first standby applications is enabled, and for setting the active database so that writing data based on the instructions from the one or more active applications is disabled.
However, LUI teaches an active database configured to read and write data based on instructions from the one or more active applications ([0028] teaches applications executed at the application servers communicate read and write (R/W) requests to a primary database (i.e. the active database is able to read and write based on the requests (i.e. instructions) communicated by the active applications)),
execute database setting processing for setting the first standby database so that data synchronization between the active database and the first standby database is stopped, and so that writing data based on the instructions from the one or more first standby applications is enabled, and for setting the active database so that writing data based on the instructions from the one or more active applications is disabled ([0037] teaches the replication (i.e. data synchronization) from the master copy of the database 240 (i.e. the active database) to the slave copy of the database 242 (i.e. the first standby database) is stopped; [0038] teaches the process continues with switching of the database connections, so that database connections are directed to the slave copy of the database 242 (now called the new master copy of the database) instead of the master copy of the database 240 (now called the new slave copy of the database); [0039] teaches the new master copy of the database 242 is set to a read-write mode (i.e. the first standby database has read/write enabled), and the new slave copy of the database 240 is set to a read-only mode (i.e. the active system can only read, the writing has been disabled); [0040] teaches that the web application servers and client devices can continue to perform database operations, via database connections, including operations that read and/or write database data during the switchover of the databases (i.e. the first standby database having read/write enabled has the web application servers and the client devices performing database operations towards the first standby database)).
Accordingly, it would have been obvious to a person having ordinary skill in the art, having the teachings of SAMPATH ‘300, SAMPATH ‘220, and LUI before him before the effective filing date of the claimed invention, to incorporate the method of switching an active and standby database as taught by LUI into the switchover control system disclosed by SAMPATH ‘300 and SAMPATH ‘220 to minimize the chance of a problem occurring within the database environment during the update (e.g., minimize the change of any database writes being lost or database connections failing) (LUI [0019]).
The combination of SAMPATH ‘300, SAMPATH ‘220, and LUI do not explicitly disclose an unactivated first standby virtual server in which one or more first standby applications are deployed, the one or more first standby applications being copies of the one or more active applications.
However, DORNEMANN teaches an unactivated first standby virtual server in which one or more first standby applications are deployed, the one or more first standby applications being copies of the one or more active applications (Fig. 6 illustrates step 602 and step 604, where a full backup of source data is copied and transmitted to the destination storage before configuring the destination client VM at destination in step 606; [0331] teaches the destination client VM (i.e. a first standby virtual server) on destination client computing device 202-D is established, i.e., configured with proper configuration parameters but not powered up (activated) as yet (i.e. the first standby virtual server is not activated); [0372] teaches backing up a first virtual machine (i.e. the active virtual machine) that hosts a first application (i.e. active application) to a backup copy; synchronizing the second virtual machine (i.e. standby virtual machine) to the first virtual machine, comprising: periodically backing up the first virtual machine to successive incremental backup copies, thereby making the second virtual machine ready to host a copy of the first application, in place of the first application hosted by the first virtual machine, based on the most recent incremental backup copy of the first virtual machine restored to the second virtual machine (i.e. the unactivated standby virtual server has copies of applications from the active server); [0375] teaches wherein the second virtual machine operates as a failover destination for the first virtual machine (i.e. the second virtual machine is where the destination client virtual machine is)).
Accordingly, it would have been obvious to a person having ordinary skill in the art, having the teachings of SAMPATH ‘300, SAMPATH ‘220, LUI, and DORNEMANN before him before the effective filing date of the claimed invention, to incorporate an unactivated standby virtual server prior to the switchover having copies of the application from the active virtual server as taught by DORNEMANN into the switchover control system disclosed by SAMPATH ‘300, SAMPATH ‘220, and LUI to prevent long durations of restoring data at a failover destination after a catastrophic failure in a production system (DORNEMANN [0004]).
Regarding Claim 6, SAMPATH ‘300 discloses:
A switchover control method for executing, by a computer (Fig. 3A illustrates steps of a switchover control; Fig. 11 illustrates a computer system 1100; [0129] discloses the computer system 1100 upon which an embodiment of the invention may be implemented (i.e. a computer executing the switchover steps)).
SAMPATH ‘300 does not explicitly disclose a computer deployed at one or more sites different from an active site.
However, SAMPATH ‘220 teaches a computer deployed at one or more sites different from an active site ([0035] teaches a disaster recovery system 250 that comprises the management console 252 (i.e. the administrator terminal) and management host 254; the disaster recovery system 250 may be communicatively coupled to primary site 210 and standby site 260 by a leased line, one or more private networks, and/or one or more public networks, such as internet 204 (i.e. the disaster recovery system 250 can be located at a different site and can communicate to both the active site and the standby site through the network); [0043] teaches clients 202 a to 202 n represent one or more clients that may access primary site 210 and standby site 260 through Internet 204).
The remainder of Claim 6 recites limitations similar to those of Claim 1 and is rejected accordingly.
Regarding Claim 7, SAMPATH ‘300 discloses:
A non-transitory computer readable storage medium having stored thereon a program for causing a computer deployed at one or more sites to execute control of switchover (Fig. 3A illustrates steps of a switchover control; Fig. 11 illustrates a computer system 1100; [0129] discloses the computer system 1100 upon which an embodiment of the invention may be implemented (i.e. a computer executing the switchover steps); [0130] discloses main memory 1106 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 1104. Such instructions, when stored in non-transitory storage media accessible to processor 1104, render computer system 1100 into a special-purpose machine that is customized to perform the operations specified in the instructions).
SAMPATH ‘300 does not explicitly disclose a computer deployed at one or more sites different from an active site.
However, SAMPATH ‘220 teaches a computer deployed at one or more sites different from an active site ([0035] teaches a disaster recovery system 250 that comprises the management console 252 (i.e. the administrator terminal) and management host 254; the disaster recovery system 250 may be communicatively coupled to primary site 210 and standby site 260 by a leased line, one or more private networks, and/or one or more public networks, such as internet 204 (i.e. the disaster recovery system 250 can be located at a different site and can communicate to both the active site and the standby site through the network); [0043] teaches clients 202 a to 202 n represent one or more clients that may access primary site 210 and standby site 260 through Internet 204).
The remainder of Claim 7 recites limitations similar to those of Claim 1 and is rejected accordingly.
Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over SAMPATH ‘300, in view of SAMPATH ‘220, LUI, and DORNEMANN, and further in view of BHATTACHARYYA et al., US 12,265,858 B1.
Regarding Claim 2, SAMPATH ‘300, SAMPATH ‘220, LUI, and DORNEMANN disclose the switchover control system of Claim 1.
SAMPATH ‘300 further discloses an active system and a plurality of sites ([0039] discloses a recovery protection group may identify which region is a primary region for cloud resources and may also identify multiple standby regions (i.e. a plurality of sites)).
The combination of SAMPATH’ 300, SAMPATH ‘220, LUI, and DORNEMANN do not explicitly disclose monitoring an active system from a site to check whether the active system is operating normally,
determine whether the active system is operating normally based on results of monitoring the active system from a site, and, when it is determined that the active system is operating normally, cancel execution of the database setting.
However, BHATTACHARYYA teaches monitor the active system from a site to check whether the active system is operating normally (Fig. 6A illustrates two sites 606 and 605, with site 606 including an active cluster manager (CM) 608, search heads, forwarders, and indexers (i.e. components of the active system); site 605 includes standby cluster manager (CM) 609, search heads, forwarders, and indexers (i.e. components of the standby system); C26:L22-29 teaches once the standby CM (i.e. component of the standby system at the standby site) has received all the ping responses from the indexers, the standby CM uses the information (i.e. the standby CM can monitor the active CM through the results of the ping responses) to determine whether it should replace the active CM (i.e. component of the active system at the active site) as the new active CM; if the ping status for at least one of the indexers is a “success,” it is indicated that at least one indexer was able to confirm that the active CM is still online (i.e. the active system is operating normally if it is online)),
determine whether the active system is operating normally based on results of monitoring the active system from a site, and, when it is determined that the active system is operating normally, cancel execution of the database setting (C26:L22-29 teaches once the standby CM (i.e. component of the standby system at the standby site) has received all the ping responses from the indexers, the standby CM uses the information to determine whether it should replace the active CM (i.e. component of the active system at the active site) as the new active CM; if the ping status for at least one of the indexers is a “success,” indicating that at least one indexer was able to confirm that the active CM is still online, the standby CM may abort any attempt to take over as the new active CM (i.e. determining that the active system is operating normally, cancel the switch in databases); C19:L8 teaches data processed and stored by an indexer (i.e. the indexer is considered to be a database and replacing which cluster manager to be active would change where the data is stored and processed (i.e. database setting)).
Accordingly, it would have been obvious to a person having ordinary skill in the art, having the teachings of SAMPATH ‘300, SAMPATH ‘220, LUI, DORNEMANN, and BHATTACHARYYA before him before the effective filing date of the claimed invention, to incorporate aborting attempts to switch from a standby to an active when the active system is operating normally as taught by BHATTACHARYYA into the switchover control system disclosed by SAMPATH ‘300, SAMPATH ‘220, LUI, and DORNEMANN to avoid significant delays (BHATTACHARYYA (C26:L11-12)).
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over SAMPATH ‘300, in view of SAMPATH ‘220, LUI, and DORNEMANN, and further in view of RAUT et al., US 9,424,152 B1.
Regarding Claim 3, SAMPATH ‘300, SAMPATH ‘220, LUI, and DORNEMANN disclose the switchover system of Claim 1.
SAMPATH ‘300 further discloses the cloud system (Fig. 1 illustrates a cloud system that includes two cloud regions 110 and 120).
SAMPATH ‘220 further teaches wherein the system further includes a standby system which is deployed at a standby site different from the active site and from the first standby site ([0025] teaches multi-tier application components running at one site (“a primary site”) may replicate data to one or more geographically different sites (“standby sites”) (i.e. there can be more than one standby sites that are geographically located differently from the active and other standby sites) to protect against data loss and to allow for application relocation to the standby site).
DORNEMANN further teaches an unactivated standby virtual server in which one or more standby applications are deployed, the one or more standby applications being copies of the one or more active applications ([0331] teaches the destination client VM (i.e. a standby virtual server) on destination client computing device 202-D is established, i.e., configured with proper configuration parameters but not powered up (activated) as yet (i.e. the standby virtual server is not activated); [0372] teaches backing up a first virtual machine (i.e. the active virtual machine) that hosts a first application (i.e. active application) to a backup copy; synchronizing the second virtual machine (i.e. standby virtual machine) to the first virtual machine, comprising: periodically backing up the first virtual machine to successive incremental backup copies, thereby making the second virtual machine ready to host a copy of the first application, in place of the first application hosted by the first virtual machine, based on the most recent incremental backup copy of the first virtual machine restored to the second virtual machine (i.e. the unactivated standby virtual server has copies of applications from the active server)).
The combination of SAMPATH ‘300, SAMPATH ‘220, LUI, and DORNEMANN do not explicitly disclose wherein the system further includes a second standby system which is deployed at a second standby site different from the active site and from the first standby site,
a standby virtual server in which one or more second standby applications are deployed, the one or more second standby applications being copies of the one or more active applications,
a second standby database which synchronizes data with the active database,
wherein the switchover control system is configured to control switchover from the active system to one of the first standby system and the second standby system,
wherein the at least one processor is configured to select one of the first standby system and the second standby system as a switchover destination.
However, RAUT teaches wherein the system further includes a second standby system which is deployed at a second standby site different from the active site and from the first standby site (Fig. 3 illustrates a production site 310 (i.e. the active site including an active system) connected to three disaster recovery sites 330, 340, and 350 through network 320 (i.e. a first, second, and third standby site having a respective standby system); C7:L34-36 teaches each of the disaster recovery sites 330, 340, and 350 may be arranged locally or at a geographic distance from the production site 310 (i.e. the standby systems are deployed at a site different from the active site)),
a standby virtual server in which one or more second standby applications are deployed, the one or more second standby applications being copies of the one or more active applications (C7:L21-33 teaches the production site 310 may be server 140A and the disaster recovery sites 330, 340, and 350 may be any one of servers 140B-140N; each of the disaster recover sites 330, 340, and 350 may provide failover for the multi-tier applications at the production site 310; in the multi-tiered application environment (e.g., a web tier, an application tier, and a database tier), the disaster recovery sites 330, 340, and 350 may replicate data of at least on tier (e.g., the database tier) for failover (i.e. more than one standby sites can copies of applications and/or databases); C8:L41-44 teaches the production site 310 and the disaster recovery sites 330, 340, and 350 may be configured according to a virtualized environment (i.e. the sites may where the multi-tier applications are working on may be on a virtual server)),
a second standby database which synchronizes data with the active database (C7:L21-33 teaches the production site 310 (i.e. the active database) may be server 140A and the disaster recovery sites 330, 340, and 350 may be any one of servers 140B-140N; each of the disaster recover sites 330, 340, and 350 may provide failover for the multi-tier applications at the production site 310; in the multi-tiered application environment (e.g., a web tier, an application tier, and a database tier), the disaster recovery sites 330, 340, and 350 may replicate data of at least on tier (e.g., the database tier) for failover (i.e. more than one standby sites can copies of applications and/or databases)),
wherein the switchover control system is configured to control switchover from the active system to one of the first standby system and the second standby system (C9:L33-41 teaches the disaster recovery sites 330, 340, 350 are ranked by priority scores and the order of priority can change depending on which disaster recover sites are available for the failover (i.e. the switchover from the active to the different standby systems are controlled by rankings)),
wherein the at least one processor is configured to select one of the first standby system and the second standby system as a switchover destination (Fig. 2 illustrates a computer system 200 in accordance with the embodiment of the present disclosure having a central processor 214 (i.e. at least one processor); C13:L2 teaches if all three disaster recovery sites (i.e. three standby sites) are available and disaster recovery site 350 has the highest score, disaster recovery site 330 has the lowest score, and that disaster recovery site 340 has the intermediate score, the order may be updated so that the failover may point to 1.) disaster recovery site 350, 2.) disaster recovery site 340, and 3.) disaster recover site 330 (i.e. the selection of standby systems as the switchover destination can differ based on ranking); C13:L7-12 teaches the user may manually modify the failover priority order of the disaster recovery sites in the failover policy (i.e. the user can also manually select between a first, second, or third standby system)).
Accordingly, it would have been obvious to a person having ordinary skill in the art, having the teachings of SAMPATH ‘300, SAMPATH ‘220, LUI, DORNEMANN, and RAUT before him before the effective filing date of the claimed invention, to incorporate configurations to select between multiple standby sites when controlling a switchover from an active site as taught by RAUT into the switchover control system disclosed by SAMPATH ‘300, SAMPATH ‘220, LUI, and DORNEMANN to automate establishing a failover policy to save users time and to always select the best disaster recovery site as it changes over time (RAUT [C1:L26-28]).
Claims 4 is rejected under 35 U.S.C. 103 as being unpatentable over SAMPATH ‘300, in view of SAMPATH ‘220, LUI, DORNEMANN, and RAUT, and further in view of SUN et al., US 2018/0159924 A1.
Regarding Claim 4, SAMPATH ‘300, SAMPATH ‘220, LUI, DORNEMANN, and RAUT disclose the switchover control system of Claim 3.
RAUT further teaches one of the first standby system and the second standby system that is deployed at a site (Fig. 3 illustrates a production site 310 (i.e. the active site including an active system) connected to three disaster recovery sites 330, 340, and 350 through network 320 (i.e. a first, second, and third standby site having a respective standby system); C7:L34-36 teaches each of the disaster recovery sites 330, 340, and 350 may be arranged locally or at a geographic distance from the production site 310 (i.e. the standby systems are deployed at a site different from the active site)).
The combination of SAMPATH ‘300, SAMPATH ‘220, LUI, DORNEMANN, and RAUT do not explicitly disclose further comprising a storage configured to store access information indicating, for each of a plurality of regions, a number of accesses to the active system from the each of the plurality of regions,
wherein the at least one processor is configured to select, as the switchover destination, based on the access information, one of the standby systems that is deployed at a site included in one of the plurality of regions higher in the number of accesses to the active system.
However, SUN teaches further comprising a storage configured to store access information indicating, for each of a plurality of regions, a number of accesses to the active system from the each of the plurality of regions (Fig. 1 illustrates three data centers 112, 114, and 116 (i.e. a plurality of regions or sites) connected to a plurality of client devices 132, 134, 136 and 138 through network 120 [0013] teaches an “entity” is a data object or a service that should only be accessed at a single data center (i.e. an active system accessed at the active site) and not multiple data centers. Thus, while an instance of entity may exist in multiple data centers (e.g., for failover reasons) (i.e. an active system having standby systems at different standby sites), the entity is only assigned to that data center (i.e., the “home” data center for that entity). Any requests for the entity need to be made through the home data center (i.e. accessing the active system is only at the active site; tracking the number of times the entity is accessed thus also tracks the number of times the “home” data center on which the entity resides is being accessed); [0016] teaches for example, a request (for an entity) received by a first data center is forwarded to the second data center to which the entity is assigned (i.e. the second data center is the active site, and users are accessing the entity through the first data center, which is not the active site); [0037] teaches usage of an entity (i.e. the active system) by a set of users is tracked and used to determine which data center to assign the entity and is based on one or more factors, such as a number of times each user in the set of users has accessed the entity (i.e. for each of a plurality of regions, the number of accesses in the active system is tracked); [0038] teaches for example, client device 132 accessed a particular entity 20 times, client device 134 accessed the particular entity 16 times, and client device 136 accessed the particular entity 33 times. If client device 136 and either client device 132 or client device 134 are associated with data center 114, then the particular entity is assigned data center 114. If client devices 132 and 134 are associated with data center 112 and only client device 136 is associated with data center 114, then the particular entity is assigned to data center 112 (i.e. data center 112 had the highest number of accesses at 36, therefore the new “home” data center for the entity is data center 112); [0071] teaches a computer system 300 upon which an embodiment of the invention may be implemented; [0072] teaches computer system 300 also includes a main memory 306, such as a random access memory (RAM) or other dynamic storage device, coupled to bus 302 for storing information and instructions to be executed by processor 304 (i.e. the ability to track the usage data to later analyze it to choose an appropriate data center would require storage and a processor)),
wherein the at least one processor is configured to select, as the switchover destination, based on the access information, one of the standby systems that is deployed at a site included in one of the plurality of regions higher in the number of accesses to the active system ([0053] teaches the data center (i.e. from the different data centers illustrated in Fig. 1) associated with the largest usage amount (i.e. selecting the destination with the higher number of accesses) is selected as the data center to which the entity is to be assigned (i.e. assigning the data center with an instance of the entity and the most number of accesses as the new “home” data center for the entity is the same as assigning a standby system deployed at a site with the highest number of accesses as the new active system).
Accordingly, it would have been obvious to a person having ordinary skill in the art, having the teachings of SAMPATH’ 300, SAMPATH ‘220, LUI, DORNEMANN, RAUT, and SUN before him before the effective filing date of the claimed invention, to incorporate choosing a standby site as a switchover destination based on the highest number of accesses from that site to the active system as taught by SUN into the switchover control system disclosed by SAMPATH ‘300, SAMPATH ‘220, LUI, DORNEMANN, and RAUT to reduce access times (or latency) for many users (SUN [0016]).
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over SAMPATH ‘300, in view of SAMPATH ‘220, LUI, DORNEMANN, and RAUT, and further in view of YAKO et al., US 2005/0267904 A1.
Regarding Claim 5, SAMPATH ‘300, SAMPATH ‘220, LUI, DORNEMANN and RAUT disclose the switchover control system of Claim 3.
SAMPATH ‘300 further discloses the switchover destination is configured to operate normally, in at least one of the execution of the database setting processing and the execution of the application activation processing executed for at least some of the one or more first standby applications ([0061] discloses executing the switchover includes a database switchover step, which makes an existing standby database an active database and an active database a standby database (i.e. standby database is operating normally by performing the database setting processing)),
The combination of SAMPATH ‘300, SAMPATH ‘220, LUI, DORNEMANN, and RAUT do not explicitly disclose wherein the at least one processor is configured to:
acquire operation information indicating whether the first standby system is configured to operate normally,
determine, based on the operation information, whether one of the first standby system and the second standby system that is selected as the switchover destination is configured to operate normally; and
change, when it is determined that the one selected as the switchover destination cannot operate normally, the switchover destination to another of the first standby system and the second standby system, and re-execute the switchover processing from start.
However, YAKO teaches wherein the at least one processor is configured to: acquire operation information indicating whether the first standby system is configured to operate normally (Fig. 3 illustrates a diagram of the computer systems used in the embodiments, where information processors 300, 3100, and 3200 include a CPU 3002 (i.e. a processor); [0059] teaches the system-monitor system-switchover control mechanism 5 that monitors the operating condition (i.e. the operation information) of the database management system 2 (i.e. unit 1, unit 2, or unit 3 as shown in Fig. 1); ; [0073] teaches obtaining the name of a server destination unit (i.e. the first standby system or the second standby system) and determining whether the obtained unit (i.e. the server destination unit) is at present in operation and so is available (i.e. determining the unit is in operation and is available indicates that information was acquired based on the results from the system-monitor system-switchover control mechanism 5)),
determine, based on the operation information, whether one of the first standby system and the second standby system that is selected as the switchover destination is configured to operate normally (Fig. 1 illustrates DBMS units 1, 2, and 3; where unit 2 is failed (i.e. unit 2 is the active system, and units 1 and 3 are the first and second standby systems); there is a server destination-in-failure information block 30 that shows the list of switchover destinations for the components during time of switchover; [0073] teaches obtaining the name of a server destination unit (i.e. the first standby system or the second standby system) and determining whether the obtained unit (i.e. the server destination unit) is at present in operation and so is available (i.e. determining the switchover destination is configured to operate normally)),
change, when it is determined that the one selected as the switchover destination cannot operate normally, the switchover destination to another of the first standby system and the second standby system, and re-execute the switchover processing from start ([0073] teaches when the obtained unit (i.e. selected switchover destination) is out of operation (i.e. cannot operate normally), another destination unit is searched and determines the obtained unit to be the server destination for switchover processing (i.e. the switchover destination is changed from a first choice standby system to the second available standby system and the switchover processing is continued)).
Accordingly, it would have been obvious to a person having ordinary skill in the art, having the teachings of SAMPATH ‘300, SAMPATH ‘220, LUI, DORNEMANN, RAUT, and YAKO before him before the effective filing date of the claimed invention, to incorporate changing the switchover destination to a different standby system when the selected standby system is not operating as taught by YAKO into the switchover control system disclosed by SAMPATH ‘300, SAMPATH ‘220, LUI, DORNEMANN, and RAUT to prevent the decrease in throughput of the entire system and to suppress the unbalance in load after system switchover in the event of failure (YAKO [0011]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Laurenz Advincula whose telephone number is (571)272-9211. The examiner can normally be reached T-F 8:30 AM - 5:30 PM EST.
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, Andrew J. Jung can be reached at 571-270-3779. 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.
/L.A./ Examiner, Art Unit 2175
/Paul Yen/ Primary Examiner, Art Unit 2175
Prosecution Insights