DETAILED ACTION
This action is responsive to communications filed 14 March 2025.
Claims 1-21 are subject to examination.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 01 May 2025, 04 June 2025, 22 July 2025, 04 September 2025, 22 September 2025, 03 October 2025, 16 October 2025, 30 April 2026 and 17 July 2026. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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-4, 6-11, 13-18 and 20-21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ryland et al. (US-9817703-B1) hereinafter Ryland in view of Dai et al. (US-20250036651-A1) hereinafter Dai.
Regarding claim 15, Ryland discloses:
A computing system ([2:34-35] computing system) comprising:
a storage medium having stored thereon a sequence of instructions ([28:11-23] one or more persistent storage devices … store instructions and/or data in persistent storage devices); and
a processor that executes the sequence of instructions to cause a set of acts ([27:46-28:10] processors may be any suitable processors capable of executing instructions [28:24-47] system memories that are configured to store instructions and data accessible by processor(s)) comprising:
configuring a cluster comprising a plurality of computing nodes to use a zero-compute witness in response to detection of a failure associated with a resource ([4:28-61] nodes of compute cluster may be configured to communicate with distributed key value data store … provide redundancy, replication, fault tolerance, or some other guarantee of maintaining a consistent state of data for clients of the distributed key-value data store among multiple nodes … storage cluster including a leader node and multiple storage nodes … leader failover mechanism provided by the distributed durability scheme may elect a new leader node from among the multiple storage nodes according to a different distributed lock manager that is accessible to key value data store (for which the storage node that acquires the leader lock may be elected the new leader node; i.e. zero-compute witness, see [20:26-46] leader node election … send a respective conditional write request including identification information in order to acquire the leader lock)), wherein the zero-compute witness comprises a remote storage object ([10:63-11:26] submit web services requests to distributed key value data store via network (i.e. remote storage object)), the remote storage object is stored at a location that is remote to the cluster and is capable of holding a value to perform witness functionality ([10:63-11:26] submit web services requests to distributed key value data store via network (i.e. remote storage object), see [20:26-46] leader node election … send a respective conditional write request including identification information in order to acquire the leader lock (i.e. holding a value to perform witness functionality, e.g. the leader lock));
monitoring, by one or more nodes of the cluster ([20:26-46] compute node instances in compute cluster may have also determined that communication or other errors were occurring with the leader node instance), the cluster to detect the failure associated with the resource ([20:26-46] communication or other errors were occurring with the leader node instance); and
in response to the detection of the failure associated with the resource ([20:26-46] determined that communication or other errors were occurring with the leader node instance), sending a conditional write request to the remote storage object of the zero-compute witness ([20:26-46] leader node election … send a respective conditional write request including identification information in order to acquire the leader lock), wherein:
in response to the remote storage object being modified by the conditional write ([20:26-46] leader node election … send a respective conditional write request including identification information in order to acquire the leader lock … only node of the compute node instances may receive an indication of a successful write (i.e. modified by the conditional write by being successfully written)), a sender of the conditional write becomes an owner of the resource ([20:47-59] compute node instance may then begin to operate in the role of leader node for compute cluster), and
in response to the remote storage object not being modified by the conditional write ([20:26-46] leader node election … send a respective conditional write request including identification information in order to acquire the leader lock … other compute node instances may receive write failure indications), the sender of the conditional write does not become the owner of the resource ([19:6-19] leader lock entry may identify the leader node for compute cluster (i.e. if the conditional write fails to write, then the sending node would not receive leadership)).
Ryland does not explicitly disclose:
wherein the zero-compute witness comprises a remote cloud-based storage object,
However, Dai discloses:
wherein the zero-compute witness comprises a remote cloud-based storage object ([0023] witness lacks dedicated compute logic (i.e. zero-compute) … serves exclusively as a storage destination for read-modify-write operations of the nodes within the cluster … cloud storage location (i.e. remote cloud-based storage object, e.g. Microsoft’s Azure Blob Storage)),
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Ryland in view of Dai to have the zero-compute witness comprise a remote cloud-based storage object. One of ordinary skill in the art would have been motivated to do so to place a witness in a shared storage location on any cloud storage location and where a cloud-based resource provider implements a multi-node replication system to provide redundancy and fault tolerance for client applications executing on cloud servers (Dai, [0002] [0023]).
Regarding claim 16, Ryland-Dai disclose:
The computing system of claim 15, set forth above,
Ryland does not explicitly disclose:
wherein the cluster comprises a stretch cluster.
However, Dai discloses:
wherein the cluster comprises a stretch cluster ([0024] two or more cluster nodes physically reside at geographically remote locations (i.e. stretch cluster)).
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Ryland in view of Dai to have the cluster comprise a stretch cluster. One of ordinary skill in the art would have been motivated to do so to have nodes of a cluster communicatively coupled to one another across a network, where nodes physically reside in a same data center or small area, or a wide area network where two or more cluster nodes physically reside at geographically remote locations (Dai, [0024]).
Regarding claim 17, Ryland-Dai disclose:
The computing system of claim 16, set forth above,
Ryland discloses:
wherein multiple clusters are configured to use the zero-compute witness ([22:62-23:12] such information may be used in cluster operations, such as when performing a leader node election using leader lock (see above), so that other compute clusters may be able to identify a newly elected leader node (i.e. multiple clusters)), and the multiple clusters comprise at least two or more of a compute clusters ([22:62-23:12] compute clusters), two or more of a storage clusters, or a compute cluster and a storage cluster.
Regarding claim 18, Ryland-Dai disclose:
The computing system of claim 16, set forth above,
Ryland discloses:
wherein the resource corresponds to a virtual machine at a first site of the cluster and having a synchronous replication relationship with is a second site of the cluster ([12:11-48] one or more database instances may be implemented on each of the storage nodes … operate as in a multi-tenant environment may be implemented on different computing nodes (or on different virtual machines executing on a single computing node) [13:33-14:3] storage node instances may include one or more modules configured to … implement replication and failover processes … replica groups, maintaining replicas for each of those groups … storage node A may be a leader node, see [21:33-54] Paxos-based technique may be implemented for such storage node operations at a key value data store as implementing leader node elections as part of leader node failover operations among storage clusters at a key value data store (see above)).
Ryland does not explicitly disclose:
wherein the cluster comprises a stretch cluster.
However, Dai discloses:
wherein the cluster comprises a stretch cluster ([0024] two or more cluster nodes physically reside at geographically remote locations (i.e. stretch cluster)).
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Ryland in view of Dai to have the cluster comprise a stretch cluster. One of ordinary skill in the art would have been motivated to do so to have nodes of a cluster communicatively coupled to one another across a network, where nodes physically reside in a same data center or small area, or a wide area network where two or more cluster nodes physically reside at geographically remote locations (Dai, [0024]).
Regarding claim 20, Ryland-Dai disclose:
The computing system of claim 15, set forth above,
Ryland discloses:
wherein ownership information is added to the remote storage object in response to a detection of a failure only ([4:28-61] leader failover mechanism provided by the distributed durability scheme may elect a new leader node from among the multiple storage nodes according to a different distributed lock manager that is accessible to key value data store (for which the storage node that acquires the leader lock may be elected the new leader node; i.e. zero-compute witness, see [20:26-46] leader node election … send a respective conditional write request including identification information in order to acquire the leader lock)).
Ryland does not explicitly disclose:
wherein the zero-compute witness comprises a remote cloud-based storage object
However, Dai discloses:
wherein the zero-compute witness comprises a remote cloud-based storage object ([0023] witness lacks dedicated compute logic (i.e. zero-compute) … serves exclusively as a storage destination for read-modify-write operations of the nodes within the cluster … cloud storage location (i.e. remote cloud-based storage object, e.g. Microsoft’s Azure Blob Storage)),
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Ryland in view of Dai to have the zero-compute witness comprise a remote cloud-based storage object. One of ordinary skill in the art would have been motivated to do so to place a witness in a shared storage location on any cloud storage location and where a cloud-based resource provider implements a multi-node replication system to provide redundancy and fault tolerance for client applications executing on cloud servers (Dai, [0002] [0023]).
Regarding claim 21, Ryland-Dai disclose:
The computing system of claim 20, set forth above,
Ryland discloses:
wherein the conditional write is predicated upon the remote storage object not having an identification of an owner of the resource ([4:28-61] leader failover mechanism provided by the distributed durability scheme may elect a new leader node from among the multiple storage nodes according to a different distributed lock manager that is accessible to key value data store (for which the storage node that acquires the leader lock may be elected the new leader node; i.e. zero-compute witness, see [20:26-46] leader node election … send a respective conditional write request including identification information in order to acquire the leader lock), see also [25:64-26:24] leader node that is no longer able to establish quorum may determine that it may need to relinquish the leader role for the compute cluster, and/or self-terminate … sending unique entries may be ceased … leader node lock entry is available (i.e. not having an identification of an owner of the resource)).
Ryland does not explicitly disclose:
wherein the zero-compute witness comprises a remote cloud-based storage object
However, Dai discloses:
wherein the zero-compute witness comprises a remote cloud-based storage object ([0023] witness lacks dedicated compute logic (i.e. zero-compute) … serves exclusively as a storage destination for read-modify-write operations of the nodes within the cluster … cloud storage location (i.e. remote cloud-based storage object, e.g. Microsoft’s Azure Blob Storage)),
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Ryland in view of Dai to have the zero-compute witness comprise a remote cloud-based storage object. One of ordinary skill in the art would have been motivated to do so to place a witness in a shared storage location on any cloud storage location and where a cloud-based resource provider implements a multi-node replication system to provide redundancy and fault tolerance for client applications executing on cloud servers (Dai, [0002] [0023]).
Regarding claims (1-4 and 6-7) and (8-11 and 13-14), they do not further define nor teach over the limitations of claims 15-18 and 20-21, therefore, claims (1-4 and 6-7) and (8-11 and 13-14) are rejected for at least the same reasons set forth above as in claims 15-18 and 20-21.
Claim(s) 5, 12 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ryland et al. (US-9817703-B1) hereinafter Ryland in view of Dai et al. (US-20250036651-A1) hereinafter Dai further in view of Jindal et al. (US-20240004766-A1) hereinafter Jindal.
Regarding claim 19, Ryland-Dai disclose:
The computing system of claim 16, set forth above,
Ryland does not explicitly disclose:
wherein the stretch cluster comprises a first site and a second site, and the first site, the second site, and the zero-compute witness are in different failure domains.
However, Dai discloses:
wherein the stretch cluster comprises a first site and a second site ([0024] two or more cluster nodes physically reside at geographically remote locations (i.e. a first and a second geographically remote location),
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Ryland in view of Dai to have the cluster comprise a stretch cluster. One of ordinary skill in the art would have been motivated to do so to have nodes of a cluster communicatively coupled to one another across a network, where nodes physically reside in a same data center or small area, or a wide area network where two or more cluster nodes physically reside at geographically remote locations (Dai, [0024]).
Ryland-Dai do not explicitly disclose:
the first site, the second site, and the zero-compute witness are in different failure domains.
However, Jindal discloses:
the first site, the second site, and the zero-compute witness are in different failure domains ([0065] there can be many definitions of a fault domain … series of nodes that are powered by a common power supply, or a fault domain can comprise a single computing node, or a fault domain can comprise a hypervisor, or a fault domain can comprise an application, or a fault domain can comprise a virtual machine, etc. [0072] various ones of the entities can be situated in different fault domains, e.g. public cloud … first fault domain, public cloud 2 … second fault domain, any (or all) of the witness services … situated in respective different fault domains other than the fault domain that correspond to the primary site entities and the fault domain that corresponds to the secondary site entities (i.e. first site, second site, and witness are in different failure domains)).
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Ryland-Dai in view of Jindal to have the first site, second site, and the zero-compute witness be in different failure domains. One of ordinary skill in the art would have been motivated to do so to have many definitions of a fault domain and have various ones of the entities be situated in different fault domains (Jindal, [0065] [0072]).
Regarding claims 5 and 12, they do not further define nor teach over the limitations of claim 19, therefore, claims 5 and 12 are rejected for at least the same reasons set forth above as in claim 19.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Sukumaran et al. (US-9984140-B1) Lease Based Leader Election System;
Gupta et al. (US-11888599-B2) Scalable Leadership Election In A Multi-processing Computing Environment;
Bridge, Jr. et al. (US-12217550-B1) Tolerating Server Failures In A Consensus Protocol Down To One Surviving Server Using Shared Storage As A Voter.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Alex Tran whose telephone number is (571)272-8173. The examiner can normally be reached Monday-Friday 10AM-6PM ET.
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, Kamal Divecha can be reached at (571)272-5863. 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.
/Alex Tran/Primary Examiner, Art Unit 2453
