DETAILED ACTION
This Office action is in response to original application filed on 06/02/2025.
Claims 1-20 are pending. Claims 1-18 are amended. Claims 19-20 are new.
Claims 1-20 are rejected.
Notice of 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(s) (IDS) submitted on 07/07/2025 was filed prior to this Office action. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement(s) is/are being considered by the examiner.
Statutory Review under 35 USC § 101
Claims 1-6 and 19 are directed towards a method and have been reviewed.
Claims 1-6 and 19 appear to be patent-eligible as the claims perform significantly more than an abstract idea based on Step 2B of the patent eligible subject matter determination, as the claims provide a non-generic arrangement of its various computer components (a target replica node, master node, a proxy node) and provide a distribution of functionality within a network (BASCOM Global Internet v. AT&T Mobility LLC, 827 F.3d 1341, 1350-51, 119 USPQ2d 1236, 1243 (Fed. Cir. 2016)) to perform multiple operations of a same single transaction.
Claims 7-12 and 20 are directed toward a system and have been reviewed.
Claims 17-20 initially appear to be statutory, as the system includes hardware (at least one memory; at least one processor) as disclosed in ¶ 0152-0153 of the applicant’s specification, “The processor 704 may include any one or more of processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP) … The memory 706 may further include a non-volatile memory, for example, a read-only memory (ROM), a flash memory, a hard disk drive (HDD), or a solid-state drive (SSD).”
Claims 7-12 and 20 also appear to be statutory as the claims perform significantly more than an abstract idea based on Step 2B of the patent eligible subject matter determination.
Claims 13-18 are directed toward an article of manufacture and have been reviewed.
Claims 13-18 initially appear to be statutory, as the article of manufacture excludes transitory signals; the claim recites “A computer program product comprising instructions that are stored on a non-transitory computer readable medium.”
Claims 13-18 also appear to be statutory as the claims perform significantly more than an abstract idea based on Step 2B of the patent eligible subject matter determination.
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.
Claims 1, 6, 19; 7, 12, 20; and 13 are rejected under 35 U.S.C. 103 as being unpatentable over McAlister et al., U.S. Patent No. 9,208,032 (published December 8, 2015; hereinafter McAlister) in view of Burchall et al., U.S. Patent Application Publication No. 2014/0337393 (hereinafter Burchall).
Regarding claim 1, McAlister teaches:
A method performed by a target replica node of a cloud storage system, wherein the method comprises: (McAlister col. 4, lines 7-23: a web service that enables clients (e.g., subscribers) to operate a data storage system in a cloud computing environment … queries may be directed to database storage that is distributed across multiple physical resources, and the database system may be scaled up or down on an as needed basis)
receiving, from a master node of the cloud storage system, a redo log comprising a write operation; (McAlister FIG. 5, col. 19, lines 27-50: the database engine head node generating a redo log record specifying the requested write, as in 520, and sending the redo log record (but not the particular data page to which the request is directed) to a node (or nodes) of a distributed database-optimized storage system that stores the particular data page, as in 530; McAlister col. 4, lines 7-23: a web service that enables clients (e.g., subscribers) to operate a data storage system in a cloud computing environment … queries may be directed to database storage that is distributed across multiple physical resources)
processing the redo log to generate a modification record; (McAlister FIG. 5, col. 19, line 51-col. 20, line 9: the method may include, in response to receiving the redo log record, the storage system node(s) writing the redo log record to disk (or to another type of persistent storage media))
sending a log reception notification to a proxy node of the cloud storage system, wherein the log reception notification indicates that the target replica node has received the redo log; (McAlister FIG. 5, col. 19, line 51-col. 20, line 9: in response to receiving the redo log record, the storage system node(s) writing the redo log record to disk (or to another type of persistent storage media), and returning a write acknowledgment to the database engine head node, as in 540. In some embodiments, in response to receiving the write acknowledgement(s), the database engine head node may return a corresponding write acknowledgement to the client from whom the write request was received (not shown))
receiving, from the proxy node, a read operation… (McAlister FIG. 5, col. 20, lines 10-30: the method may also include (e.g., at some point subsequent to coalescing redo logs to create an up-to-date version of the particular data page) the database engine head node receiving a read request directed to the particular data page, as in 560)
determining, based on the modification record, data corresponding to the read operation; and (McAlister FIG. 5, col. 19, line 51-col. 20, line 30: the method may also include (e.g., at some point subsequent to coalescing redo logs to create an up-to-date version of the particular data page [shows being based on the modification record]) the database engine head node receiving a read request directed to the particular data page, as in 560. In response, the database engine head node may send a corresponding read request to a storage node that stores the particular data page [relevant to determining data] (e.g., one of the storage nodes in the primary AZ or one in a secondary AZ), as in 570)
feeding back the data to the proxy node. (McAlister FIG. 5, col. 20, lines 10-30: the method may include the storage system node to which the request was sent returning the particular data page to the database engine head node in its current state, as in 580, after which the database engine head node may return the requested data to the client from whom the read request was received, as in 590)
McAlister does not expressly disclose a read operation that belongs to a same transaction as the write operation.
However, Burchall addresses this by teaching receiving … a read operation that belongs to a same transaction as the write operation. (Burchall FIG. 6, ¶ 0058-0062: At 610, a read request to perform a read of a record (e.g., stored by the database service or some other service) and a transaction request to perform a transaction to the record may be received, for example, from one or more clients (e.g., of the database service or other service) ... As shown at 620, first and second indications of time may be associated with the read and the transaction, respectively ... a fuzzy read can happen when an update and (re)read happen nearly simultaneously and result in different values read for the same record)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the transaction execution of McAlister with the transaction ordering of Burchall.
In addition, both of the references (McAlister and Burchall) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as database transaction management.
Motivation to do so would be to improve the functioning of McAlister receiving database requests with the ability in similar reference Burchall also receiving database requests but with the improvement of mitigating read anomalies.
Motivation to do so would also be the teaching, suggestion, or motivation for a person of ordinary skill in the art to provide for a strong and understandable isolation level to customers and to improve scalability as seen in Burchall ¶ 0076.
Regarding claim 7, McAlister teaches:
An apparatus used in a target replica node of a cloud storage system, wherein the apparatus comprises: (McAlister col. 4, lines 7-23: a web service that enables clients (e.g., subscribers) to operate a data storage system in a cloud computing environment … queries may be directed to database storage that is distributed across multiple physical resources, and the database system may be scaled up or down on an as needed basis)
at least one memory configured to store instructions; and at least one processor coupled to the at least one memory and configured to execute the instructions to cause the apparatus to: (McAlister col. 48, lines 24-52: Any or all of program instructions 2025 may be provided as a computer program product, or software, that may include a non-transitory computer-readable storage medium having stored thereon instructions, which may be used to program a computer system (or other electronic devices) to perform a process according to various embodiments)
receive, from a master node of the cloud storage system, a redo log comprising a write operation; (McAlister FIG. 5, col. 19, lines 27-50: the database engine head node generating a redo log record specifying the requested write, as in 520, and sending the redo log record (but not the particular data page to which the request is directed) to a node (or nodes) of a distributed database-optimized storage system that stores the particular data page, as in 530; McAlister col. 4, lines 7-23: a web service that enables clients (e.g., subscribers) to operate a data storage system in a cloud computing environment … queries may be directed to database storage that is distributed across multiple physical resources)
process the redo log to generate a modification record; (McAlister FIG. 5, col. 19, line 51-col. 20, line 9: the method may include, in response to receiving the redo log record, the storage system node(s) writing the redo log record to disk (or to another type of persistent storage media))
send a log reception notification to a proxy node of the cloud storage system, wherein the log reception notification indicates that the target replica node has received the redo log; (McAlister FIG. 5, col. 19, line 51-col. 20, line 9: in response to receiving the redo log record, the storage system node(s) writing the redo log record to disk (or to another type of persistent storage media), and returning a write acknowledgment to the database engine head node, as in 540. In some embodiments, in response to receiving the write acknowledgement(s), the database engine head node may return a corresponding write acknowledgement to the client from whom the write request was received (not shown))
receive, from the proxy node, a read operation… (McAlister FIG. 5, col. 20, lines 10-30: the method may also include (e.g., at some point subsequent to coalescing redo logs to create an up-to-date version of the particular data page) the database engine head node receiving a read request directed to the particular data page, as in 560)
determine, based on the modification record, data corresponding to the read operation; and (McAlister FIG. 5, col. 19, line 51-col. 20, line 30: the method may also include (e.g., at some point subsequent to coalescing redo logs to create an up-to-date version of the particular data page [shows being based on the modification record]) the database engine head node receiving a read request directed to the particular data page, as in 560. In response, the database engine head node may send a corresponding read request to a storage node that stores the particular data page [relevant to determining data] (e.g., one of the storage nodes in the primary AZ or one in a secondary AZ), as in 570)
feed back the data to the proxy node. (McAlister FIG. 5, col. 20, lines 10-30: the method may include the storage system node to which the request was sent returning the particular data page to the database engine head node in its current state, as in 580, after which the database engine head node may return the requested data to the client from whom the read request was received, as in 590)
McAlister does not expressly disclose a read operation that belongs to a same transaction as the write operation.
However, Burchall addresses this by teaching to receive … a read operation that belongs to a same transaction as the write operation. (Burchall FIG. 6, ¶ 0058-0062: At 610, a read request to perform a read of a record (e.g., stored by the database service or some other service) and a transaction request to perform a transaction to the record may be received, for example, from one or more clients (e.g., of the database service or other service) ... As shown at 620, first and second indications of time may be associated with the read and the transaction, respectively ... a fuzzy read can happen when an update and (re)read happen nearly simultaneously and result in different values read for the same record)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the transaction execution of McAlister with the transaction ordering of Burchall.
In addition, both of the references (McAlister and Burchall) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as database transaction management.
Motivation to do so would be to improve the functioning of McAlister receiving database requests with the ability in similar reference Burchall also receiving database requests but with the improvement of mitigating read anomalies.
Motivation to do so would also be the teaching, suggestion, or motivation for a person of ordinary skill in the art to provide for a strong and understandable isolation level to customers and to improve scalability as seen in Burchall ¶ 0076.
Regarding claim 13, McAlister teaches:
A computer program product comprising instructions that are stored on a non-transitory computer readable medium and that, when executed by at least one processor, cause a target replica node of a cloud storage system to: (McAlister col. 4, lines 7-23: a web service that enables clients (e.g., subscribers) to operate a data storage system in a cloud computing environment … queries may be directed to database storage that is distributed across multiple physical resources; McAlister col. 48, lines 24-52: Any or all of program instructions 2025 may be provided as a computer program product, or software, that may include a non-transitory computer-readable storage medium having stored thereon instructions, which may be used to program a computer system (or other electronic devices) to perform a process according to various embodiments)
receive, from a master node of the cloud storage system, a redo log comprising a write operation; (McAlister FIG. 5, col. 19, lines 27-50: the database engine head node generating a redo log record specifying the requested write, as in 520, and sending the redo log record (but not the particular data page to which the request is directed) to a node (or nodes) of a distributed database-optimized storage system that stores the particular data page, as in 530; McAlister col. 4, lines 7-23: a web service that enables clients (e.g., subscribers) to operate a data storage system in a cloud computing environment … queries may be directed to database storage that is distributed across multiple physical resources)
process the redo log to generate a modification record; (McAlister FIG. 5, col. 19, line 51-col. 20, line 9: the method may include, in response to receiving the redo log record, the storage system node(s) writing the redo log record to disk (or to another type of persistent storage media))
send a log reception notification to a proxy node of the cloud storage system, wherein the log reception notification indicates that the target replica node has received the redo log; (McAlister FIG. 5, col. 19, line 51-col. 20, line 9: in response to receiving the redo log record, the storage system node(s) writing the redo log record to disk (or to another type of persistent storage media), and returning a write acknowledgment to the database engine head node, as in 540. In some embodiments, in response to receiving the write acknowledgement(s), the database engine head node may return a corresponding write acknowledgement to the client from whom the write request was received (not shown))
receive, from the proxy node, a read operation… (McAlister FIG. 5, col. 20, lines 10-30: the method may also include (e.g., at some point subsequent to coalescing redo logs to create an up-to-date version of the particular data page) the database engine head node receiving a read request directed to the particular data page, as in 560)
determine, based on the modification record, data corresponding to the read operation; and (McAlister FIG. 5, col. 19, line 51-col. 20, line 30: the method may also include (e.g., at some point subsequent to coalescing redo logs to create an up-to-date version of the particular data page [shows being based on the modification record]) the database engine head node receiving a read request directed to the particular data page, as in 560. In response, the database engine head node may send a corresponding read request to a storage node that stores the particular data page [relevant to determining data] (e.g., one of the storage nodes in the primary AZ or one in a secondary AZ), as in 570)
feed back the data to the proxy node. (McAlister FIG. 5, col. 20, lines 10-30: the method may include the storage system node to which the request was sent returning the particular data page to the database engine head node in its current state, as in 580, after which the database engine head node may return the requested data to the client from whom the read request was received, as in 590)
McAlister does not expressly disclose a read operation that belongs to a same transaction as the write operation.
However, Burchall addresses this by teaching to receive … a read operation that belongs to a same transaction as the write operation. (Burchall FIG. 6, ¶ 0058-0062: At 610, a read request to perform a read of a record (e.g., stored by the database service or some other service) and a transaction request to perform a transaction to the record may be received, for example, from one or more clients (e.g., of the database service or other service) ... As shown at 620, first and second indications of time may be associated with the read and the transaction, respectively ... a fuzzy read can happen when an update and (re)read happen nearly simultaneously and result in different values read for the same record)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the transaction execution of McAlister with the transaction ordering of Burchall.
In addition, both of the references (McAlister and Burchall) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as database transaction management.
Motivation to do so would be to improve the functioning of McAlister receiving database requests with the ability in similar reference Burchall also receiving database requests but with the improvement of mitigating read anomalies.
Motivation to do so would also be the teaching, suggestion, or motivation for a person of ordinary skill in the art to provide for a strong and understandable isolation level to customers and to improve scalability as seen in Burchall ¶ 0076.
Regarding claims 6, 12, and 18, McAlister in view of Burchall teaches:
wherein before determining the data corresponding to the read operation, the method further comprises determining that the … record is not written to a disk. (McAlister FIG. 5, col. 20, lines 10-30: the database engine head node may send a corresponding read request to a storage node that stores the particular data page (e.g., one of the storage nodes in the primary AZ or one in a secondary AZ), as in 570. Note that, in this example, it is assumed that the database engine head node does not store a current version of the particular data page in its cache [shows not being written]. Otherwise, the method may include database engine head node responding to the read request itself (e.g., by returning the requested data from its cache), rather than sending a corresponding read request to one of the storage system nodes; McAlister shows being written to a disk in col. 48, line 53-col. 49, line 10: the information described herein as being stored by the database tier (e.g., on a database engine head node), such as a transaction log, an undo log, cached page data, or other information used in performing the functions of the database tiers described herein may be stored in data store 2045 or in another portion of system memory 2020 on one or more nodes, in persistent storage 2060, and/or on one or more remote storage devices 2070, at different times and in various embodiments)
Burchall teaches the modification record. (Burchall ¶ 0074: various indications of time may be stored in a transaction table. For example, Tw may be stored with a transaction commit time as of the time of commit and each time a value is written, a transaction identifier may be generated. The transaction identifier may indicate whether a given transaction is active or committed; see also Burchall p9, Tables 1-3, ¶ 0062-0064: a fuzzy read can happen when an update and (re)read happen nearly simultaneously and result in different values read for the same record. In the example of Table 1 using a .delta. of 5, the read works properly as it reads the proper value by treating the commit as having happened before the read's consistency point)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the transaction execution of McAlister as modified with the transaction ordering of Burchall.
Motivation to do so would be to improve the functioning of McAlister as modified seeking remote data with the ability in similar reference Burchall also seeking remote data but with the improvement of transaction metadata.
Regarding claims 19-20, McAlister in view of Burchall teaches:
wherein processing the redo log to generate the modification record comprises: replaying the redo log to generate a target transaction; and generating the modification record by executing the target transaction. (McAlister col. 5, lines 5-31: before the database can be made available to handle incoming queries from client processes, a system process must read in all of the data pages that were changed after the determined checkpoint and apply each of the applicable change log records that had not already been applied to those data pages ... following a crash, multiple background threads may operate in parallel on different storage nodes to reconstruct data pages from corresponding redo logs. In the meantime, if an incoming query targets a data page that has not yet been reconstructed, the storage layer may be configured to re-create that data page on the fly from the appropriate redo logs; McAlister col. 28, lines 56-67: the system might have to replay a large number of redo log records to re-create the current version of a data page to which a lot of changes were directed since the last time that data page was flushed)
Claims 2-5, 8-11, and 14-17 are rejected under 35 U.S.C. 103 as being unpatentable over McAlister in view of Burchall in further view of Chan et al., U.S. Patent Application Publication No. 2021/0165762 (appears to share assignee with instant application; published June 3, 2021, prior to the instant application date of December 2, 2022; hereinafter Chan) in further view of Wang et al., U.S. Patent Application Publication No. 2019/0347167 (appears to share assignee with instant application; hereinafter Wang).
Regarding claims 2, 8, and 14, McAlister in view of Burchall does not expressly disclose:
wherein the redo log further comprises a first master channel identifier corresponding to a first master channel between the proxy node and the master node, wherein the first master channel is configured to transmit write operations of target user equipment, and wherein before determining the data corresponding to the read operation, the method further comprises:
obtaining a first replica channel identifier corresponding to the read operation, wherein the first replica channel identifier corresponds to a first replica channel between the proxy node and the target replica node, and wherein the first replica channel is configured to transmit read operations of the target user equipment; and
obtaining, based on the first replica channel identifier, the modification record.
However, Chan teaches:
wherein the redo log further comprises a first master channel identifier corresponding to a first master channel between the proxy node and the master node, (Chan FIG. 3, ¶ 0048-0051, see first ¶ 0048: a system 300 implementing a common log module (CLM) 304 to detect and resolve write-write conflicts between transactions received from a plurality of master nodes 100-1, 100-2 . . . 100-N ... the master node 100-1 includes a coordinator node 130-1 and a data node 132-1 ... The system 300 further includes a global transaction manager (GTM) 302, a CLM 304 and a common storage 316; see Chan ¶ 0051: The one REDO log contains an identifier (ID) associated with the master node (referred to hereinafter as master node ID) (e.g. master node 100-1, where the REDO log comes from) and log sequence number (LSN) mapping information (i.e., information indicative of a mapping of a local LSN associated with the master node (e.g. master node 100-1))
wherein the first master channel is configured to transmit write operations of target user equipment, (Chan FIG. 3, ¶ 0048-0051, see ¶ 0048: A write-write conflict occurs when at least two master nodes 100-1, 100-2 . . . 100-N send transactions that each include a request to write to the same page, or tuple of a database, which results in conflicting data. A write-write conflict does not occur when at least two master nodes 100-1, 100-2 . . . 100-N send transactions that include a request to write to different pages or tuples of a database; see Chan ¶ 0040-0043: The R/W drive or interface 116 reads from and writes to one or more portable computer-readable storage media 126 ... FIG. 2 depicts a multi-writer database system 200 (hereinafter system 200) implemented in accordance with various embodiments of the present disclosure. As shown, the system 200 comprises N master nodes 100-1, 100-2 . . . 100-N. Each of the N master nodes 100-1, 100-2 . . . 100-N includes the same components as the master node 100 [shows write operations of target user equipment])
Chan also teaches obtaining … the modification record. (Chan ¶ 0054-0059: After receiving the dirty page numbers and second global LSN, at step S.sub.5, the data node 132-1 provides the REDO logs for the transaction along with the transaction ID 302-1 of the transaction to the CLM 304 indicating enough data has been accumulated ... After the CLM 304 processes the group of REDO logs, the CLM 304 transmits a latest global LSN associated with the transaction and a status of the transaction (indicating whether the transaction was committed or aborted) to the data node 132-1 at step S.sub.8)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the redo logs of McAlister as modified with the redo log metadata of Chan.
In addition, both of the references (McAlister as modified and Chan) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as redo log management.
Motivation to do so would be to improve the functioning of McAlister as modified managing redo log records with the ability in similar reference Chan also receiving managing redo log records but with the improvement of additional metadata.
Motivation to do so would also be the teaching, suggestion, or motivation for a person of ordinary skill in the art to implement fast, efficient and economical conflict detection and resolution for multi-writer database systems as seen in Chan ¶ 0009.
McAlister in view of Burchall and Chan does not expressly disclose:
and wherein before determining the data corresponding to the read operation, the method further comprises:
obtaining a first replica channel identifier corresponding to the read operation, wherein the first replica channel identifier corresponds to a first replica channel between the proxy node and the target replica node, and wherein the first replica channel is configured to transmit read operations of the target user equipment; and
McAlister in view of Burchall and Chan further does not expressly disclose obtaining based on the first replica channel identifier.
However, Wang teaches:
and wherein before determining the data corresponding to the read operation, the method further comprises: (Wang FIG. 5, ¶ 0141-0143: Step S509 [shows occurrence later in operations]: The standby node performs a corresponding operation on a storage unit, in a local cache, that is indicated by the corresponding operation record … After receiving the operation record, the standby node first determines whether the storage unit corresponding to the operation record exists in the local cache of the standby node. If the storage unit corresponding to the operation record exists in the local cache of the standby node, the operation record is applied to the corresponding storage unit)
obtaining a first replica channel identifier corresponding to the read operation, (Wang FIGs. 5-6, ¶ 0130-0132: Step S505: The control node determines a second storage unit set in a standby node … The mapping table includes at least one entry. Each entry may include an identifier of a standby node, identifiers of storage units in a local cache of the standby node, an address of the standby node, and the like. Specifically, the identifier of the standby node may be a standby node number, the identifier of the storage unit may be a storage unit number (such as a page number))
wherein the first replica channel identifier corresponds to a first replica channel between the proxy node and the target replica node, (Wang FIG. 3-D, ¶ 0104: the database system includes: one primary node, a standby node used as a control node, another standby node, and a storage device; Wang FIG. 5, ¶ 0131: the control node further needs to determine a storage unit set in a standby node in the database system, that is, determine a storage unit in each standby node)
and wherein the first replica channel is configured to transmit read operations of the target user equipment; (Wang FIG. 2, FIG. 5, ¶ 0139-0140: Step S508: The control node sends the corresponding operation record to the standby node; see Wang ¶ 0144: When performing a read/write transaction, the primary node modifies the page 1, the page 2, and the page 3, correspondingly generates an operation log (including a redo log 1, a redo log 2, and a redo log 3), and sends the operation log to the control node [shows read operations within the redo logs])
Wang also teaches obtaining based on the first replica channel identifier. (Wang FIG. 2, FIG. 5, ¶ 0139-0140: Step S508: The control node sends the corresponding operation record to the standby node [occurs after standby node determination of S504-S505, showing being based on the first replica channel identifier]; see Wang ¶ 0144: When performing a read/write transaction, the primary node modifies the page 1, the page 2, and the page 3, correspondingly generates an operation log (including a redo log 1, a redo log 2, and a redo log 3), and sends the operation log to the control node)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the redo logs of McAlister as modified with the redo log identifiers of Wang.
In addition, both of the references (McAlister as modified and Wang) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as redo log management.
Motivation to do so would be to improve the functioning of McAlister as modified managing redo log records with the ability in similar reference Wang also receiving managing redo log records but with the improvement of additional metadata.
Motivation to do so would also be the teaching, suggestion, or motivation for a person of ordinary skill in the art to reduce invalid data transmission between a primary node and a standby node, thereby reducing CPU consumption of the primary node/standby node and network bandwidth resource waste, as seen in Wang ¶ 0006.
Regarding claims 3, 9, and 15, McAlister in view of Burchall and Chan and Wang teaches:
wherein obtaining the modification record comprises: determining … a target transaction that is established during processing of the redo log and that corresponds to the redo log; and (Chan ¶ 0026: receiving, from a global transaction manager (GTM), a set of active transactions, a first global log sequence number (LSN) and an associated transaction identifier (ID) corresponding to a transaction; Chan ¶ 0054: The snapshot includes information related to a current status of the database, including a list of historical transactions, an identifier of each transaction in the list of transactions (referred to hereinafter as transaction ID); Chan ¶ 0056-0057: At step S.sub.2, the coordinator node 130-1 then passes the snapshot of the database received from the GTM module 302, and an identifier of the initiated transaction (transaction ID) to the data node 132-1)
obtaining the modification record based on a correspondence between the modification record and the target transaction. (Chan ¶ 0026: transmitting a REDO log associated with the current transaction to the CLM; Chan ¶ 0054-0059: After receiving the dirty page numbers and second global LSN, at step S.sub.5, the data node 132-1 provides the REDO logs for the transaction along with the transaction ID 302-1 of the transaction to the CLM 304 indicating enough data has been accumulated ... After the CLM 304 processes the group of REDO logs, the CLM 304 transmits a latest global LSN associated with the transaction and a status of the transaction (indicating whether the transaction was committed or aborted) to the data node 132-1 at step S.sub.8)
Wang teaches performing a “determining, based on the first replica channel identifier … that corresponds to the redo log.” (Wang FIG. 5, ¶ 0130-0136, see first replica channel identifier in at least ¶ 0132: the identifier of the standby node may be a standby node number, the identifier of the storage unit may be a storage unit number (such as a page number), and the address of the standby node may be an IP/MAC address of the standby node; see Wang ¶ 0135-0138: the control node determines a modified page in the primary node by using step S504, and determines a page in each standby node by using step S505. Therefore, the control node may determine a page that needs to be updated in the standby node ... the operation log includes multiple operation records, each operation record is a redo log, and each redo log includes an identifier of a modified page in the primary node (for example, a redo log 1 includes an identifier of the page 1, and a redo log 2 includes an identifier of the page 2) [shows corresponding to the redo log])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the redo logs of McAlister as modified with the redo log identifiers of Wang.
Motivation to do so would be to improve the functioning of McAlister as modified managing redo log records with the ability in similar reference Wang also receiving managing redo log records but with the improvement of additional metadata.
Regarding claims 4, 10, and 16, McAlister in view of Burchall and Chan and Wang teaches:
…a first correspondence between the first master channel identifier and the first … identifier, (Chan ¶ 0051: The one REDO log contains an identifier (ID) associated with the master node (referred to hereinafter as master node ID) (e.g. master node 100-1, where the REDO log comes from) and log sequence number (LSN) mapping information (i.e., information indicative of a mapping of a local LSN associated with the master node (e.g. master node 100-1))
wherein the method further comprises adding, during processing of the redo log, the first master channel identifier in the redo log and the target transaction into a second correspondence between a master channel identifier and a transaction, (Chan FIG. 3, ¶ 0050-0053: each of the master nodes 100-1 and 100-2 may be configured to accumulate and group together various associated REDO logs and transmit the group of REDO logs towards the CLM 304 ... After detecting a write-write conflict, the WWCD 308 [shown in FIG. 3 to be within CLM 304] provides the one REDO log to the log persist module 310 ... The log persist module 310 receives the one REDO log from the WWCD 308 and persists the received one REDO log to the CLM storage 314 ... The GSC 312 module reads the REDO logs that have been persisted to the CLM storage 314, extracts information from the REDO logs, including the list of transactions, dirty pages numbers, master node ID, local LSN, and global LSN etc., and provides the extracted information to the master nodes 100-1 and 100-2 [relevant to second correspondence]; see relatedly Chan ¶ 0073: the group of REDO logs, while being transmitted to CLM 304, may be accompanied by the transaction ID 302-1 )
and wherein determining the target transaction comprises: determining, based on the first correspondence, that the first master channel identifier corresponds to the … channel identifier; and (Chan ¶ 0051: The one REDO log contains an identifier (ID) associated with the master node (referred to hereinafter as master node ID) (e.g. master node 100-1, where the REDO log comes from) and log sequence number (LSN) mapping information (i.e., information indicative of a mapping of a local LSN associated with the master node (e.g. master node 100-1))
determining, based on the second correspondence, that the target transaction corresponds to the first master channel identifier. (Chan FIG. 3, ¶ 0050-0053: The GSC 312 module reads the REDO logs that have been persisted to the CLM storage 314, extracts information from the REDO logs, including the list of transactions, dirty pages numbers, master node ID [relevant to master channel identifier], local LSN, and global LSN etc., and provides the extracted information to the master nodes 100-1 and 100-2 [relevant to second correspondence]; see relatedly Chan ¶ 0073: the group of REDO logs, while being transmitted to CLM 304, may be accompanied by the transaction ID 302-1 )
Wang teaches wherein the target replica node stores … the first replica channel identifier. (Wang FIG. 6, ¶ 0132-0133: The mapping table includes at least one entry. Each entry may include an identifier of a standby node, identifiers of storage units in a local cache of the standby node, an address of the standby node, and the like ... Entries in the mapping table may include related mapping information of all standby nodes in the database system; FIG. 8, Step S802, ¶ 0150-0153: The registration request includes an identifier of the standby node 1 and an identifier (a page number) of the page 8. After receiving the registration request, the control node determines, according to the identifier of the standby node 1, that an entry corresponding to an identifier of the standby node 1 is an entry 1. Then, the control node adds the identifier of the page 8 to the entry 1, that is, page numbers <1, 6, and 7>in the entry 1 in the mapping table are updated to page numbers <1, 6, 7, and 8>)
Wang further teaches determining, based on the first correspondence … the first replica channel identifier. (Wang FIG. 8, ¶ 0174-0177: by querying the mapping table, the primary node determines that the standby node 1 and the standby node 2 exist in the database system, and may determine a page in the standby node 1 and a page in the standby node 2)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the redo logs of McAlister as modified with the redo log identifiers of Wang.
Motivation to do so would be to improve the functioning of McAlister as modified managing redo log records with the ability in similar reference Wang also receiving managing redo log records but with the improvement of additional metadata.
Regarding claims 5, 11, and 17, McAlister in view of Burchall and Chan and Wang teaches:
…a first correspondence between the first master channel identifier and the first … identifier, (Chan ¶ 0051: The one REDO log contains an identifier (ID) associated with the master node (referred to hereinafter as master node ID) (e.g. master node 100-1, where the REDO log comes from) and log sequence number (LSN) mapping information (i.e., information indicative of a mapping of a local LSN associated with the master node (e.g. master node 100-1))
wherein the method further comprises: determining, during processing of the redo log and based on the first correspondence, the first … identifier corresponding to the first master channel identifier in the redo log; and (Chan ¶ 0051: The WWCD 308 checks for a write-write conflict by analyzing the one REDO log [relevant to processing] to determine whether the one REDO log modifies the same page (or same tuple) as any other REDO log in the log buffer. After detecting a write-write conflict, the WWCD 308 provides the one REDO log to the log persist module 310. The one REDO log contains an identifier (ID) associated with the master node (referred to hereinafter as master node ID) (e.g. master node 100-1, where the REDO log comes from) [shows corresponding to a master channel identifier] and log sequence number (LSN) mapping information (i.e., information indicative of a mapping of a local LSN associated with the master node (e.g. master node 100-1); see also Chan ¶ 0053: The GSC 312 module reads the REDO logs that have been persisted to the CLM storage 314, extracts information from the REDO logs, including the list of transactions, dirty pages numbers, master node ID, local LSN, and global LSN etc., and provides the extracted information to the master nodes 100-1 and 100-2)
adding the first … identifier and the target transaction into a third correspondence between a replica channel identifier and a transaction, (Chan ¶ 0050-0052: each of the master nodes 100-1 and 100-2 may be configured to accumulate and group together various associated REDO logs and transmit the group of REDO logs towards the CLM 304; see then Chan ¶ 0054-0057: The snapshot includes information related to a current status of the database, including a list of historical transactions, an identifier of each transaction in the list of transactions (referred to hereinafter as transaction ID) [shows target transaction], a status of each transaction in the list historical transactions (i.e., whether a given transaction in the list of transactions is active or committed), and a global LSN associated with each transaction ID)
McAlister in view of Burchall and Chan and Wang also teaches the third correspondence. (Chan FIG. 4, ¶ 0056-0057: At step S.sub.2, the coordinator node 130-1 then passes the snapshot of the database received from the GTM module 302 [shows involvement of the third correspondence], and an identifier of the initiated transaction (transaction ID) to the data node 132-1)
Chan as utilized in McAlister in view of Burchall and Chan and Wang does not expressly disclose the following limitations, addressed by Wang.
Wang teaches wherein the target replica node stores … the first replica channel identifier. (Wang FIG. 6, ¶ 0132-0133: The mapping table includes at least one entry. Each entry may include an identifier of a standby node, identifiers of storage units in a local cache of the standby node, an address of the standby node, and the like ... Entries in the mapping table may include related mapping information of all standby nodes in the database system; FIG. 8, Step S802, ¶ 0150-0153: The registration request includes an identifier of the standby node 1 and an identifier (a page number) of the page 8. After receiving the registration request, the control node determines, according to the identifier of the standby node 1, that an entry corresponding to an identifier of the standby node 1 is an entry 1. Then, the control node adds the identifier of the page 8 to the entry 1, that is, page numbers <1, 6, and 7>in the entry 1 in the mapping table are updated to page numbers <1, 6, 7, and 8>)
Wang further teaches determining … the first replica channel identifier (Wang FIG. 8, ¶ 0174-0177: Step S808: The control node determines a first storage unit set corresponding to the operation log … by querying the mapping table, the primary node determines that the standby node 1 and the standby node 2 exist in the database system, and may determine a page in the standby node 1 and a page in the standby node 2)
Wang further teaches adding the first replica channel identifier. (Wang FIGs. 8-9, ¶ 0150-0153: Step S802 … updates a mapping table based on the registration request … the control node determines, according to the identifier of the standby node, a mapping table entry corresponding to the identifier of the standby node, and adds the identifier of the to-be-registered storage unit to the entry corresponding to the identifier of the standby node, to update the mapping table; see ¶ 0153: The registration request includes an identifier of the standby node 1 and an identifier (a page number) of the page 8 ... the control node adds the identifier of the page 8 to the entry 1, that is, page numbers <1, 6, and 7>in the entry 1 in the mapping table are updated to page numbers <1, 6, 7, and 8>. The control node updates the mapping table)
Wang further teaches:
wherein determining the target transaction comprises searching the … correspondence for the target transaction based on the first replica channel identifier. (Wang FIG. 8, ¶ 0173-0186, see first ¶ 0173: After generating the operation log, the primary node sends the operation log to the control node based on the identifier of the control node; see then ¶ 0176: Step S809 ... by querying the mapping table, the primary node determines that the standby node 1 and the standby node 2 exist in the database system, and may determine a page in the standby node 1 and a page in the standby node 2; see then ¶ 0181-0186: The control node obtains an operation record corresponding to the storage unit intersection set from the operation log ... Step S813: The standby node performs a corresponding operation on a storage unit, in a local cache, that is indicated by the corresponding operation record)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the redo logs of McAlister as modified with the redo log identifiers of Wang.
Motivation to do so would be to improve the functioning of McAlister as modified managing redo log records with the ability in similar reference Wang also receiving managing redo log records but with the improvement of additional metadata.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Lee et al., U.S. Patent Application Publication No. 2016/0147813, "Distributed Transaction Commit Protocol"; see Lee FIGs. 4-7 describing disk storage, coordinator nodes, and cohort nodes, and Lee ¶ 0037, "The transaction logs may include undo and redo logs, which allow cohort node 406 to undo or redo transactions when necessary,” relevant to at least the independent claims involving a master node, a proxy node, and a target replica node and further involving a redo log.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JEDIDIAH P FERRER whose telephone number is (571)270-7695. The examiner can normally be reached Monday, Tuesday, Friday, 12:00pm-9:00pm.
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, Kavita Stanley can be reached at (571)272-8352. 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.
/J.P.F/Examiner, Art Unit 2153 June 8, 2026
/KAVITA STANLEY/Supervisory Patent Examiner, Art Unit 2153
Prosecution Insights