DETAILED ACTION
This communication is responsive to the claim amendment filed on 09/11/2025.
Claims 1, 11, and 16 are independent claims.
Claim 20 was previously canceled.
Claims 3, 11, 13, 15, 16, and 19 are amended.
Claims 1-19, and 21 are pending in this application.
This Action has been made FINAL.
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 09/29/2025 has been considered and recorded. The submission is in compliance with the provisions of 37 CFR §1.97. See form PTO-1449 singed and attached hereto.
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 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.
Claims 1, and 9-10 are rejected under 35 U.S.C. 103 as being unpatentable over Martin et al., US Pub. No. 2018/0373708 (hereinafter as “Martin”) in view of Gajic, US Pub. No. 2013/0332484 (hereinafter as “Gajic”), and further in view of Yurchenko et al., US Pub. No. 2014/0358852 (hereinafter as “Yurchenko”).
Regarding claim 1, Martin teaches: a method for detecting conflict for a keyspace being written to by multiple database nodes of a database system (par. [0025] wherein “identical keys” in the records of multiple versions are interpreted as the conflict), the method comprising:
receiving, by a first database node of the database system, permission information that indicates that the keyspace has been provisioned to the first database node to write records having keys that fall in the keyspace (pars. [0014] “a single key space rooted by a tenant identifier”, wherein the “tenant identifier (i.e., “tenant ID”)” is interpreted as database node; [0018] teaches the permission information, e.g., “a unique id, or key, assigned by the system100. The key can include various types of information, such as a tenant identifier to indicate which tenant the data is associated with”; and par. [0026], e.g., “tenant data may interpreted primary key requests for versions of the data … based on the key in the pool of the data stored… to access the appropriate data created by the tenant” teaches the permission information; Fig. 1A shown the database node receiving query with information that indicates keyspace (ks) see Fig. 1B has been provisioned to the tenant identifier as interpreted node ID to store/write records having keys, see in par. [0027], e.g., “Records can be keyed by a keyspace (ks), a tenant identifier, an object identifier (objectId), and/or an object key (ObjectKey). As shown in FIG. 1B, the record may include the tenant identifier, the objectId, and the objectKey. The key of the record may include the tenant identifier, the objectId, and the objectKey…”);
receiving, by the first database node, a request to perform a database transaction that includes writing a particular record for a key included in the keyspace (see par. [0025] “The database system (e.g., system 100 shown in FIG. 1, central component 700 and/or second computer 800 show in FIG. 4, or databases 1200a, 1200b, 1200c, and/or 1200d shown in FIGS. 6A-6B) may store transactions as immutable versions of given records. Immutable versions of contents of records already stored on the server system may be unchanged until the contents are deleted (if ever) from the server system. That is, a received transaction may create a new version of the contents of the record to be stored in the server system, instead of altering the contents of the record. Thus, it may be possible for multiple versions of a record (e.g., records having different contents) as disclosed herein to have identical keys except for transaction identifiers. The use of otherwise identical keys for versions of a given record may allow for the changing of data stored in the relational database…”, wherein the technique of “store” transaction is interpreted as the “writing” transaction of the particular record for an identical “key” herewith; and pars. [0026] discloses various database transactions, and [0027] “…a database system (e.g., system 100 shown in FIG. 1, the systems shown in FIG. 2A-2C, central component 700 and/or second computer 800 shown in FIG. 3, or database systems 1200a-1200d shown in FIGS. 6A-6B) according to an implementation of the disclosed subject matter. Records can be keyed by a keyspace (ks), a tenant identifier, an object identifier (objectId), and/or an object key (ObjectKey). As shown in FIG. 1B, the record may include the tenant identifier, the objectId, and the objectKey. The key of the record may include the tenant identifier, the objectId, and the objectKey…”);
accessing, by the first database node, one or more keyspace references from a keyspace reference catalog that stores information indicating when and where keyspaces were written to by database nodes of the database system (see Fig. 1A is shown Catalog at element 135, and Fig. 1B: shown herewith the “ks”=keyspace, Fig. 5A is shown the database nodes of the database system/servers; and par. [0031] “Severs 211, 212 correspond to servers 111, 112 in FIG. 1, residing in the access layer 105. A data extent references set 220 contains the extent IDs (EID) and key ranges of the extents that store corresponding data for each of the tenants. Extents 231, 232 are stored in a physical storage layer 227. A catalog 235 tracks the ID and key range of the extents 231, 232. The data extent references set 220, catalog 235, and extents 231, 232 correspond to the data extent references set 120, catalog 135, and extents 130 shown in FIG. 1A.” see further in Fig. 2A at elements 220 and 235).
Martin teaches “a database system” (Fig. 1, e.g., system 100), “the systems” (see Figs. 2A-2C), and “database systems 1200a-1200d” shown in Figs. 6A-6B. Martin further teaches: “Records can be keyed by a keyspace (ks), a tenant identifier, an object identifier (objectId), and/or an object key (ObjectKey). As shown in FIG. 1B, the record may include the tenant identifier, the objectId, and the objectKey. The key of the record may include the tenant identifier, the objectId, and the objectKey…” (see par. [0027]). However, Martin does not explicitly teach amended limitation: “wherein a given one of the one or more keyspace references identifies a respective database node of the database system that was previously provisioned the keyspace to write records for the keyspace;” and the limitations: “detecting, by the first database node, a potential conflict based on the one or more keyspace references indicating that there are one or more in-progress database transactions executing at a second database node of the database system that are writing records for the keyspace;” “in response to the detecting, the first database node sending a request to the second database node for information indicating whether the second database node has written a record for the key for the one or more in-progress database transactions that conflicts with the particular record”; and “based on a response from the second database node indicating that the second database node has not written a record that conflicts with the particular record, the first database node writing the particular record.”
In the same field of endeavor (i.e., data processing), Gajic teaches: “wherein a given one of the one or more keyspace references identifies a respective database node of the database system that was previously provisioned the keyspace to write records for the keyspace” (see pars. [0048] “a first node may be assigned a subset of columns under a key and a second node may be assigned a second subset of columns under the same key. In this example, the cluster manager 404 determines from the underlying read or write request whether to add the first node 108, the second node 108, or both to the connection list based on the column range in the request…”, and [0049], e.g., [Keyspace_1] [Column_Family_1] [Key_1], and (Key_1, Node_5), (Key_2, Node_10));
detecting, by the first database node, a potential conflict based on the one or more keyspace references indicating that there are one or more in-progress database transactions executing at a second database node of the database system that are writing records for the keyspace (pars. [0027-29] teaches the data structure of keys, status of key, a group of column families is referred to as the keyspace, and other references, [0048] “a first node may be assigned a subset of columns under a key and a second node may be assigned a second subset of columns under the same key. In this example, the cluster manager 404 determines from the underlying read or write request whether to add the first node 108, the second node 108, or both to the connection list based on the column range in the request. To the database software implemented on the node 108, it may appear that the node 108 stores a complete set of column data under the key.”); and
in response to the detecting, the first database node sending a request to the second database node for information indicating whether the second database node has written a record for the key for the one or more in-progress database transactions that conflicts with the particular record (par. [0048] in “underlying read or write request”, and e.g., “a first node may be assigned a subset of columns under a key and a second node may be assigned a second subset of columns under the same key”, and par. [0051] under the same “Key_1” in different nodes, e.g., Node_15, Node_20, Node_25)
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to combine the teachings of the cited references because the teachings of Gajic would have provided Martin with the above indicated limitations for allowing a skilled artisan in motivation for performing specified node(s) containing data under the search key and detecting any potential conflict in database nodes with the different keys or same key to avoids duplicating read/write data/record associated with key(s) in the database nodes in cloud system(s)/server(s) (Gajic: pars. [0036, and 48-49]).
Martin and Gajic do not explicitly teach the limitation: “based on a response from the second database node indicating that the second database node has not written a record that conflicts with the particular record, the first database node writing the particular record.”
In the same field of endeavor (i.e., data processing), Yurchenko teaches:
based on a response indicating that the second database node has not written a record that conflicts with the particular record, the first database node writing the particular record (pars. [0092] “If the node 104b finds that the first information is not similar to any hashed key …, the node 104b identifies that no conflict of synchronization has occurred. In case of no conflicts, a commit of database changes is carried out”, and [0093] “check whether or not a possible collision has occurred…, the node 104b may compare the first database key with one or more database keys to which the hashed key pertains. If the first database key is not substantially similar, similar or preferably same to any of these database keys, the node 104b identifies that no conflict of synchronization has occurred.”, where the technique of synchronization implies to writing record)
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to combine the teachings of the cited references because the teachings of Yurchenko would have provided Martin, and Gajic with the above indicated limitations for allowing a skill artisan to motivate in performing inserting/storing/writing records having keys in the keyspace in the particular database node(s) (Yurchenko: Figs. 4A-4B and pars. [0004, 0007]).
Regarding claim 9, Martin, Gajic, and Yurchenko teach:
wherein the keyspace reference catalog includes a plurality of keyspace references for the keyspace (Martin: see Fig. 2A-2C: shown the indications for the keyspace at elements 220 and 227 and 232), and wherein one of the plurality of keyspace references identifies the database node that is permitted to write records for the keyspace (Martin: Fig. 2A at elements 211 with written record 10, and 212 with written record 33, and pars. [0020 and 24]), and wherein two or more of the plurality of keyspace references identify database nodes at which to read records written for the keyspace (Gajic: pars. [0048 and 51]; and Yurchenko: figs. 1-3B and pars. [0046], [0049] “perform read and/or write operations on the nodes”, and [0078] “database key within its respective database key space”).
Regarding claim 10, Yurchenko teaches:
wherein the first database node is operable to, in response to the second database node having written a record for the key, aborting at least a portion of the database transaction (par. [0093] “... the node 104b may compare the first database key with one or more database keys to which the hashed key pertains… In a preferred embodiment, if the node 104b finds that the first information is similar or same to a hashed key…, the node 104b identifies that a conflict has occurred and no commit to database change is approved.”).
Claims 2, and 4 are rejected under 35 U.S.C. 103 as being unpatentable over Martin, Gajic, and Yurchenko, and in view of Stephens et al., US Patent No. 10303669 (hereinafter as “Stephens”).
Regarding claim 2, the claim is rejected by the same reasons set forth above to claim 1. Martin, Gajic, and Yurchenko do not explicitly teach the limitation: “before receiving the request to perform the database transaction, the first database node issuing a permission request to the database system for approval to write records for the keyspace, wherein the permission information is received in response to issuing the permission request.”
In the same field of endeavor (i.e., data processing), Stephens teaches:
before receiving the request to perform the database transaction, the first database node issuing a permission request to the database system for approval to write records for the keyspace, wherein the permission information is received in response to issuing the permission request (Col. 8, lines 21-67 teaches the policy management service 210 receives the permission request from user (as interpreted as the first database node) for granting/permission to access, modify and/or “may only write to resource 12345 between the hours of 9:00 and 9:30 AM…”, and Col. 11, lines 27-40, e.g., “a key-value store implementing a flat keyspace…”).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to combine the teachings of the cited references because the teachings of Stephens would have provided Martin, Gajic, and Yurchenko with the above indicated limitations for allowing a skill artisan in motivation for performing the authorization access and store records in fulfillment of the request is granted (Stephens: Fig. 7 and Cols. 8 and 11).
Regarding claim 4, Martin, Yurchenko and Stephens teach:
wherein the keyspace reference catalog includes a keyspace reference that indicates that, while the keyspace is provisioned to the first database node, all record writes to the keyspace are to be performed by the first database node (Martin: Fig. 1B and Fig. 2A, wherein the Server 211 and Server 212 are interpreted as the database nodes; and Yurchenko: pars. [0092-94]; and Stephens: Fig. 7 as shown the user/or first database node store/write metadata/records for the keyspace, Col. 11, lines 27-40, e.g., “a key-value store implementing a flat keyspace…”).
Claims 3 and 5 are rejected under 35 U.S.C. 103 as being unpatentable over Martin, Gajic, Yurchenko, and Stephens, and further in view of VERMEULEN et al., US Pub. No. 20160085772 (hereinafter as “Vermeulen”).
Regarding claim 3, the claim is rejected by the same reasons set forth above to claims 1-2. However, Martin, Gajic, Yurchenko, and Stephens do not explicitly teach the limitation: “permitted to commit subsequent to the keyspace being provisioned to the first database node, and caused a record write for the keyspace before the keyspace was provisioned to the first database node.”
In the same field of endeavor, Vermeulen teaches: “permitted to commit subsequent to the keyspace being provisioned to the first database node” (Vermeulen: par. [0253] “a requested write was conditional committed or not, the CSC may play a more active role to determine a write's status—e.g., the CSC may read an LTM log directly (e.g., using a log read interface similar to interface 1513 shown in FIG. 15), or may query an LTM to determine the result of a commit request”), and “caused a record write for the keyspace before the keyspace was provisioned to the first database node” (Vermeulen: pars. [0095] “write sets that can be used to detect conflicts with previously-committed transactions” and [0255] “a multi-partition transaction and that an unconditional commit record must be found before the writes are propagated to their target destinations”).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to combine the teachings of the cited references because the teachings of Vermeulen would have provided Martin, Gajic, Yurchenko, and Stephens with the above indicated limitations for allowing a skill artisan to motivate in performing the active transaction of write record in the target data stores (Vermeulen: pars. [0095, 119, and 132, 143]).
Regarding claim 5, the claim is rejected by the same reasons set forth above to claims 1-4. However, Martin, Gajic, Yurchenko and Stephens do not explicitly teach the limitations: “receiving, by the first database node, a relinquish request to relinquish the keyspace to the second database node to permit the second database node to write a record for the keyspace as part of an in-progress transaction on the second database node; and relinquishing, by the first database node, the keyspace in response to the relinquish request.”.
In the same field of endeavor (i.e., data processing), Vermeulen teaches:
receiving, by the first database node, a relinquish request to relinquish the keyspace to the second database node to permit the second database node to write a record for the keyspace for subsequent database transactions executed at the second database node (pars. [0070] e.g., “write operations” and “transaction’s write set” in the data stores/target data stores, [0076] “If either the acceptor node 110 or the committer node 116 rejects a requested state transition” and also wherein the “abandon the request” and “permitted to abort transition requests” are interpreted as the “relinquish request”, [0087] “state transition request may include a write payload…, and the write payload may be included in the transition record”; and par. [0253] “a requested write was conditional committed or not, the CSC may play a more active role to determine a write's status…”, [0256] “the multi-partition transaction corresponding to CRec1 has been explicitly aborted, write propagation and/or further processing for CRec1 may be abandoned by WA1, i.e., the writes of CRec1 need not be applied to their destination locations (element 4620)... if the propagation of the writes is abandoned, the commit record CRec1 may be modified or removed from LTM1's log to indicate the abandonment (e.g., by WA1 or by LTM1 in response to a request from WA1)”, and [0167] “the transaction should be abandoned or abort if the deadline is not met”, [0228] “the writes may be abandoned”, where the “abandoned”/”abort” are technically interpreted as “relinquish” as known by a skilled artisan, and further in par. [0233] as well to abandon the write request); and
relinquishing, by the first database node, the keyspace in response to the relinquish request (Vermeulen: pars. [0070] e.g., “write operations” and “transaction’s write set” in the data stores/target data stores, [0076] “If either the acceptor node 110 or the committer node 116 rejects a requested state transition”, “abandon the transition request” and “permitted to abort transition requests” are interpreted as the “relinquish request”, [0087] “state transition request may include a write payload…, and the write payload may be included in the transition record”, and [0233]).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to combine the teachings of the cited references because the teachings of Vermeulen would have provided Martin, Gajic, Yurchenko, and Stephens with the above indicated limitations for allowing a skill artisan to motivate in performing the abort/abandon=relinquish write operation/transaction per the abort/relinquish request to avoid conflict write record(s) in the target data stores (Vermeulen: pars. [0095, 119, and 132, 143]).
Claims 6, and 8 are rejected under 35 U.S.C. 103 as being unpatentable over Martin, Gajic, and Yurchenko, and in view of Lyle et al., US Patent No. 6366902 (hereinafter as “Lyle”).
Regarding claim 6, the claim is rejected by the same reasons set forth above to claim 1. However, Martin, Gajic, and Yurchenko do not explicitly teach the limitation: “wherein a particular one of the one or more keyspace references identifies an epoch range for the keyspace is associated with the second database node, and wherein the method further comprises: making, by the first database node, a determination that an epoch corresponding to the database transaction falls within the epoch range, wherein the determination is indicative that the second database node has written a record for the keyspace.”
In the same field of endeavor (i.e., data processing), Lyle teaches:
wherein a particular one of the one or more keyspace references identifies an epoch range for the keyspace is associated with the second database node (fig. 3, element 302 and fig. 4, element 406, wherein the Epoch number implements the epoch range for the table/keyspace 300 and 400; see col. 5, lines 55-65, e.g., keys, catalog, table space, an epoch number, and other information, etc.), and wherein the method further comprises:
making, by the first database node, a determination that an epoch corresponding to the database transaction falls within the epoch range, wherein the determination is indicative that the second database node has written a record for the keyspace (again figs. 3-4 as explained above; col. 5, lines 16-30 and col. 6, lines 54-65, e.g., “INSERT operation” transaction writing to the database node within the epoch number=range location”).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to combine the teachings of the cited references because the teachings of Lyle would have provided Martin, Gajic, and Yurchenko with the above indicated limitations using the epoch within epoch number/range for writing transaction more efficiently (Lyle: cols. 5-6, e.g., epoch with a region/location for Update/Insert=writing transaction).
Regarding claim 8, Martin teaches:
deleting, from the keyspace reference catalog, the particular keyspace reference after storing, in a persistence database of the database system, all records written at the second database node for the keyspace (Martin: Fig. 1 shown the catalog, and pars. [0029-30] wherein the “flush operation” implies to the “deleting”, and [0042], e.g., “now removed from the source database instance of server 211 …”).
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Martin, Wyatt, Gajic, Yurchenko, and Lyle, and further in view of Peleg et al., US Pub. No. 20050091180 (hereinafter as “Peleg”).
Regarding claim 7, the claim is rejected by the same reasons set forth above to claim 1 and 6. Furthermore, Lyle teaches: “modifying the epoch range in response to a commitment of a last active transaction that is linked to the particular keyspace reference” (Lyle: col. 5, lines 27-30, e.g., “The epoch number is used to determine when rows are moved. In particular, when rows are moved within the table space or partition, for example, by a reorganization, the epoch number stored for that table space or partition is updated.”, wherein the “rows are move” indicates to a commitment of a last active transaction, and the epoch number=range is updated=modifying).
However, Martin, Gajic, Yurchenko, and Lyle do not explicitly teach: “wherein the epoch range does not define an epoch for the upper bound of the epoch range prior to the modifying.”
In the same field of endeavor, Peleg teaches: “wherein the epoch range does not define an epoch for the upper bound of the epoch range prior to the modifying” (fig. 2 shown the tablespace=keyspace having the Epoch range column contain epochs associated with the timestamp, update type, record, in which the epoch undefines for upper bound before to the update/modify, pars. [0079] in particular Table 1, e.g., “No bounds Upper bound…” associated with the epoch range in pars. [0082-87]).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to combine the teachings of the cited references because the teachings of Peleg would have provided Martin, Gajic, Yurchenko, and Lyle with the above indicated limitation for allowing a skill artisan to motivate in performing the epoch interval/range, prior to the update/refresh/modifying, does not define epoch for the upper bound in fail catch-up the epochs (Peleg: pars. [0082-88]).
Claims 11-12, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Martin et al., US Pub. No. 2018/0373708 (hereinafter as “Martin”) in view of Martin et al., US Pub. No. 2018/0373604 (hereinafter as “Martin ‘604”), and further in view of Gajic, US Pub. No. 2013/0332484 (hereinafter as “Gajic”), and further in view of Yurchenko et al., US Pub. No. 2014/0358852 (hereinafter as “Yurchenko”)
Regarding claim 11, Martin teaches: a non-transitory computer readable medium having program instructions stored thereon that are executable by a first database node of a database system to cause the first database node (e.g., “database systems 1200a-1200d” shown in Figs. 6A-6B) to perform operations comprising:
receiving permission information that indicates that a keyspace has been provisioned to the first database node to write records having keys that fall in the keyspace (pars. [0014] “a single key space rooted by a tenant identifier”, wherein the “tenant identifier (i.e., “tenant ID”)” is interpreted as database node; [0018] teaches the permission information, and further as “a unique id, or key, assigned by the system100. The key can include various types of information, such as a tenant identifier to indicate which tenant the data is associated with”; and par. [0026], e.g., “tenant data may interpreted primary key requests for versions of the data … based on the key in the pool of the data stored… to access the appropriate data created by the tenant” teaches the permission information; Fig. 1A shown the database node receiving query with information that indicates keyspace (ks) see Fig. 1B has been provisioned to the tenant identifier as interpreted node ID to store/write records having keys, see in par. [0027], e.g., “Records can be keyed by a keyspace (ks), a tenant identifier, an object identifier (objectId), and/or an object key (ObjectKey). As shown in FIG. 1B, the record may include the tenant identifier, the objectId, and the objectKey. The key of the record may include the tenant identifier, the objectId, and the objectKey…”);
receiving a request to perform a database transaction that includes writing a particular record for a key included in the keyspace (see par. [0025] “The database system (e.g., system 100 shown in FIG. 1, central component 700 and/or second computer 800 show in FIG. 4, or databases 1200a, 1200b, 1200c, and/or 1200d shown in FIGS. 6A-6B) may store transactions as immutable versions of given records. Immutable versions of contents of records already stored on the server system may be unchanged until the contents are deleted (if ever) from the server system. That is, a received transaction may create a new version of the contents of the record to be stored in the server system, instead of altering the contents of the record. Thus, it may be possible for multiple versions of a record (e.g., records having different contents) as disclosed herein to have identical keys except for transaction identifiers. The use of otherwise identical keys for versions of a given record may allow for the changing of data stored in the relational database…”, wherein the technique of “store” transaction is interpreted as the “writing” transaction of the particular record for an identical “key” herewith; and pars. [0026] discloses various database transactions, and [0027] “…a database system (e.g., system 100 shown in FIG. 1, the systems shown in FIG. 2A-2C, central component 700 and/or second computer 800 shown in FIG. 3, or database systems 1200a-1200d shown in FIGS. 6A-6B) according to an implementation of the disclosed subject matter. Records can be keyed by a keyspace (ks), a tenant identifier, an object identifier (objectId), and/or an object key (ObjectKey). As shown in FIG. 1B, the record may include the tenant identifier, the objectId, and the objectKey. The key of the record may include the tenant identifier, the objectId, and the objectKey…”); and
accessing one or more keyspace references from a keyspace reference catalog that stores a plurality of keyspace references each correspond to a respective one of a plurality of database nodes (see Fig. 1A is shown Catalog at element 135, and Fig. 1B: shown herewith the “ks”=keyspace, Fig. 5A is shown the database nodes of the database system/servers; and par. [0031] “Severs 211, 212 correspond to servers 111, 112 in FIG. 1, residing in the access layer 105. A data extent references set 220 contains the extent IDs (EID) and key ranges of the extents that store corresponding data for each of the tenants. Extents 231, 232 are stored in a physical storage layer 227. A catalog 235 tracks the ID and key range of the extents 231, 232. The data extent references set 220, catalog 235, and extents 231, 232 correspond to the data extent references set 120, catalog 135, and extents 130 shown in FIG. 1A.” see further in Fig. 2A at elements 220 and 235)
Martin teaches the timestamp for records in the keyspace of catalog component corresponding the different versions (see pars. [0025-27]). However, Martin does not explicitly teach: “identify a time frame during which the respective database node wrote one or more records for a particular keyspace corresponding to that keyspace reference; detecting a potential conflict based on the one or more keyspace references indicating that there are one or more in-progress database transactions executing at a second database node of the database system that are writing records for the keyspace; in response to the detecting, sending a request to the second database node for information indicating whether the second database node has written a record for the key for the one or more in-progress database transactions that conflicts with the particular record; and based on a response indicating that the second database node has written a record that conflicts with the particular record, waiting until the record written by the second database node has been committed before writing the particular record.”
In the same field of endeavor (i.e., data processing), Martin’ 604 teaches: “identify a time frame during which the respective database node wrote one or more records for a particular keyspace corresponding to that keyspace reference” (Abstract, e.g., “first point in time”, and Par. [0071] e.g., “30 days, 60 days, 90 days, 120 days… at a particular point in time (e.g., every day at the same time, twice a day, every hour, or the like)…” for archival set of data/records in the extend(s)=keyspace of the database nodes).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to combine the teachings of the cited references because the teachings of Martin ‘604 would have provided Martin with the above amended limitation for allowing a skilled artisan in motivation for performing the efficient write operation with record in the second database node having previously assigned same minimum and/or maximum key for keyspace in a time frame (Martin ’604: pars. [0020, and 42-43]).
Martin and Martin’ 604 do not explicitly teach: “detecting a potential conflict based on the one or more keyspace references indicating that there are one or more in-progress database transactions executing at a second database node of the database system that are writing records for the keyspace; in response to the detecting, sending a request to the second database node for information indicating whether the second database node has written a record for the key for the one or more in-progress database transactions that conflicts with the particular record; and based on a response indicating that the second database node has written a record that conflicts with the particular record, waiting until the record written by the second database node has been committed before writing the particular record.”
In the same field of endeavor (i.e., data processing), Gajic teaches:
detecting a potential conflict based on the one or more keyspace references indicating that there are one or more in-progress database transactions executing at a second database node of the database system that are writing records for the keyspace (pars. [0027-29] teaches the data structure of keys, status of key, a group of column families is referred to as the keyspace, and other references, [0048] “a first node may be assigned a subset of columns under a key and a second node may be assigned a second subset of columns under the same key. In this example, the cluster manager 404 determines from the underlying read or write request whether to add the first node 108, the second node 108, or both to the connection list based on the column range in the request. To the database software implemented on the node 108, it may appear that the node 108 stores a complete set of column data under the key.”);
in response to the detecting, sending a request to the second database node for information indicating whether the second database node has written a record for the key for the one or more in-progress database transactions that conflicts with the particular record (par. [0048] in “underlying read or write request”, and e.g., “a first node may be assigned a subset of columns under a key and a second node may be assigned a second subset of columns under the same key”, and par. [0051] under the same “Key_1” in different nodes, e.g., Node_15, Node_20, Node_25).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to combine the teachings of the cited references because the teachings of Gajic would have provided Martin and Martin’ 604 with the above indicated limitations for allowing a skilled artisan in motivation for performing specified node(s) containing data under the search key and detecting any potential conflict in database nodes with the different keys or same key to avoids duplicating read/write data/record associated with key(s) in the database nodes in cloud system(s)/server(s) (Gajic: pars. [0036, and 48-49]).
Martin, Martin’ 604, and Gajic do not explicitly teach: “based on a response indicating that the second database node has written a record that conflicts with the particular record, waiting until the record written by the second database node has been committed before writing the particular record.”
In the same field of endeavor (i.e., data processing), Yurchenko teaches:
based on a response indicating that the second database node has written a record that conflicts with the particular record, waiting until the record written by the second database node has been committed before writing the particular record (pars. [0092] “the node 104b identifies that no conflict of synchronization has occurred. In case of no conflicts, a commit of database changes is carried out”, and [0093] “check whether or not a possible collision has occurred… the node 104b may compare the first database key with one or more database keys to which the hashed key pertains… In a preferred embodiment, if the node 104b finds that the first information is similar or same to a hashed key…, the node 104b identifies that a conflict has occurred and no commit to database change is approved” implies to the abort or wait)
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to combine the teachings of the cited references because the teachings of Yurchenko would have provided Martin, Martin’ 604, and Gajic with the above indicated limitations for allowing a skill artisan to motivate in performing inserting/storing/writing records having keys in the keyspace in the particular database node(s) (Yurchenko: Figs. 4A-4B and pars. [0004, 0007]).
Regarding claim 12, Martin and Martin’ 604, in combination, teach: wherein a particular one of the one or more keyspace references corresponds to the second database node identifies the keyspace by a minimum key and a maximum key (Martin: Figs. 2A-2C: shown the indication of “Key Start” and “Key End” which are interpreted as the minimum and maximum keys in the keyspace; and Par. [0031] e.g., “key ranges”), and wherein the particular indication specifies a time frame that encompasses the particular time frame (Martin: see par. [0026], e.g., specifies in “time stamps” is interpreted as the time frame or “other time identifiers may be made at the creation of a tenant…”; and Martin’ 604: see again in Abstract, e.g., “first point in time”, and par. [0071] e.g., “30 days, 60 days, 90 days, 120 days… at a particular point in time (e.g., every day at the same time, twice a day, every hour, or the like)…” for archival set of data/records in the extend(s)=keyspace of the database nodes).
Regarding claim 15, Yurchenko teaches: “in response to determining that the second database node has not written a record for the key, writing the particular record” (pars. [0092] “If the node 104b finds that the first information is not similar to any hashed key …, the node 104b identifies that no conflict of synchronization has occurred. In case of no conflicts, a commit of database changes is carried out”, and [0093] “check whether or not a possible collision has occurred…, the node 104b may compare the first database key with one or more database keys to which the hashed key pertains. If the first database key is not substantially similar, similar or preferably same to any of these database keys, the node 104b identifies that no conflict of synchronization has occurred.”, where the technique of synchronization implies to writing record).
Claims 13-14 are rejected under 35 U.S.C. 103 as being unpatentable over Martin, Martin’ 604, Gajic, and Yurchenko, and further in view of Stephens et al., US Patent No. 10303669 (hereinafter as “Stephens”)
Regarding claim 13, the claim is rejected by the same reasons set forth above to claim 11. Furthermore, Martin teaches: “causing a keyspace reference to be stored at the keyspace reference catalog that indicates that all record writes for the keyspace are to occur at the first database node” (see Fig. 2A, elements 220 and 235 – Catalog, which is used to store the keys and other reference data/record(s) in the keyspace 220, and Fig. 1B, and element 231, wherein the Server 211 is interpreted as the first database node).
However, Martin, Martin’ 604, Gajic, and Yurchenko do not explicitly teach: “requesting, from a manager node that manages the keyspace reference catalog, approval to write records for the keyspace at the first database node, wherein the permission information is received from the manager node in response to requesting approval.”
In the same field of endeavor (i.e., data processing), Stephens teaches:
requesting, from a manager node that manages the keyspace reference catalog, approval to write records for the keyspace at the first database node, wherein the permission information is received from the manager node in response to requesting approval (see Col. 8, lines 21-67 teaches the policy management service 210 receives the permission request from user (as interpreted as the first database node), which interpreted as the manager node, for granting/permission to access and modify or “may only write to resource 12345 between the hours of 9:00 and 9:30 AM…”, and Col. 11, lines 27-40, e.g., “a key-value store implementing a flat keyspace…” which inherits to the “information” as broadest reasonable interpretation. See MPEP 2111).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to combine the teachings of the cited references because the teachings of Stephens would have provided Martin, Martin’s, Gajic, and Yurchenko with the above indicated limitations for allowing a skill artisan in motivation for facilitating the authorization access and store records in fulfillment of the request is granted (Stephens: Fig. 7 and Cols. 8 and 11).
Regarding claim 14, Martin and Stephens, in combination, teach:
performing another database transaction that includes writing another particular record for the key included in the keyspace (Martin: par. [0025]: “The database system (e.g., system 100 shown in FIG. 1, central component 700 and/or second computer 800 show in FIG. 4, or databases 1200a, 1200b, 1200c, and/or 1200d shown in FIGS. 6A-6B) may store transactions as immutable versions of given records... That is, a received transaction may create a new version of the contents of the record to be stored in the server system, instead of altering the contents of the record. Thus, it may be possible for multiple versions of a record (e.g., records having different contents) as disclosed herein to have identical keys except for transaction identifiers. The use of otherwise identical keys for versions of a given record may allow for the changing of data stored in the relational database…”, wherein the “store transactions” intended of the performing another database transaction)
determining, using the keyspace reference catalog, that the permission to write records for the keyspace has been transferred to a third database node (Martin: Figs. 2A-2C, elements 235 – Catalog for the keys in the keyspace 220, and Fig. 1B; and Stephens: Col. 8, lines 21-67 teaches the policy management service 210 receives the permission request from user (as interpreted as the first database node) for granting/permission to access, modify or “may only write to resource …”, and Col. 11, lines 27-40, e.g., “a key-value store implementing a flat keyspace…”); and
sending a write request to the third database node to write the other particular record (Martin: see pars. [0024-25]; and Stephens: Col. 4, lines 6-55, e.g., “requests to an appropriate entities”, “add to”=write request… keyspace…. keys may include the name of the objects…”).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to combine the teachings of the cited references because the teachings of Stephens would have provided Martin, Martin’ 604, Gajic, and Yurchenko with the above indicated limitations for allowing a skill artisan in motivation for facilitating the authorization access and store records in fulfillment of the request is granted (Stephens: Fig. 7 and Cols. 8 and 11).
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Martin, Gajic, and further in view of Wyatt et al., US Pub. No. 2019/0045007 (hereinafter as “Wyatt”), and Martin et al., US Pub. No. 2018/0373604 (hereinafter as “Martin ‘604”), and Yurchenko et al., US Pub. No. 2014/0358852 (hereinafter as “Yurchenko”).
Regarding claim 16, the claim is rejected by the same reasons set forth above to claim 1. However, Martin, and Gajic does not explicitly teach the limitations: “wherein the particular keyspace was relinquished by another database node of the database system”, “wherein a first one of the plurality of keyspace reference identifies the particular keyspace, first time frame, and a second database node;” and “based on a response indicating that the second database node has not written the second record that conflicts with the first record, writing the first record.”
In the same field of endeavor (i.e., data processing), Wyatt teaches: “wherein the particular keyspace was relinquished by another database node” (Fig. 1-3, wherein the Active Node 140 as interpreted as the second database node is not permitted to write records, Fig. 5 “Prevent Write Operations, from Active Node, to Particular Portion Allocated for Writing Data 530 after “Modifying Identifier to Specify that Active Node Is Not to Write Data to Distribute Storage 520” which teaches the keyspace was relinquished in authorization; pars. [0024-26] teaches prevent the active node=second database node from writing possibly corrupt records after active node modifies identifier=relinquishes keyspace; see further in par. [0030], and [0036]).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to combine the teachings of the cited references because the teachings of Wyatt would have provided Martin and Gajic with the above indicated limitations for allowing a skilled artisan in motivation for performing access control in prevent corrupt writing records having identifiers/keys modifying/relinquishing by the particular database node(s) in the Database System (Wyatt: Figs. 1-6, and pars. [0024-26] and [0037-39]).
However, Martin, Gajic, and Wyatt do not explicitly teach the limitations: “wherein a first one of the plurality of keyspace reference identifies the particular keyspace, first time frame, and the other database node”, and “based on a response indicating that the second database node has not written the second record that conflicts with the first record, writing the first record.”
In the same field of endeavor (i.e., data processing), Martin’ 604 teaches: “wherein a first one of the plurality of keyspace reference identifies the particular keyspace, first time frame, and the other database node” (Abstract, e.g., “first point in time”, and Par. [0071] e.g., “30 days, 60 days, 90 days, 120 days… at a particular point in time (e.g., every day at the same time, twice a day, every hour, or the like)…” for archival set of data/records in the extend(s) of the database nodes).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to combine the teachings of the cited references because the teachings of Martin ‘604 would have provided Martin, Gajic, and Wyatt with the above indicated limitations for allowing a skilled artisan in motivation for performing the efficient write operation with record in the second database node having previously assigned same minimum and/or maximum key for keyspace (Martin ’604: pars. [0020, and 42-43]).
Martin, Gajic, Wyatt, and Martin ‘604 do not explicitly teach the limitations: “based on a response indicating that the second database node has not written the second record that conflicts with the first record, writing the first record.”
In the same field of endeavor (i.e., data processing), Yurchenko teaches:
based on a response indicating that the second database node has not written a record that conflicts with the particular record, the first database node writing the particular record (pars. [0092] “If the node 104b finds that the first information is not similar to any hashed key …, the node 104b identifies that no conflict of synchronization has occurred. In case of no conflicts, a commit of database changes is carried out”, and [0093] “check whether or not a possible collision has occurred…, the node 104b may compare the first database key with one or more database keys to which the hashed key pertains. If the first database key is not substantially similar, similar or preferably same to any of these database keys, the node 104b identifies that no conflict of synchronization has occurred.”).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to combine the teachings of the cited references because the teachings of Yurchenko would have provided Martin, Gajic, Wyatt, Martin ‘604, with the above indicated limitations for allowing a skill artisan in motivation to determine whether the data insert/store/write requests sending between the database system nodes as check constraint the written/stored/saved data in the particular database node(s) (Yurchenko: Figs. 4A-4B and pars. [0004, 0007]).
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Martin, Gajic, Wyatt, Martin ‘604, and Yurchenko, and further in view of HOLENSTEIN et al., US Pub. No. 20100191884 (hereinafter as “Holenstein”).
Regarding claim 17, the claim is rejected by the same reasons set forth above to claim 16. However, Martin, Gajic, Wyatt, Martin ‘604, and Yurchenko do not explicitly teach: “receiving, by the database system, an upgrade request to perform a rolling upgrade at the other database node, wherein the assigning is performed in response to receiving the upgrade request.”
In the same field of endeavor (i.e., data processing), Holenstein teaches:
receiving, by the database system, an upgrade request to perform a rolling upgrade at the other database node, wherein the assigning is performed in response to receiving the upgrade request (pars. [0435] “4. Elimination of planned downtime via the use of rolling upgrades”, and [1091-1092], e.g., ‘All that is required … that it can be upgraded. Means must be provided to resynchronize the node's database with the current state of the application database … be upgraded. This process can continue with all of the nodes in the application network, thus allowing an upgrade to be rolled through the network with no application downtime.”)
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to combine the teachings of the cited references because the teachings of Holenstein would have provided Martin, Gajic, Wyatt, Martin ‘604, and Yurchenko with the above indicated limitations for performing rolling upgrade algorithm for elimination of downtime (Holenstein: Pars. [0435 and 1091-1092]).
Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over Martin, Gajic, Wyatt, Martin ‘604, and Yurchenko, and further in view of Meyers, US Patent No. 10356150 (hereinafter as “Meyers”).
Regarding claim 18, the claim is rejected by the same reasons set forth above to claim 16. Furthermore, Martin teaches wherein the assigning includes: “adding, by the database system, a second keyspace reference to the keyspace reference catalog” (Figs. 2A-2B: shown the keyspace element 231 is assigned to first database node/server 211 and the Catalog 235; and see Par. [0018] “The system 100 can store data in immutable extents. Each extent can have a unique id, or key, assigned by the system 100. The key can include various types of information, such as a tenant identifier to indicate which tenant the data is associated with.”). However, Martin, Gajic, Wyatt, Martin ‘604, and Yurchenko do not explicitly teach “wherein the second keyspace reference specifies an open state that indicates that all record writes for the particular keyspace are to occur at the first database node; and updating, by the database system, the first keyspace reference to specify a closed state that indicates that record writes for the particular keyspace are not to occur at the second database node.”
In the same field of endeavor, Meyers teaches:
w wherein the second keyspace reference specifies an open state that indicates that all record writes for the particular keyspace are to occur at the first database node (Fig. 4b: at keyspaces indicates the write all record, see “state=open”, and Col. 4, lines 1-25, and Col. 9, lines 55-61, e.g., marked= indication as “open” or “active” status); and
updating, by the database system, the first keyspace reference to specify a closed state that indicates that record writes for the particular keyspace are not to occur at the second database node (see techniques of replaced=update with the marked=indication “closed” or “terminated” in Col. 9, lines 52-58 and 65-67).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to combine the teachings of the cited references because the teachings of Meyers would have provided Martin, Gajic, Wyatt, Martin ‘604, and Yurchenko with the above indicated limitations for allowing a skill artisan for motivate in using the specific state, e.g., open and close states, for performing the record writing more efficient (Meyers: Fig. 4b and cols. 4 and 9, lines 55-61).
Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Martin, Gajic, Wyatt, Martin ‘604, and Yurchenko, and further in view of Arye et al., US Pub. No. 2021/0034598 (hereinafter as “Arye”).
Regarding claim 19, the claim is rejected by the same reasons set forth above to claim 16. Furthermore, Martin, teaches: determining, based on the keyspace reference catalog, that at least two of the plurality of keyspace references pertain to the particular keyspace (Martin: Figs. 1B, and 2A-2C, e.g., “Key Start” and “Key End” as interpreted as the two of the indications; Martin ‘604: Pars. [0037] “Records can be keyed by a keyspace (ks), a tenant identifier, an object identifier (objectId), and/or an object key (ObjectKey)…”, and [0042] the indications: “a minimum key and a maximum key”, “key start,” which may be a minimum key, and a “key end,” which may be a maximum key of a boundary range”), wherein the at least two keyspace references include the first particular keyspace reference (Martin: see again in Fig. 1B and 2A-2C “ks”=keyspace with at two of keyspace references, see pars. [0018 and 24]).
However, Martin, Gajic, Wyatt, Martin ‘604, and Yurchenko do not teach: “in response to determining that a time frame identified by a different one of the at least two keyspace references than the first keyspace reference overlaps with a second time frame associated with the transaction, sending a request to a third database node for information indicating whether a record has been written, but not committed by the third database node for the key.”
In the same field of endeavor (i.e., data processing), Arye teaches:
in response to determining that a time frame identified by a different one of the at least two at least two keyspace references than the first keyspace reference overlaps with a second time frame associated with the transaction (Arye: par. [0173] “the database system defines a chunk as having a particular time interval (that is, both a start and end time) when the chunk is created. Then the system creates a new chunk when needed, e.g., when new data is to be inserted to a time interval that does not yet exist… overlap the time intervals of the first and second chunk, the first chunk's end time is modified when the second chunk is created so that they remain disjoint and their time intervals can be strictly ordered.” Since the chunks have a particular time intervals, checking/determining overlap first chunk and second chunk illustrate to the overlap time frames as known by a skill artisan, and pars. [0235] “If overlapping chunks are created, the database system follows its policies for writing and reading to overlapping chunks.”, and [0237] “the database system creates a new chunk that overlaps the same interval, or the database system switches to the use of a different time interval…”, and [0268]), sending a request to a third database node for information indicating whether a record has been written, but not committed by the third database node for the key (Arye ‘598: (pars. [0072] e.g., “…sending the query on behalf on another origin (e.g., an intermediate server or middleware layer acting as a queue, buffer, or router such as for INSERTS, or an application acting on behalf of another system or user).”, wherein the INSERTS cause to write (see algorithm in Fig. 8), [0151] “queries in a database system comprising a plurality of database nodes, in accordance with an embodiment. A database system node 310a receives database queries and may send one or more queries to chunks (that may be implemented as physical tables of the data), which are stored on the coordinator database system node or on other database system nodes….”, and [0229] “… it may be the result of a large batch insert that fails or is interrupted (which the non-committed rows needing to subsequently be removed)….”, wherein the row is embedded in the chunk(s) which is/are further shown in the Fig. 2, wherein the ‘space’ is interpreted as the key, and Figs. 7(A)-7(C), and Par. [0268] e.g., “overlap old chunks in terms of the time range”, “the two set have overlapping time periods”).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to combine the teachings of the cited references because the teachings of Meyers would have provided Martin, Gajic, Wyatt, Martin ‘604, and Yurchenko with the above indicated limitations for allowing a skill artisan in motivate for performing the insert/store the records in the target database table/node without or witching the overlapped time interval/frame to commit the write operation (Arye: pars. [0235, 237, and 268]).
Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over Martin, Gajic, and Yurchenko, and further in view of Meyers, US Patent No. 10356150 (hereinafter as “Meyers”).
Regarding claim 21, the claim is rejected by the same reasons set forth above to claim 1. Furthermore, in the same field of endeavor (i.e., data processing), Martin, Gajic, Yurchenko, and Meyers, in combination, teach: “wherein the keyspace reference catalog includes a plurality of keyspace references associated with the keyspace (see Martin: Fig. 1 is shown the Catalog; and Figs. 2A-2B: shown the keyspace element 231 is assigned to first database node/server 211 and the Catalog 235; and see Par. [0018] “The system 100 can store data in immutable extents. Each extent can have a unique id, or key, assigned by the system 100. The key can include various types of information, such as a tenant identifier to indicate which tenant the data is associated with.”), wherein the plurality of keyspace references includes:
a first keyspace reference that is associated with the first database node (Gajic: see pars. [0048-49, and 51] as explained above to claim 1) and specifies an open state that indicates that record writes for the keyspace are to occur at the first database node (Meyers: see Fig. 4b: at keyspaces indicates the write all record, see “state=open”, and Col. 4, lines 1-25, and Col. 9, lines 55-61, e.g., marked= indication as “open” or “active” status);
a second keyspace reference that is associated with the second database node (Gajic: see pars. [0048-49, and 51] as explained above to claim 1) and specifies a closed state that indicates that there are in-progress database transactions executing at the second database node that are associated with the keyspace but have not committed (Yurchenko: par. [0093] “... the node 104b may compare the first database key with one or more database keys to which the hashed key pertains… In a preferred embodiment, if the node 104b finds that the first information is similar or same to a hashed key…, the node 104b identifies that a conflict has occurred and no commit to database change is approved.”; and Meyers: see techniques of replaced=update with the marked=indication “closed” or “terminated” in Col. 9, lines 52-58 and 65-67); and
a third keyspace reference that is associated with a third database node of the database system (Gajic: see Figs. 1-3 for plurality of data nodes in the database system; and pars. [0048-49, and 51] teach the plurality of keys/references associated with the plurality of nodes associated with the data/records) and specifies an inactive state that indicates that transactions associated with the keyspace that were executing at the third database node have committed (Yurchenko: par. [0007] “(b) if it is found that no database server has made a change involving the substantially similar, similar or preferably same database key, the first change is committed”, and par. [0092]; and Meyers: see the marked=indication “closed” or “terminated” in Col. 9, lines 52-58 and 65-67, which is interpreted as the “inactive”).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to combine the teachings of the cited references because the teachings of Meyers would have provided Martin, Gajic, and Yurchenko with the above indicated limitations for allowing a skill artisan for motivate in using the specific state, e.g., open and close states, for performing the record writing more efficient (Meyers: Fig. 4b and cols. 4 and 9, lines 55-61).
Response to Arguments
Referring to claim rejections under 35 USC 103, Applicant's arguments to the amended limitations in the respective claim 11 (see Remarks, pages 8-12) have been considered but are moot in view of the new grounds of rejection necessitated by applicant's amendment to the claims. Applicant's newly amended features are taught implicitly, expressly, or impliedly by the prior art of record. See the rejections set forth above for details.
A/ Responding Applicant’s argument on page 9 of the Remarks: Examiner respectfully submits that Martin and Martin’ 604, in combination, teaches the claim limitation: “accessing one or more keyspace references from a keyspace reference catalog that stores a plurality of keyspace references each correspond to a respective one of a plurality of database nodes” (Martin: Fig. 1A is shown Catalog at element 135, and Fig. 1B: shown herewith the “ks”=keyspace, Fig. 5A is shown the database nodes of the database system/servers; and par. [0031] “Severs 211, 212 correspond to servers 111, 112 in FIG. 1, residing in the access layer 105. A data extent references set 220 contains the extent IDs (EID) and key ranges of the extents that store corresponding data for each of the tenants. Extents 231, 232 are stored in a physical storage layer 227. A catalog 235 tracks the ID and key range of the extents 231, 232. The data extent references set 220, catalog 235, and extents 231, 232 correspond to the data extent references set 120, catalog 135, and extents 130 shown in FIG. 1A.” see further in Fig. 2A at elements 220 and 235) and “identify a time frame during which the respective database node wrote one or more records for a particular keyspace corresponding to that keyspace reference” (Martin’ 604: Abstract, e.g., “first point in time”, and Par. [0071] e.g., “30 days, 60 days, 90 days, 120 days… at a particular point in time (e.g., every day at the same time, twice a day, every hour, or the like)…” for archival set of data/records in the extend(s)=keyspace of the database nodes).
B/ Responding Applicant’s argument on page 10 of Remarks: Examiner
respectfully submits that Gajic teaches, discloses, or expressly suggests the claim limitation: “detecting a potential conflict based on the one or more keyspace references indicating that there are one or more in-progress database transactions executing at a second database node of the database system that are writing records for the keyspace” (pars. [0027-29] teaches the data structure of keys, status of key, a group of column families is referred to as the keyspace, and other references, [0048] “a first node may be assigned a subset of columns under a key and a second node may be assigned a second subset of columns under the same key. In this example, the cluster manager 404 determines from the underlying read or write request whether to add the first node 108, the second node 108, or both to the connection list based on the column range in the request. To the database software implemented on the node 108, it may appear that the node 108 stores a complete set of column data under the key.”).
C/ Responding Applicant’s argument on page 11 of Remarks: Examiner respectfully submits that Yurchenko teaches the claim limitation: “based on a response indicating that the second database node has written a record that conflicts with the particular record, waiting until the record written by the second database node has been committed before writing the particular record” (pars. [0092] “the node 104b identifies that no conflict of synchronization has occurred. In case of no conflicts, a commit of database changes is carried out”, and [0093] “check whether or not a possible collision has occurred… the node 104b may compare the first database key with one or more database keys to which the hashed key pertains… In a preferred embodiment, if the node 104b finds that the first information is similar or same to a hashed key…, the node 104b identifies that a conflict has occurred and no commit to database change is approved” implies to the abort or wait).
Examiner will reference prior art using terminology familiar to one of ordinary skill in the art. Such an approach is broad in concept and can be either explicit or implicit in meaning. Thus, examiner has full latitude to interpret limitation(s) of each claim in the broadest reasonable interpretation. See MPEP 2111 – Claim Interpretation: "During examination, the claims must be interpreted as broadly as their terms reasonably allow." In re American Academy of Science Tech Center, 367 F.3d 1359, 1369, 70 USPQ2d 1827, 1834 (Fed. Cir. 2004) (The USPTO uses a different standard for construing claims than that used by district courts; during examination the USPTO must give claims their broadest reasonable interpretation). In Phillips v. AWH Corp., 415 F.3d 1303, 75 USPQ2d 1321 (Fed. Cir. 2005), the court further elaborated on the “broadest reasonable interpretation" standard and recognized that “The Patent and Trademark Office (“PTO") determines the scope of claims in patent applications not solely on the basis of the claim language, but upon giving claims their broadest reasonable construction." Thus, when interpreting claims, the courts have held that Examiners should (1) interpret claim terms as broadly as their terms reasonably allows and (2) interpret claim phrases as broadly as their construction reasonably allows.
Prior Arts
The prior art made of record on form PTO-892 and not relied upon is considered pertinent to applicant's disclosure. Applicant is required under 37 C.F.R. § 1.111(c) to consider these references fully when responding to this action.
It is noted that any citation to specific, pages, columns, lines, or figures in the prior art references and any interpretation of the references should not be considered to be limiting in any way. A reference is relevant for all it contains and may be relied upon for all that it would have reasonably suggested to one having ordinary skill in the art. See In re Heck, 699 F.2d 1331, 1332-33, 216 USPQ 1038, 1039 (Fed. Cir. 1983) (quoting In re Lemelson, 397 F.2d 1006, 1009, 158 USPQ 275,277 (CCPA 1968)); Merck & Co. v. Biocraft Laboratories, 874 F.2d 804, 10 USPQ2d 1843 (Fed. Cir.), cert. denied, 493 U.S. 975 (1989).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Jessica N. Le whose telephone number is (571)270-1009. The examiner can normally be reached M-F 9: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, SHERIEF BADAWI can be reached on (571) 272-9782. 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.
/Jessica N Le/Examiner, Art Unit 2169
/MD I UDDIN/Primary Examiner, Art Unit 2169