DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
The amendment filed 6/18/2026 has been entered. Claims 1, 7, 8, 13, 15, 18, and 20 stand amended. Claims 9 and 11 stand cancelled. Claims 1-8, 10, 12-20 stand pending.
Information Disclosure Statement
The IDS filed 6/18/2026 has been considered by examiner.
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 (i.e., changing from AIA to pre-AIA ) 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.
Claim(s) 1-8, 10, 12-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chen at al. in US Patent Application Publication № 2022/0171787, hereinafter called Chen, in combination with Leshinsky et al. in US Patent Application Publication № 2017/0132091, hereinafter called Leshinsky.
In regard to claim 1, Chen teaches a computer-implemented method comprising:
executing, by a cluster of computing nodes, an object-relational database management system (an OBDMS is expressly contemplated, “The DBMS acronym is sometime extended to indicate the underlying database model, such as RDBMS for relational database model, OODBMS or ORDBMS for object (orientated) database model, and ORDBMS for object-relational database model.” Paragraph 0055) comprising a primary node and one or more read-replica nodes (“As used herein, the term "database master server" shall refer to a server or other node in a cloud-based database that is configured to handle modifications to the database including requests to insert, update, or delete database records. The term "database replica server" shall refer to a server or other node in the cloud-based database that is configured to handle only read requests, e.g., requests to select database records” paragraph 0015), the cluster of computing nodes sharing access to a shared block storage volume that stores an object-relational database (“A redo log record, also called a redo entry or log entry, holds a group of change vectors, each of which describes or represents a change made to a single block or page in the database” paragraph 0066);
receiving, by a replica node of the one or more read-replica nodes, log updates individually indicating a corresponding change to be made to the object-relational database (“In some examples, a log cache may be used by a replica node of the database to track recent redo log records applicable to a given page. The recent redo log records stored in the log cache may be applied to update the page on-demand when the current version of the page is requested.” Paragraph 0012);
receiving, by a read-replica node of the one or more read-replica nodes, a read request for data corresponding to the object-relational database (“The method comprises receiving from a client, at the database replica server, a request for a desired page of database data.” Paragraph 0016);
obtaining, by the read-replica node of the one or more read-replica nodes from the shared block storage volume, a version of a page of the object-relational database (“The database master server 212 always accesses (i.e., reads) the latest version of pages, which will be within the GFB boundary. The database replica server 214 lags behind the database master server 212. The version of the page accessible by the database replica server 214 may be made accessible as updates to the database page are completed based on at least the MTR boundary. That is, an updated page version (i.e., a version of a page that has been updated) may be made accessible to (i.e., to be read by) the database replica server 214 only after all redo log records within the same single MTR boundary have been processed. Respecting the MTR boundary in this manner will help to ensure database consistency. However, the boundary for processing records may be larger, for example a GFB boundary for a single GFB or even for a group of GFBs.” Paragraph 0093), the version of the page being associated with a first log sequence number (an earlier LSN shown in at least paragraph 101 relative to the most recent LSN shown in at least paragraph 100);
storing the version of the page obtained from the shared block storage volume in local memory of the read-replica node (“(“In response to receiving the request for the desired page a stored version of the desired page is retrieved,” paragraph 0067, further, the read and update of a page and a specification of a particular version is taught in at least paragraph 0134);
generating, by the read-replica node of the one or more read-replica nodes, an updated version of the page of the object-relational database based at least in part on sequentially applying a subset of the log updates to the previous version of the page that is stored in local memory of the read-replica node, each of the subset of the log updates being associated with a respective log sequence number that is larger than the first log sequence number (“In response to receiving the request for the desired page a stored version of the desired page is retrieved. One or more redo log records associated with the desired page are retrieved from a log cache. The one or more redo log records are applied to the stored version of the desired page to generate an updated desired page. The updated desired page is sent from the database replica server to the client.” Paragraph 0016, wherein “A redo log record may also include a sequence
number, such as a log sequence number (LSN), indicating the location of the redo log record within the redo log. Generally, the LSN is assigned to a log record in the order in which the redo log record is entered in the GFB. The redo log records in the GFB are typically ordered in increasing LSN.” Paragraph 0067); and
providing, by the read-replica node of the one or more read-replica nodes, the data requested with the read request, the data being obtained from the updated version of the page that is stored in local memory of the read-replica node (“The updated desired page is sent from the database replica server to the client.” Paragraph 0016, wherein “The database replica server 214 includes a replica buffer pool 1214 for storing local versions of data pages.” Paragraph 0101).
However, although Chen teaches retrieving data from multiple areas (paragraph 0134) and a shared log cache (paragraph 0107) which can apply updates to stored pages (paragraph 0105) Chen fails to expressly teach that the shared block storage volume comprising a staging area storing a first set of pages that were recently modified and for which corresponding log updates have not been stored at each of the one or more read-replica nodes of the object-relational database, the shared block storage volume further comprising a main area storing a second set of pages of the object- relational database for which respective log updates have been synchronized at each of the one or more read-replica nodes;
Or that the version of the page being obtained from the main area based at least in part on the first log-sequence number and a second log sequence number associated with the staging area.
Leshinsky teaches that the shared block storage volume (i.e. SSD) comprising a staging area storing a first set of pages that were recently modified and for which corresponding log updates have not been stored at each of the one or more read-replica nodes of the object-relational database (i.e. append-only log-structured region, paragraph 0052; alternatively or additionally, hot log zone, paragraph 0109, wherein “In some embodiments, the hot log zone may accept new writes from the client as they are received by the storage node. Both Delta User Log Records (DULRs), which specify a change to a user/data page in the form of a delta from the previous version of the page, and Absolute User Log Records (AULRs), which specify the contents of a complete user/data page, may be written completely into the log.” Paragraph 0110), the shared block storage volume further comprising a main area storing a second set of pages of the object- relational database for which respective log updates have been synchronized at each of the one or more read-replica nodes (i.e. larger coalesced zone, paragraph 0052; alternatively or additionally, user data zone, paragraph 0109, also, “As described herein coalescing is the process of applying DULRs to an earlier version of a user page to create a later version of the user page. Coalescing a user page may help reduce read latency because (until another DULR is written) all DULRs written prior to coalescing may not need to be read and applied on demand.” Paragraph 0121, note that coalescing may also be performed in the cold zone, paragraph 0131, and that logs are taught to be marked when distributed, “The log record, and attendant metadata, may then be sent to the determined protection group, as illustrated in FIG. 1. In some embodiments, based, at least in part, on acknowledgments received from storage nodes 118 implementing a protection group to which the log record is sent, the log record may be identified as eligible for durability to log 102.” Paragraph 0030);
Or that the version of the page being obtained from the main area based at least in part on the first log-sequence number and a second log sequence number associated with the staging area (“reading a cold user page (which may involve locating the data sectors of the user page and returning them without needing to apply any additional DULRs), reading a hot user page (which may involve locating the data sectors of the most recent AULR for the user page and apply any subsequent DULRs to the user page before returning it),” paragraph 0121).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the instant application to modify the shared storage database with log and data areas, as taught by Chen, to include the staging and replicated zones, as taught by Leshinsky. It would have been obvious because it represents the application of a known technique (i.e. coalescing data from an append-only log into user data which is made durable, as taught by Leshinsky in at least paragraph 0113, wherein durability is based on synchronization, paragraph 0120) to a known system (i.e. the database log storage system with a log and stored pages, as taught by Chen in at least paragraph 0134) ready for improvement to yield only predictable results (i.e. the data is coalesced from the log storage area into the permanent storage based on determination of data durability)
In regard to claim 2, Chen further teaches that the primary node alone is allowed to read from and write to the shared block storage volume (“Generally, the database master server 212 handles all modifications to the database (including requests to insert, update, or delete database records), and the database replica server(s) 214 handle only read requests (i.e., request to select database records). Database transactions, which include multiple statements such as insert, update, delete, select (i.e. read request), are handled by the database servers 212,214 in the compute layer 210.” Paragraph 0071; note that the claim as written appears to require that the performance of both reading and writing be exclusive, but does not address them separately).
In regard to claim 3, Chen further teaches that the read-replica node maintains an in-memory map of respective data segments of the object-relational database (“In some embodiments, the log cache 1240 is stored fully in memory. In other embodiments, the log cache 1240 may be stored with some parts in memory and some parts on fast accessible external storage, or entirely on fast accessible external storage with memory-based caching.” Paragraph 0108 ).
In regard to claim 4, Chen further teaches that the log updates are stored in an in-memory tree structure within the local memory of the read-replica node (“The locally stored pages in the replica buffer pool 1214 are shown as a B+ tree structure containing three pages: a local version of Page A corresponding to LSN=l00 1232, a local version of Page B corresponding to LSN=120 1234, and a local version of Page C corresponding to LSN=1501236. It will be appreciated that the locally stored versions of Page A 1232 and Page C 1236 are out of date relative to the most recent versions of Page A 1222 and Page C 1226 at the database master server 214 at LSN=200.” Paragraph 101).
In regard to claim 5, Chen further teaches that generating the updated version of the object-relational database is performed by a query process executing at the read-replica node (“In some embodiments, the log cache 1240 may be used by the database replica server 214 to perform on-demand application of redo log records (e.g., redo log records 1252 and 1258) to the locally stored pages (e.g., Page A 1232 and Page C 1236) in the replica buffer pool 1214. This on-demand redo log record application process is described in greater detail below with reference to FIG. 7” paragraph 0105).
In regard to claim 6, Chen further teaches that the shared block storage volume is managed by a block storage service of a cloud computing environment, the block storage service being configured to allow any of the cluster of computing nodes to read from the shared block storage volume, the block storage service restricting write access to the shared block storage volume to only the primary node (“Generally, the database master server 212 handles all modifications to the database (including requests to insert, update, or delete database records), and the database replica server(s) 214 handle only read requests (i.e., request to select database records). Database transactions, which include multiple statements such as insert, update, delete, select (i.e. read request), are handled by the database servers 212,214 in the compute layer 210.” Paragraph 0071)
In regard to claim 7, Chen further teaches that the version of the page of the object-relational database is obtained in response to the read request (“As described above, the state of the pages stored in the buffer pool of the database replica server 214 lags behind the latest transactions committed by the database master server 212” paragraph 0095, wherein “To address these limitations, example embodiments described herein may provide on-demand application of redo log records to a page stored in the buffer pool…” paragraph 0096).
In regard to claim 8, Chen teaches a computing device, comprising:
one or more processors; and
one or more memories that store computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to (“In some aspects, the present disclosure describes a computer-readable medium storing instructions thereon to be executed by a processor device in a cloud-based database comprising data stored in pages,” paragraph 0018):
execute a cluster of computing nodes of a cloud computing environment, the cluster of computing nodes comprising a primary node and a read-replica node of an object-relational database management system (“As used herein, the term "database master server" shall refer to a server or other node in a cloud-based database that is configured to handle modifications to the database including requests to insert, update, or delete database records. The term "database replica server" shall refer to a server or other node in the cloud-based database that is configured to handle only read requests, e.g., requests to select database records” paragraph 0015), the cluster of computing nodes sharing access to a shared block storage volume that stores an object-relational database (“A redo log record, also called a redo entry or log entry, holds a group of change vectors, each of which describes or represents a change made to a single block or page in the database” paragraph 0066);
receive, by the read-replica node, log updates individually indicating a corresponding change to be made to the object-relational database (“In some examples, a log cache may be used by a replica node of the database to track recent redo log records applicable to a given page. The recent redo log records stored in the log cache may be applied to update the page on-demand when the current version of the page is requested.” Paragraph 0012);
receive, by the read-replica node, a read request for data corresponding to the object-relational database (“The method comprises receiving from a client, at the database replica server, a request for a desired page of database data.” Paragraph 0016);
generate, in local memory of the read-replica node, a current version of a portion of the object-relational database based on 1) obtaining a version of the portion of the object-relational database and 2) applying the corresponding change identified by at least one of the log updates (“In response to receiving the request for the desired page a stored version of the desired page is retrieved. One or more redo log records associated with the desired page are retrieved from a log cache. The one or more redo log records are applied to the stored version of the desired page to generate an updated desired page. The updated desired page is sent from the database replica server to the client.” Paragraph 0016, wherein “A redo log record may also include a sequence
number, such as a log sequence number (LSN), indicating the location of the redo log record within the redo log. Generally, the LSN is assigned to a log record in the order in which the redo log record is entered in the GFB. The redo log records in the GFB are typically ordered in increasing LSN.” Paragraph 0067); and
provide, by the read-replica node, the data requested with the read request, the data being obtained from the current version of the portion of the object-relational database that is stored in local memory of the read-replica node (“The updated desired page is sent from the database replica server to the client.” Paragraph 0016, wherein “The database replica server 214 includes a replica buffer pool 1214 for storing local versions of data pages.” Paragraph 0101).
However, although Chen teaches retrieving data from multiple areas (paragraph 0134) and a shared log cache (paragraph 0107) which can apply updates to stored pages (paragraph 0105) Chen fails to expressly teach that the shared block storage volume comprising a staging area storing a first set of pages that were recently modified and for which corresponding log updates have not been stored at each of the one or more read-replica nodes of the object-relational database, the shared block storage volume further comprising a main area storing a second set of pages of the object- relational database for which respective log updates have been synchronized at each of the one or more read-replica nodes;
Or that the version of the page being obtained from the main area based at least in part on the first log-sequence number and a second log sequence number associated with the staging area.
Leshinsky teaches that the shared block storage volume (i.e. SSD) comprising a staging area storing a first set of pages that were recently modified and for which corresponding log updates have not been stored at each of the one or more read-replica nodes of the object-relational database (i.e. append-only log-structured region, paragraph 0052; alternatively or additionally, hot log zone, paragraph 0109, wherein “In some embodiments, the hot log zone may accept new writes from the client as they are received by the storage node. Both Delta User Log Records (DULRs), which specify a change to a user/data page in the form of a delta from the previous version of the page, and Absolute User Log Records (AULRs), which specify the contents of a complete user/data page, may be written completely into the log.” Paragraph 0110), the shared block storage volume further comprising a main area storing a second set of pages of the object- relational database for which respective log updates have been synchronized at each of the one or more read-replica nodes (i.e. larger coalesced zone, paragraph 0052; alternatively or additionally, user data zone, paragraph 0109, also, “As described herein coalescing is the process of applying DULRs to an earlier version of a user page to create a later version of the user page. Coalescing a user page may help reduce read latency because (until another DULR is written) all DULRs written prior to coalescing may not need to be read and applied on demand.” Paragraph 0121, note that coalescing may also be performed in the cold zone, paragraph 0131, and that logs are taught to be marked when distributed, “The log record, and attendant metadata, may then be sent to the determined protection group, as illustrated in FIG. 1. In some embodiments, based, at least in part, on acknowledgments received from storage nodes 118 implementing a protection group to which the log record is sent, the log record may be identified as eligible for durability to log 102.” Paragraph 0030);
Or that the version of the page being obtained from the main area based at least in part on the first log-sequence number and a second log sequence number associated with the staging area (“reading a cold user page (which may involve locating the data sectors of the user page and returning them without needing to apply any additional DULRs), reading a hot user page (which may involve locating the data sectors of the most recent AULR for the user page and apply any subsequent DULRs to the user page before returning it),” paragraph 0121).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the instant application to modify the shared storage database with log and data areas, as taught by Chen, to include the staging and replicated zones, as taught by Leshinsky. It would have been obvious because it represents the application of a known technique (i.e. coalescing data from an append-only log into user data which is made durable, as taught by Leshinsky in at least paragraph 0113, wherein durability is based on synchronization, paragraph 0120) to a known system (i.e. the database log storage system with a log and stored pages, as taught by Chen in at least paragraph 0134) ready for improvement to yield only predictable results (i.e. the data is coalesced from the log storage area into the permanent storage based on determination of data durability)
In regard to claim 10, Chen further teaches that the log updates are received from the primary node (“Operations performed by the master SAL module 222 include sending redo log record updates from the database master server 212 to the database replica server(s) 214 (arrow 202);” paragraph 0075).
In regard to claim 12, Chen further teaches that the shared block storage volume stores multiple versions of the object-relational database (“The database master server 212 always accesses (i.e., reads) the latest version of pages, which will be within the GFB boundary. The database replica server 214 lags behind the database master server 212. The version of the page accessible by the database replica server 214 may be made accessible as updates to the database page are completed based on at least the MTR boundary. That is, an updated page version (i.e., a version of a page that has been updated) may be made accessible to (i.e., to be read by) the database replica server 214 only after all redo log records within the same single MTR boundary have been processed. Respecting the MTR boundary in this manner will help to ensure database consistency. However, the boundary for processing records may be larger, for example a GFB boundary for a single GFB or even for a group of GFBs.” Paragraph 0093) and a write-ahead log that stores one or more log updates corresponding to the object-relational database (“sending information regarding the physical location of the redo log (i.e. identifying the log store 234) to enable the database replica server(s) 214 to know where to access (i.e., read) the latest redo log records (also arrow 202); accessing (i.e., reading) pages from the page store(s) 232 (dashed arrow 204); and writing redo log record to the log store(s) 234 (arrow 205) and page store(s) 232 (arrow 206)” paragraph 0075).
In regard to claim 13, Chen further teaches that each of the plurality of read-replica nodes being restricted from processing write requests (“Generally, the database master server 212 handles all modifications to the database (including requests to insert, update, or delete database records), and the database replica server(s) 214 handle only read requests (i.e., request to select database records).” Paragraph 0071).
In regard to claim 14, Chen further teaches that each computing node of the cluster of computing nodes individually executes a file system that supports a single-writer-multiple-reader model (“Generally, the database master server 212 handles all modifications to the database (including requests to insert, update, or delete database records), and the database replica server(s) 214 handle only read requests (i.e., request to select database records).” Paragraph 0071, wherein “In the context of FIG. 1, the SAL 220 may be considered to span the database service 126 and the virtualized storage resources 120, and provides a layer of abstraction that pools physical resources to serve both the database service 126 and the virtualized storage resources 120.” Paragraph 0072).
In regard to claim 15, Chen further teaches a computer-readable medium comprising one or more memories storing computer-executable instructions that, when executed by one or more processors of a cloud computing environment, cause the one or more processors to (“In some aspects, the present disclosure describes a computer-readable medium storing instructions thereon to be executed by a processor device in a cloud-based database comprising data stored in pages,” paragraph 0018):
execute at a portion of a cluster of computing nodes of the cloud computing environment, the cluster of computing nodes comprising a primary node and a read-replica node (“As used herein, the term "database master server" shall refer to a server or other node in a cloud-based database that is configured to handle modifications to the database including requests to insert, update, or delete database records. The term "database replica server" shall refer to a server or other node in the cloud-based database that is configured to handle only read requests, e.g., requests to select database records” paragraph 0015) of an object-relational database management system (an OBDMS is expressly contemplated, “The DBMS acronym is sometime extended to indicate the underlying database model, such as RDBMS for relational database model, OODBMS or ORDBMS for object (orientated) database model, and ORDBMS for object-relational database model.” Paragraph 0055), the cluster of computing nodes sharing access to a shared block storage volume that stores an object-relational database (“A redo log record, also called a redo entry or log entry, holds a group of change vectors, each of which describes or represents a change made to a single block or page in the database” paragraph 0066);
receive, by the read-replica node, log updates individually indicating a corresponding change to be made to the object-relational database (“In some examples, a log cache may be used by a replica node of the database to track recent redo log records applicable to a given page. The recent redo log records stored in the log cache may be applied to update the page on-demand when the current version of the page is requested.” Paragraph 0012);
receive, by the read-replica node, a read request for data corresponding to the object-relational database (“The method comprises receiving from a client, at the database replica server, a request for a desired page of database data.” Paragraph 0016);
generate, in local memory of the read-replica node, a current version of a portion of the object-relational database based on 1) obtaining a previous version of the portion of the object-relational databased and 2) applying the corresponding change identified by at least one of the log updates (“In response to receiving the request for the desired page a stored version of the desired page is retrieved. One or more redo log records associated with the desired page are retrieved from a log cache. The one or more redo log records are applied to the stored version of the desired page to generate an updated desired page. The updated desired page is sent from the database replica server to the client.” Paragraph 0016); and
provide, by the read-replica node, the data requested with the read request, the data being obtained from the current version of the portion of the object-relational database that is stored in local memory of the replica node (“The updated desired page is sent from the database replica server to the client.” Paragraph 0016, wherein “The database replica server 214 includes a replica buffer pool 1214 for storing local versions of data pages.” Paragraph 0101).
However, although Chen teaches retrieving data from multiple areas (paragraph 0134) and a shared log cache (paragraph 0107) which can apply updates to stored pages (paragraph 0105) Chen fails to expressly teach that the shared block storage volume comprising a staging area storing a first set of pages that were recently modified and for which corresponding log updates have not been stored at each of the one or more read-replica nodes of the object-relational database, the shared block storage volume further comprising a main area storing a second set of pages of the object- relational database for which respective log updates have been synchronized at each of the one or more read-replica nodes;
Or that the version of the page being obtained from the main area based at least in part on the first log-sequence number and a second log sequence number associated with the staging area.
Leshinsky teaches that the shared block storage volume (i.e. SSD) comprising a staging area storing a first set of pages that were recently modified and for which corresponding log updates have not been stored at each of the one or more read-replica nodes of the object-relational database (i.e. append-only log-structured region, paragraph 0052; alternatively or additionally, hot log zone, paragraph 0109, wherein “In some embodiments, the hot log zone may accept new writes from the client as they are received by the storage node. Both Delta User Log Records (DULRs), which specify a change to a user/data page in the form of a delta from the previous version of the page, and Absolute User Log Records (AULRs), which specify the contents of a complete user/data page, may be written completely into the log.” Paragraph 0110), the shared block storage volume further comprising a main area storing a second set of pages of the object- relational database for which respective log updates have been synchronized at each of the one or more read-replica nodes (i.e. larger coalesced zone, paragraph 0052; alternatively or additionally, user data zone, paragraph 0109, also, “As described herein coalescing is the process of applying DULRs to an earlier version of a user page to create a later version of the user page. Coalescing a user page may help reduce read latency because (until another DULR is written) all DULRs written prior to coalescing may not need to be read and applied on demand.” Paragraph 0121, note that coalescing may also be performed in the cold zone, paragraph 0131, and that logs are taught to be marked when distributed, “The log record, and attendant metadata, may then be sent to the determined protection group, as illustrated in FIG. 1. In some embodiments, based, at least in part, on acknowledgments received from storage nodes 118 implementing a protection group to which the log record is sent, the log record may be identified as eligible for durability to log 102.” Paragraph 0030);
Or that the version of the page being obtained from the main area based at least in part on the first log-sequence number and a second log sequence number associated with the staging area (“reading a cold user page (which may involve locating the data sectors of the user page and returning them without needing to apply any additional DULRs), reading a hot user page (which may involve locating the data sectors of the most recent AULR for the user page and apply any subsequent DULRs to the user page before returning it),” paragraph 0121).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the instant application to modify the shared storage database with log and data areas, as taught by Chen, to include the staging and replicated zones, as taught by Leshinsky. It would have been obvious because it represents the application of a known technique (i.e. coalescing data from an append-only log into user data which is made durable, as taught by Leshinsky in at least paragraph 0113, wherein durability is based on synchronization, paragraph 0120) to a known system (i.e. the database log storage system with a log and stored pages, as taught by Chen in at least paragraph 0134) ready for improvement to yield only predictable results (i.e. the data is coalesced from the log storage area into the permanent storage based on determination of data durability)
In regard to claim 16, Chen further teaches that the log updates are stored in a tree data structure (“The locally stored pages in the replica buffer pool 1214 are shown as a B+ tree structure” paragraph 0101), and wherein applying changes corresponding to the log updates comprises traversing the tree data structure (“The log cache 1240 provides an efficient lookup interface for use by the database replica server 214. Given a page identifier (e.g. "Page A", or a page ID number corresponding to Page A) and a range of page versions ( e.g., starting LSN and ending LSN), the log cache 1240 may return corresponding redo log record contents for all redo log records in the corresponding lookup table 1242 entry that are within the range of page versions” paragraph 0104, wherein “In some embodiments, the log cache 1240 may be used by the database replica server 214 to perform ondemand application of redo log records (e.g., redo log records 1252 and 1258) to the locally stored pages (e.g., Page A 1232 and Page C 1236) in the replica buffer pool” paragraph 0105).
In regard to claim 17, Chen further teaches that the log updates are received from a journal stream, wherein the primary node is a publisher of the journal stream, and wherein the read-replica node is a subscriber of the journal stream (“Operations performed by the master SAL module 222 include sending redo log record updates from the database master server 212 to the database replica server(s) 214 (arrow 202); […] Operations performed by the replica SAL module 223 include receiving redo log record updates from the database master server 212 (arrow 202);” paragraph 0075).
In regard to claim 18, Chen further teaches that executing the computer-executable instructions further causes the one or more processors to transmit, by the read-replica node to the primary node, an update request for the log updates, wherein the update request comprises a current log position corresponding to a last log update applied by the read-replica node to in-memory data (“The log cache may be used in some embodiments to keep track of the latest page update ( e.g., current LSN) from the database master server 212 and provide a lookup interface to allow the database replica server 214 to obtain redo log records applicable to a particular page key (e.g., applicable to a requested page) and a range of versions.” Paragraph 0097).
In regard to claim 19, Chen further teaches that executing the computer-executable instructions further causes the one or more processors to start a second read-replica node to execute as part of the cluster of computing nodes (a second node is expressly contemplated, “The compute layer 210 includes a database master server 212 (also referred to simply as master 212) and one or more database replica servers 214 (also referred to simply as replica(s) 214). The database master server 212 and database replica server(s) 214 may be generally referred to as database servers 212, 214.” Paragraph 0071), wherein the second read-replica node accesses the shared block storage volume to update local storage (“When a read request for a particular page is received from a client, the database replica server 214 retrieves a copy of the page stored in the replica buffer pool 1214, looks up the page in the lookup table 1242 of the log cache 1240, and applies any redo log records associated with the lookup table entry for the page that are required to bring the last version of the page in the replica buffer pool 1214. If the requested page is not present in the replica buffer pool 1214, the database replica server 214 may retrieve the last version of the page stored in the page store(s) 232.” Paragraph 0134).
In regard to claim 20, Chen further teaches that the second read-replica node executes operations that cause the second replica node to:
receive a second read request for the data corresponding to the object-relational database;
generate, in second local memory of the second read-replica node, a new version of the portion of the object-relational database based on 1) obtaining a second previous version of the portion of the object-relational databased and 2) applying one or more corresponding changes identified by at least one of the log updates; and
provide, by the second read-replica node, the data requested with the second read request, the data being obtained from the new version of the portion of the object-relational database that is stored in the local memory of the second read-replica node (“receive, from a client, a request for a desired page of database data, and in response to receiving the request for the desired page, retrieve a stored version of the desired page, retrieve one or more redo log records associated with the desired page, apply the one or more redo log records to the stored version of the desired page to generate an updated desired page, and send, to the client, the updated desired page.” Paragraph 0018; wherein a second server is contemplated, “In a cloud database 200 with multiple database replica servers 214, each such database replica server 214 could have its own log cache 1240, or a single log cache 1240 could be shared by multiple database replica servers 214.” Paragraph 0107, and multiple requests are expressly considered, “Registration of new redo log records into the log cache 1240 may be done after the database master server 212 writes the redo log records into cloud storage (e.g., log store(s) 234 and page store(s) 232), and before the database replica server(s) 214 make the corresponding changes visible to transactions (i.e., read requests received from clients).” Paragraph 0110).
Response to Arguments
In regard to the previous rejection of claim 9 under 35 U.S.C. 112(b), it is obviated as the claim has been cancelled.
Applicant’s arguments, see pages 8-11, filed 4/28/2026, with respect to the rejection(s) of claim(s) 1-20 under 35 U.S.C. 102(a)(1) have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Chen and Leshinsky. For more information, please refer to the relevant sections above.
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 Lauren Z Ganger whose telephone number is (571)272-0270. The examiner can normally be reached 10:00 AM - 7:30 PM.
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, Ajay Bhatia can be reached at (571) 272-3906. 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.
/AJAY M BHATIA/Supervisory Patent Examiner, Art Unit 2156
Prosecution Insights