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 .
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) 18, 19, 23-25, 29 is/are rejected under 35 U.S.C. 103 as being unpatentable over Non-Patent Literature PostgreSQL High Availability on Kubernetes (“Willer”) in view of Non-Patent Literature What is Mirantis k0s, and how is it different from Rancher k3s (“Mehndiratta”) and Non-Patent Literature Fast Key-Value Store With PostgreSQL (“Arctype”).
Regarding claim 18, Willer teaches
A storage cluster, comprising: (Pg. 2: database cluster)
a primary storage node…configured to: (Pg. 2: primary database node)
store the data in a local database of the primary storage node…; and (Pg. 2: primary database node services writes)
send the data to a secondary storage node; and (Pg. 2: primary database node services writes and replicates the changes to the read only secondary database node)
the secondary storage node, configured to: (Pg. 2: secondary database node)
store the data in a local database of the secondary storage node… (Pg. 2: primary database node services writes and replicates the changes to the read only secondary database node)
wherein the storage cluster has exactly two storage nodes: the primary storage node and the secondary storage node (Pg. 2: two database nodes: the primary database node and the secondary database node)
Willer does not teach the remaining limitations.
Mehndiratta teaches
a primary storage node comprising a proxy interface, wherein the proxy interface is compatible with an ETCD cluster interface, and the primary storage node is configured to: (Pg. 3, 6: Kine is an etcd API that translates etcd calls to calls to databases such as Postgres)
obtain data from a container management cluster; (Pg. 3, 6: Kine is an etcd API that translates etcd calls, such as those from the Kubernetes API, to calls to databases such as Postgres)
store the data in a local database of the primary storage node (Pg. 3, 6: Kine is an etcd API that translates etcd calls, such as those from the Kubernetes API, to calls to databases such as Postgres)
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to combine Mehndiratta’s Kubernetes architecture with Willer’s database architecture.
One of ordinary skill in the art prior to the effective filing date would have been motivated to make the combination because Willer explicitly suggests implementing a high availability Postgres cluster in Kubernetes (Willer, Pg. 2-3), and Mehndiratta provides a high availability Kubernetes solution using Postgres (Mehndiratta, Pg. 6).
Willer in view of Mehndiratta does not teach store the data in a database in a key-value pair (K- V) manner.
Arctype teaches
store the data in a database in a key-value pair (K- V) manner (Pg. 3, 4: store data in Postgres in as key-value)
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to combine Arctype’s Postgres key-value storage with Willer in view of Mehndiratta’s Postgres.
One of ordinary skill in the art prior to the effective filing date would have been motivated to make the combination because key-value storage comes bundled with Postgres installations and using it is simpler than using a separate database for key-value storage (Arctype, Pg. 3, 8)
Regarding claim 19, Willer in view of Mehndiratta and Arctype further teaches
wherein the proxy interface of the primary storage node communicates with an application programming interface server (API) server in the container management cluster; (Mehndiratta, Pg. 3, 6: Kine is an etcd API that translates etcd calls, such as those from the Kubernetes API, to calls to databases such as Postgres)
wherein the proxy interface of the primary storage node is configured to:
perform protocol conversion on a first request from the API server, to obtain a second request supported by the local database of the primary storage node; and (Mehndiratta, Pg. 3, 6: Kine is an etcd API that translates etcd calls, such as those from the Kubernetes API, to calls to databases such as Postgres)
send the second request to the local database of the primary storage node; and (Mehndiratta, Pg. 3, 6: Kine is an etcd API that translates etcd calls, such as those from the Kubernetes API, to calls to databases such as Postgres)
wherein the local database of the primary storage node is configured to store the data comprised in the second request. (Mehndiratta, Pg. 3, 6: Kine is an etcd API that translates etcd calls, such as those from the Kubernetes API, to calls to databases such as Postgres)
Regarding claim 23, Willer in view of Mehndiratta and Arctype further teaches
wherein the container management cluster is a Kubernetes cluster. (Mehndiratta, Pg. 3, 6: Kubernetes)
Claim(s) 24, 29, the method(s) implemented by the storage cluster(s) of claim(s) 18, 19, 23, respectively, is/are rejected on the same grounds as claim(s) 18, 19, 23, respectively.
Regarding claim 25, Willer in view of Mehndiratta and Arctype further teaches
wherein the proxy interface of the primary storage node communicates with an application programming interface (API) server in the container management cluster; and (Mehndiratta, Pg. 3, 6: Kine is an etcd API that translates etcd calls, such as those from the Kubernetes API, to calls to databases such as Postgres)
wherein obtaining, by the primary storage node, the data from the container management cluster, and storing, by the primary storage node, the data in the local database of the primary storage node comprises: (Mehndiratta, Pg. 3, 6: Kine is an etcd API that translates etcd calls, such as those from the Kubernetes API, to calls to databases such as Postgres)
receiving, by the proxy interface of the primary storage node, a first request from the API server; (Mehndiratta, Pg. 3, 6: Kine is an etcd API that translates etcd calls, such as those from the Kubernetes API, to calls to databases such as Postgres)
performing protocol conversion on the first request, to obtain a second request supported by the local database of the primary storage node; (Mehndiratta, Pg. 3, 6: Kine is an etcd API that translates etcd calls, such as those from the Kubernetes API, to calls to databases such as Postgres)
sending the second request to the local database of the primary storage node; and (Mehndiratta, Pg. 3, 6: Kine is an etcd API that translates etcd calls, such as those from the Kubernetes API, to calls to databases such as Postgres)
storing, by the local database of the primary storage node, the data comprised in the second request. (Mehndiratta, Pg. 3, 6: Kine is an etcd API that translates etcd calls, such as those from the Kubernetes API, to calls to databases such as Postgres)
Claim(s) 20, 22, 26, 28 is/are rejected under 35 U.S.C. 103 as being unpatentable over Non-Patent Literature PostgreSQL High Availability on Kubernetes (“Willer”) in view of Non-Patent Literature What is Mirantis k0s, and how is it different from Rancher k3s (“Mehndiratta”), Non-Patent Literature Fast Key-Value Store With PostgreSQL (“Arctype”) and US Patent Application Publication No. 20080126845 (“Luo”).
Regarding claim 20, Willer in view of Mehndiratta and Arctype does not teach the remaining limitations.
Luo teaches
an arbitration node separately connected to the primary storage node and the secondary storage node; and (Fig. 3, [0065]: observer connected to primary and standby database)
wherein the arbitration node is configured to:
monitor working statuses of the primary storage node and the secondary storage node; and ([0076], [0155]: observer sends messages to determine the statuses of the primary and standby database)
when determining that the working status of the primary storage node changes from normal to failed, and the working status of the secondary storage node is normal, switch the secondary storage node to be the primary storage node in the storage cluster. (Fig. 8, [0173], [0175], [0176]: if the observer determines that the primary database is no longer responding to messages, and the standby database is ready to failover, the observer sends a failover command to the standby database. The standby becomes the new primary)
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to combine Luo’s observer for a replicated database with Willer in view of Mehndiratta and Arctype’s replicated database.
One of ordinary skill in the art prior to the effective filing date would have been motivated to make the combination to prevent divergence of primary and standby databases during failover (Luo, [0028], [0040]).
Regarding claim 22, Willer in view of Mehndiratta, Arctype, and Luo further teaches
wherein the arbitration node is configured to:
when switching the secondary storage node to the primary storage node in the storage cluster, send a switch indication to the secondary storage node, wherein the switch indication indicates to the secondary storage node to switch to the primary storage node in the storage cluster; and (Luo, Fig. 8, [0173], [0175], [0176]: if the observer determines that the primary database is no longer responding to messages, and the standby database is ready to failover, the observer sends a failover command to the standby database. The standby becomes the new primary)
wherein the secondary storage node is further configured to switch to the primary storage node in the storage cluster based on the switch indication. (Luo, Fig. 8, [0173], [0175], [0176]: if the observer determines that the primary database is no longer responding to messages, and the standby database is ready to failover, the observer sends a failover command to the standby database. The standby becomes the new primary)
Claim(s) 26, 28, the method(s) implemented by the storage cluster(s) of claim(s) 20, 22, respectively, is/are rejected on the same grounds as claim(s) 20, 22, respectively.
Claim(s) 21, 27 is/are rejected under 35 U.S.C. 103 as being unpatentable over Non-Patent Literature PostgreSQL High Availability on Kubernetes (“Willer”) in view of Non-Patent Literature What is Mirantis k0s, and how is it different from Rancher k3s (“Mehndiratta”), Non-Patent Literature Fast Key-Value Store With PostgreSQL (“Arctype”), US Patent Application Publication No. 20080126845 (“Luo”) and US Patent Application Publication No. 20200112499 (“Casacio”).
Regarding claim 21, Willer in view of Mehndiratta, Arctype, and Luo teaches
an arbitration node is separately connected to two storage nodes in [a] storage cluster; and (Luo, Fig. 3, [0065]: observer connected to primary and standby database)
wherein the arbitration node is configured to:
monitor working statuses of the two storage nodes in [a] storage cluster…(Luo, [0076], [0155]: observer sends messages to determine the statuses of the primary and standby database)
when determining that a working status of a primary storage node of a first storage cluster changes from normal to failed and a working status of a secondary storage node in the first storage cluster is normal, switch the secondary storage node in the first storage cluster to the primary storage node in the first storage cluster…(Luo, Fig. 8, [0173], [0175], [0176]: if the observer determines that the primary database is no longer responding to messages, and the standby database is ready to failover, the observer sends a failover command to the standby database. The standby becomes the new primary)
Willer in view of Mehndiratta, Arctype, and Luo does not further teach the remaining limitations.
Casacio teaches
wherein there are a plurality of storage clusters, and an arbitration node is separately connected to two storage nodes in each storage cluster; and (Fig. 2, [0014], [0029], [0030]: a single witness is connected to multiple quorums across multiple storage clusters)
wherein the arbitration node is configured to:
monitor working statuses of the two storage nodes in each storage cluster of the plurality of storage clusters; (Fig. 2, [0014], [0029], [0030]: a single witness is connected to multiple quorums across multiple storage clusters and receives heartbeats for all quorums)
and wherein the first storage cluster is comprised in the plurality of storage clusters. (Fig. 2, [0014], [0029], [0030]: a single witness is connected to multiple quorums across multiple storage clusters)
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to combine Casacio’s witness for multiple storage clusters with Willer in view of Mehndiratta, Arctype, and Luo’s observer.
One of ordinary skill in the art prior to the effective filing date would have been motivated to make the combination to provide scaling capability and reducing system administration overhead (Casacio, [0031]).
Claim(s) 27, the method(s) implemented by the storage cluster(s) of claim(s) 21, respectively, is/are rejected on the same grounds as claim(s) 21, respectively.
Claim(s) 30 is/are rejected under 35 U.S.C. 103 as being unpatentable over Non-Patent Literature PostgreSQL High Availability on Kubernetes (“Willer”) in view of Non-Patent Literature What is Mirantis k0s, and how is it different from Rancher k3s (“Mehndiratta”), Non-Patent Literature Fast Key-Value Store With PostgreSQL (“Arctype”) and US Patent Application Publication No. 20200112499 (“Casacio”).
Claim(s) 30 the medium(s) that implement(s) the storage cluster(s) of claim(s) 18, respectively, is/are rejected on the same grounds as claim(s) 18, respectively.
Willer in view of Mehndiratta and Arctype does not further teach
A non-transitory computer readable storage medium storing executable instructions, wherein when the executable instructions are executed by at least one processor, a storage cluster is caused to perform the following
Casacio teaches
A non-transitory computer readable storage medium storing executable instructions, wherein when the executable instructions are executed by at least one processor, a storage cluster is caused to perform the following ([0048], [0054])
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to store Willer in view of Mehndiratta and Arctype’s software implementation in Casacio’s storage medium.
One of ordinary skill in the art prior to the effective filing date would have been motivated to make the combination because software implementations can be stored on storage mediums (Casacio, [0054]).
Claim(s) 31, the medium(s) that implement(s) the method(s) of claim(s) 25, respectively, is/are rejected on the same grounds as claim(s) 25, respectively.
Willer in view of Mehndiratta, Arctype, and Casacio further teaches
A non-transitory computer readable storage medium storing executable instructions, wherein when the executable instructions are executed by at least one processor, a storage cluster is caused to perform the following (Casacio, [0048], [0054])
Claim(s) 32-34 is/are rejected under 35 U.S.C. 103 as being unpatentable over Non-Patent Literature PostgreSQL High Availability on Kubernetes (“Willer”) in view of Non-Patent Literature What is Mirantis k0s, and how is it different from Rancher k3s (“Mehndiratta”), Non-Patent Literature Fast Key-Value Store With PostgreSQL (“Arctype”), US Patent Application Publication No. 20200112499 (“Casacio”) and US Patent Application Publication No. 20080126845 (“Luo”).
Claim(s) 32-34, the medium(s) that implement(s) the storage cluster(s) of claim(s) 20-22, respectively, is/are rejected on the same grounds as claim(s) 20-22, respectively.
Response to Arguments
Applicant’s arguments with respect to claim(s) 18-34 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALBERT LI whose telephone number is (571)272-5721. The examiner can normally be reached M-F 8:00AM-4:00PM PT.
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, Bryce Bonzo can be reached at (571)272-3655. 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.
/A.L./Examiner, Art Unit 2113
/MARC DUNCAN/Primary Examiner, Art Unit 2113
Prosecution Insights