DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-20 are presented for examination.
This Office action is Non-Final.
Obviousness 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 § 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-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-24 of U.S. Patent No. 12,423,323 (‘323). Although the claims at issue are not identical, they are not patentably distinct from each other because both are directed to maintaining availability of replicated data by utilizing a primary deployment and a secondary deployment, replicating data between the deployments, detecting that the primary deployment has become unavailable, and performing failover operations so that processing continues despite the unavailability of the primary deployment..
The instant independent claims recite replicating data stored in a primary deployment to a secondary deployment, determining that the primary deployment transitioned from an available state to an unavailable state, and executing one or more transactions on the data at the secondary deployment in response to determining that the primary deployment is unavailable.
The claims of the ‘323 patent likewise recite replication of data between primary and secondary deployments and failover from the primary deployment to the secondary deployment upon unavailability of the primary deployment. Following failover, the secondary deployment assumes responsibility for servicing database operations
It would have been obvious to one of ordinary skill in the art that, once the secondary deployment assumes responsibility for servicing database operations following failover as taught by the ‘323 patent, transactions would necessarily be executed on the secondary deployment while the primary deployment remains unavailable. Executing transactions at the deployment currently servicing database operations constitutes no more than an obvious variation and expected operation of the failover architecture disclosed in the patent and would have yielded the predictable result of maintaining continued database availability during a primary deployment outage.
Prior Art Made of Record
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
McAlister et al. discloses replicated instances in a database environment provide for automatic failover and recovery. A monitoring component can periodically communicate with a primary and a secondary replica for an instance, with each capable of residing in a separate data zone or geographic location to provide a level of reliability and availability. A database running on the primary instance can have information synchronously replicated to the secondary replica at a block level, such that the primary and secondary replicas are in sync. In the event that the monitoring component is not able to communicate with one of the replicas, the monitoring component can attempt to determine whether those replicas can communicate with each other, as well as whether the replicas have the same data generation version. Depending on the state information, the monitoring component can automatically perform a recovery operation, such as to failover to the secondary replica or perform secondary replica recovery.
Dageville et al. (‘161 and ‘777) discloses replication and failover of database data is disclosed. A method includes replicating database data stored in a primary deployment such that the database data is further stored in a secondary deployment. The method includes executing one or more updates to the database data at the secondary deployment when the primary deployment is unavailable and propagating the one or more updates to the primary deployment when the primary deployment becomes available again. The method includes executing queries on the database data at the primary deployment when the primary deployment is available.
Dageville et al. (‘845) discloses replication and failover of database data is disclosed. A method includes copying a first dataset of a first account stored in a primary deployment to a secondary deployment. The method includes determining that the first dataset stored in the primary deployment is unavailable. The method includes executing a first transaction on the first dataset at the secondary deployment in response to determining that the first dataset stored in the primary deployment is unavailable. The method includes executing a second transaction on a second dataset of a second account at the primary deployment while the first dataset of the first account stored in the primary deployment is unavailable.
Dageville et al. discloses directing requests to databases based on client account association is disclosed. A method includes determining a first client account associated with a first request to perform a first transaction. The method includes determining a second client account associated with a second request to perform a second transaction. The method includes selecting, for the first request, a primary deployment that stores a first dataset responsive to determining the first client account associated with the first request. The method includes selecting, for the second request, a secondary deployment that stores a second dataset that includes the first dataset responsive to determining the second client account associated with the second request. The method includes executing, while the primary deployment and the secondary deployment are both available, the first transaction on the first dataset at the primary deployment and the second transaction on the second dataset at the secondary deployment.
Robinson et al. (‘608) discloses transitioning a client connection for a database from a first deployment of the database to a second deployment of the database. A method includes maintaining the client connection between a client and the first deployment such that database traffic occurs at the first deployment. The method includes generating a unique identification that references a first connection object of the first deployment and a second connection object of a second deployment. The method includes receiving a notification that the first deployment is unavailable and providing an external connection group unique identification to the second deployment for the second deployment to determine whether the client should be connected to the second deployment. The method includes receiving a uniform resource locator from the second deployment if the client should be connected to the second deployment.
Robinson et al. (‘207) discloses generates a unique identification that references a first connection object of a first deployment and a second connection object of a second deployment of a database. The subject technology receives a notification that the first deployment is unavailable, the notification that the first deployment is unavailable comprises an indication of a downtime for the first deployment. The subject technology provides an external connection group unique identification to the second deployment for the second deployment to determine whether a client is to be connected to the second deployment. The subject technology receives a uniform resource locator from the second deployment when a client device is to be connected to the second deployment, the uniform resource locator being provided to the client device for connecting to the second deployment.
Bikumala et al. discloses instructions stored in a memory and executed by one or more processors to configure an availability group that includes a primary database and a secondary database and configure one or more subscriptions associated with the primary database. Individual subscriptions of the one or more subscriptions may identify a network element (e.g., individual subscriber) of one or more network elements that subscribe to receiving a portion of data stored in the primary database. The processors may configure the secondary database to replicate a content of the primary database, configure the secondary database to publish data based on the one or more subscriptions in response to a failover from the primary database to the secondary database, and redirect the one or more subscriptions from the primary database to the availability group.
Garlapati et al. discloses a customer may use a disaster recovery service to generate a disaster recovery scenario in order to make certain resources available to the customer in the event of a data region failure. The customer may specify a recovery point objective, a recovery time objective and a recovery data region for the scenario. Accordingly, the disaster recovery service may coordinate with one or more other services provided by the computing resource service provider to reproduce the customer resources and other resources necessary to support the customer resources. These reproduced resources may be transferred to the recovery data region based at least in part on the parameters specified by the customer. In the event of a data region failure, the disaster recovery service may update the domain name system to resolve any customer requests for the customer resources to the recovery data region.
Sathyanarayana et al. discloses seamless failover in a database replication environment which has a primary database server and a plurality of standby database servers, is described. An example method includes orderly terminating transactions on the primary database server, where the transactions are originated from client applications. The transaction logs of the primary database server are drained and the transaction logs are replicated from the primary database server to the plurality of standby database servers. One of the standby database servers is designated as a new primary database server processing user transactions.
Cherkauer et al. discloses log-shipping data replication from a primary system to a communicatively-coupled standby system. Embodiments of the invention may receive transactional log data at a standby system, from the primary system, and before the transactional log data is written to storage on the primary system. Embodiments may then receive a notification from the primary system indicating that the corresponding log data was written to storage on the primary system, and responsive to receiving the notification, may process the received transactional log data.
Bloomstein et al. discloses a framework for managing both clustering and data replication in a software system distributed across multiple nodes. The framework includes at least one agent running at nodes comprising the distributed system. The framework also includes a master to coordinate clustering and replication operations. The framework further includes a library of software programs, called primitives, that are used by agents to communicate with the master. The agent(s) obtain cluster status information and replication status information, which are used by the master to manage clustering and replication operations. The framework is designed to work with existing cluster management applications and data replication facilities. The framework provides status information needed for coordinating clustering and replication operations to ensure that applications and data remain in a consistent state for disaster recovery purposes.
Allen et al. discloses failover. Specifically, a primary server and a backup server are available to a plurality of clients. Messages containing requests are processed by the primary server, while a mirror image of transaction records generated by the processing of those requests is maintained in volatile memory of both the primary server and the backup server. In this mode of operation, the Volatile memory is periodically flushed to non-volatile memory.
Allowable Subject Matter
Claims 1-20 would be allowed upon submitting a terminal disclaimer in order to obviate the above Obviousness Double Patenting rejection above.
The following is a statement of reasons for the indication of allowable subject matter:
The prior art of record fails to teach or suggest the claimed combination of (i) replicating data from a primary deployment to a secondary deployment, (ii) determining that the primary deployment has transitioned to an unavailable state, and (iii) executing one or more transactions on the data at the secondary deployment in response to the primary deployment becoming unavailable. The prior art further fails to teach or suggest the claimed failover architecture in which transaction processing continues at the secondary deployment following detection of primary deployment unavailability, as recited in independent claims 1, 11, and 20.
When taken into context the claims as a whole were not uncovered in the prior art, even further, dependent claims 2-10 and 12-19 would also be allowed as they depend upon the allowable independent claims 1 and 11.
Conclusions/Points of Contacts
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JORGE A CASANOVA whose telephone number is (571)270-3563. The examiner can normally be reached M-F: 9 a.m. to 6 p.m. (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, Aleksandr Kerzhner can be reached at (571) 270-1760. 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.
/JORGE A CASANOVA/Primary Examiner, Art Unit 2165
Prosecution Insights