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 .
DETAILED ACTION
This Office Action is in response to the application filed on 02/27/2025.
Claims 1-20 are pending.
Information Disclosure Statement
The information disclosure statement (IDS) filed on 02/27/2025 has been considered (see form-1449, MPEP 609).
Drawings
The drawings filed on 02/27/2025 are accepted.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-19 of U.S. Patent No. 12,253916. Although the conflicting are not patentably distinct from each other because since the claims of the Patent No.12,253,916 contains every element of the claims of the instant application, and as such, anticipate the claims of the instant application 19/065727. (See table below).
Instant Application claim 1
Patent No. 12,253916 claim 1
A method, comprising: executing, by a database system, a plurality of database transactions, wherein the executing includes writing records for the plurality of database transactions into an in-memory cache of the database system; performing, by the database system, a first flush operation to flush committed records from the in-memory cache to a persistent storage, wherein the committed records correspond to one or more of the plurality of database transactions that have committed; and generating, by the database system, checkpoint information for use in a database recovery routine, wherein the checkpoint information identifies active database transactions of the plurality of database transactions that were active and not committed at a flush point associated with the first flush operation, and wherein the checkpoint information enables the database system to skip replaying, during the database recovery routine, committed or aborted database transactions of the plurality of database transactions that occurred between a recovery start point of the database recovery routine and the flush point such that less than a total number of the plurality of database transactions is replayed.
A method for implementing a database recovery routine to start up a database system in response to a database failure, the method comprising: accessing, by the database system, checkpoint information that identifies a set of active database transactions that were active at a flush point that occurred before the database failure, wherein the flush point corresponds to an execution of a flush operation in which records of at least one committed database transaction were flushed to a database repository; and as a part of the database recovery routine, the database system replaying a plurality of database transactions within a recovery window comprising two sections, a first section defined by a recovery start point and the flush point and a second section defined by the flush point and a recovery end point, wherein the replaying includes: for the first section, replaying the set of active database transactions but excluding any committed or aborted database transactions that occurred within the first section such that less than a total number of database transactions occurring within the first section are replayed; and for the second section, replaying, without excluding committed or aborted database transactions, database transactions occurring within the second section.
Claims 1-10 of Patent No. 12,253916 satisfies all the elements of claims 2-8 of the instant application, and as such, anticipates the claims of instant application.
Instant Application claim 9
Patent No.12,253916 claim 11
A non-transitory computer-readable medium having program instructions stored thereon that are capable of causing a computer system to perform operations comprising: executing a plurality of database transactions, wherein the executing includes writing records for the plurality of database transactions into an in-memory cache of the computer system; performing a first flush operation to flush committed records from the in-memory cache to a persistent storage, wherein the committed records correspond to one or more of the plurality of database transactions that have committed; and generating checkpoint information for use in a database recovery routine, wherein the checkpoint information identifies active database transactions of the plurality of database transactions that were active and not committed at a flush point associated with the first flush operation, and wherein the checkpoint information enables a database system to skip replaying, during the database recovery routine, committed or aborted database transactions of the plurality of database transactions that occurred between a recovery start point of the database recovery routine and the flush point such that less than a total number of the plurality of database transactions is replayed.
A non-transitory computer-readable medium having program instructions stored thereon that are capable of causing a computer system to perform operations comprising: accessing checkpoint information that identifies active database transactions that were active at a particular point that occurred before a database failure; and as a part of a database recovery routine, replaying a plurality of database transaction within a recovery window comprising two sections, a first section defined by a recovery start point and the particular point and a second section defined by the particular point and a recovery end point, wherein the replaying includes: for the first section, replaying the active database transactions but excluding any committed database transactions that occurred within the first section such that less than a total number of database transactions occurring within the first section are replayed; and for the second section, replaying, without excluding committed database transactions, database transactions occurring within the second section.
Claims 11-15 of Patent No. 12,253916 satisfies all the elements of claims 10-14 of the instant application, and as such, anticipates the claims of instant application.
Instant Application claim 15
Patent No.12,253916 claim 16
A system, comprising: at least one processor; and a memory having program instructions stored thereon that are executable by the at least one processor to cause the system to perform operations comprising: executing a plurality of database transactions, wherein the executing includes writing records for the plurality of database transactions into an in-memory cache of the system; performing a first flush operation to flush committed records from the in-memory cache to a persistent storage, wherein the committed records correspond to one or more of the plurality of database transactions that have committed; and generating checkpoint information for use in a database recovery routine, wherein the checkpoint information identifies active database transactions of the plurality of database transactions that were active and not committed at a flush point associated with the first flush operation, and wherein the checkpoint information enables the system to skip replaying, during the database recovery routine, committed or aborted database transactions of the plurality of database transactions that occurred between a recovery start point of the database recovery routine and the flush point such that less than a total number of the plurality of database transactions is replayed.
A system, comprising: at least one processor; and a memory having program instructions stored thereon that are executable by the at least one processor to cause the system to perform operations comprising: accessing checkpoint information that identifies a set of active database transactions that were active at a flush point that occurred before a database failure, wherein the flush point corresponds to an execution of a flush operation in which records of at least one committed database transaction were flushed to a database repository; and replaying a plurality of database transaction within a recovery window comprising two sections, a first section defined by a recovery start point and the flush point and a second section defined by the flush point and a recovery end point, wherein the replaying includes: for the first section, replaying the set of active database transactions but excluding any committed or aborted database transactions that occurred within the first section such that less than a total number of database transactions occurring within the first section are replayed; and for the second section, replaying, without excluding committed or aborted database transactions, database transactions occurring within the second section.
Claims 16-19 of Patent No. 12,253916 satisfies all the elements of claims 16-20 of the instant application, and as such, anticipates the claims of instant application.
Examiner Notes
Examiner cites particular columns, paragraphs, figures and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the 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.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-6, 9-10, 12 and 15-18 are rejected under 35 U.S.C. 103 as being unpatentable over Schreter et al. (US PGPUB 2022/0382650, hereinafter Schreter), in view of Abouzour et al. (US PGPUB 2022/0164335, hereinafter Abouzour).
As per as claim 1, Schreter discloses:
A method, comprising:
executing, by a database system, a plurality of database transactions, wherein the executing includes writing records for the plurality of database transactions into an in-memory cache of the database system (Schreter, e.g., [003-005], “...at least one memory may include program code that provides operations when executed by the at least one processor. The operations may include: performing, at each of a plurality of data partitions, a point-in-time recovery to a specified time... copy of a first transaction log that includes a plurality of transactions performed at each of the plurality of data partitions may be generated at each of the plurality of data partitions...”);
performing, by the database system, a first flush operation to flush committed records from the in-memory cache to a persistent storage, wherein the committed records correspond to one or more of the plurality of database transactions that have committed (Schreter, e.g., [006-0011], “... commit or rollback the one or more transactions... a transaction may be rolled back by at least setting a transaction control block of the transaction to an aborting state, writing a rollback log record for the transaction, performing one or more post-rollback operations, and upon writing the rollback log record and completing the one or more post-rollback operations...”); and
generating, by the database system, checkpoint information for use in a database recovery routine, wherein the checkpoint information identifies active database transactions of the plurality of database transactions that were active and not committed at a flush point associated with the first flush operation, and wherein the checkpoint information enables the database system to skip replaying, during the database recovery routine, committed or aborted database transactions of the plurality of database transactions that occurred between a recovery start point of the database recovery routine and the flush point such that less than a total number of the plurality of database transactions is replayed (Schreter, e.g., [0021-0022], “...applying one or more transactions that have committed at each of the plurality of data partitions up to the specified time...identifying one or more open transactions that have not been committed at each of the plurality of data partitions at the specified time...” and [0091-0093], “....write an ABORT log record and enter the transaction in the rollback transaction table (RTT) at the data partition. The data partition may inform the transaction coordinator of the ABORT log record without waiting for the record to be durably written... generate a commit identifier... COMMIT log record is durably written at every participating data partition, the transaction coordinator may confirm the commit to the frontend driver and remove the transaction control block of the transaction...”).
To further clarify the features of “flush committed records” and “flush point such that less than a total number of the plurality of database transactions is replayed”.
However Abouzour, in an analogous art, discloses “flush committed records” (Abouzour, e.g., [0048-0049], “... flush a dirty page of a buffer pool to persistent storage...” and [0058-0059], [0062], “... flushed reflects a new table-level version...”, [0069], (...flushing the data structure disk...)), “flush point such that less than a total number of the plurality of database transactions is replayed” (Abouzour, e.g., [0074-0080], “... transaction commits, its RF/RB bitmaps are flushed to storage, the identities of the bitmaps are recorded in the transaction log...transaction manager maintains a chain of committed transactions with pointers to the associated RF/RB bitmaps and tracks the oldest transaction in the chain whose pages are still referenced by active transactions... the transaction log is replayed from the checkpointed state... the commit of T.sub.1 is replayed at clock 90, the active set is updated to W.sub.1: {131-200} because the committed range of object keys {101-130} no longer needs to be tracked...”). Thus, it would have been obvious to one of ordinary skill in the art BEFORE the effective filling date of the claimed invention to combine the teaching of Abouzour and Schreter to provide a database client with the most up-to-date version of an updated object but may provide stale versions of the object in the meantime and allow updates to a stored object with strong read-after-write consistency, and therefore are not compatible with page update protocols of traditional disk-based relational database management systems (Abouzour, e.g., [0003-0005]).
As per as claim 2, the combination of Abouzour and Schreter disclose:
The method of claim 1, wherein the executing includes writing log records for the plurality of database transactions to a transaction log, and wherein the checkpoint information specifies, for a particular one of the active database transactions, a transaction identifier associated with one or more log records of the transaction log that enable the particular active database transaction to be replayed (Schreter, e.g., [0003-0006], “...transaction log that includes a plurality of transactions performed at each of the plurality of data partitions may be generated at each of the plurality of data partitions. A second copy of a second transaction log that includes a second plurality of transactions performed at each of the one or more transaction coordinator partitions... the point-in-time recovery at each of the plurality of data partitions may be performed based at least on the first copy of the first transaction log...”) and see (Abouzour, e.g., [0074-0080], “... transaction commits, its RF/RB bitmaps are flushed to storage, the identities of the bitmaps are recorded in the transaction log...transaction manager maintains a chain of committed transactions with pointers to the associated RF/RB bitmaps and tracks the oldest transaction in the chain whose pages are still referenced by active transactions... the transaction log is replayed from the checkpointed state... the commit of T.sub.1 is replayed at clock 90, the active set is updated to W.sub.1: {131-200} because the committed range of object keys {101-130} no longer needs to be tracked...”).
As per as claim 3, the combination of Abouzour and Schreter disclose:
The method of claim 2, wherein the checkpoint information specifies a starting log position corresponding to an initial log record written to the transaction log for the particular active database transaction (Schreter, e.g., [005-0011], “... commit or rollback the one or more transactions... a transaction may be rolled back by at least setting a transaction control block of the transaction to an aborting state, writing a rollback log record for the transaction, performing one or more post-rollback operations, and upon writing the rollback log record and completing the one or more post-rollback operations...”).
As per as claim 4, the combination of Abouzour and Schreter disclose:
The method of claim 2, wherein the recovery start point corresponds to an initial log record written to the transaction log for the oldest one of the active database transactions (Schreter, e.g., [006-0011], “...the point-in-time recovery at each of the plurality of data partitions may be performed based at least on the first copy of the first transaction log...commit or rollback the one or more transactions... a transaction may be rolled back by at least setting a transaction control block of the transaction to an aborting state, writing a rollback log record for the transaction, performing one or more post-rollback operations, and upon writing the rollback log record and completing the one or more post-rollback operations...”).
As per as claim 5, the combination of Abouzour and Schreter disclose:
The method of claim 2, wherein the flush point corresponds to a position in the transaction log that is associated with the first flush operation (Abouzour, e.g., [0048-0049], “... flush a dirty page of a buffer pool to persistent storage...” and [0058-0059], [0062], “... flushed reflects a new table-level version...”, [0069], (...flushing the data structure disk...)).
As per as claim 6, the combination of Abouzour and Schreter disclose:
The method of claim 2, wherein the checkpoint information specifies the flush point and the recovery start point, wherein a recovery end point of the database recovery routine corresponds to an end of the transaction log (Abouzour, e.g., [0074-0080], “... transaction commits, its RF/RB bitmaps are flushed to storage, the identities of the bitmaps are recorded in the transaction log...transaction manager maintains a chain of committed transactions with pointers to the associated RF/RB bitmaps and tracks the oldest transaction in the chain whose pages are still referenced by active transactions... the transaction log is replayed from the checkpointed state... the commit of T.sub.1 is replayed at clock 90, the active set is updated to W.sub.1: {131-200} because the committed range of object keys {101-130} no longer needs to be tracked...”) and see (Schreter, e.g., [0003-0006], “...transaction log that includes a plurality of transactions performed at each of the plurality of data partitions may be generated at each of the plurality of data partitions. A second copy of a second transaction log that includes a second plurality of transactions performed at each of the one or more transaction coordinator partitions... the point-in-time recovery at each of the plurality of data partitions may be performed based at least on the first copy of the first transaction log...”).
Claim 9 contain essentially the same subject matter as claim 1 and therefore are rejected under the same rationale.
As per as claim 10, the combination of Abouzour and Schreter disclose:
The non-transitory computer-readable medium of claim 9, wherein the operations further comprise: writing log records for the plurality of database transactions to a transaction log, wherein the recovery start point corresponds to an initial log record written to the transaction log for the oldest one of the active database transactions (Schreter, e.g., [0003-0006], “...transaction log that includes a plurality of transactions performed at each of the plurality of data partitions may be generated at each of the plurality of data partitions. A second copy of a second transaction log that includes a second plurality of transactions performed at each of the one or more transaction coordinator partitions... the point-in-time recovery at each of the plurality of data partitions may be performed based at least on the first copy of the first transaction log...”) and see (Abouzour, e.g., [0074-0080], “... transaction commits, its RF/RB bitmaps are flushed to storage, the identities of the bitmaps are recorded in the transaction log...transaction manager maintains a chain of committed transactions with pointers to the associated RF/RB bitmaps and tracks the oldest transaction in the chain whose pages are still referenced by active transactions... the transaction log is replayed from the checkpointed state... the commit of T.sub.1 is replayed at clock 90, the active set is updated to W.sub.1: {131-200} because the committed range of object keys {101-130} no longer needs to be tracked...”).
As per as claim 12, the combination of Abouzour and Schreter disclose:
The non-transitory computer-readable medium of claim 9, wherein the checkpoint information specifies, for a given one of the active database transactions:
a transaction identifier of the given active database transaction that is associated with one or more log records of a transaction log (Schreter, e.g., [0003-0006], “...transaction log that includes a plurality of transactions performed at each of the plurality of data partitions may be generated at each of the plurality of data partitions. A second copy of a second transaction log that includes a second plurality of transactions performed at each of the one or more transaction coordinator partitions... the point-in-time recovery at each of the plurality of data partitions may be performed based at least on the first copy of the first transaction log...”); and
a starting log position corresponding to an initial log record written to the transaction log for the given active database transaction (Schreter, e.g., [0003-0006], “...transaction log that includes a plurality of transactions performed at each of the plurality of data partitions...transactions performed at each of the one or more transaction coordinator partitions... the point-in-time recovery at each of the plurality of data partitions may be performed based at least on the first copy of the first transaction log...”).
Claim 15 contain essentially the same subject matter as claim 1 and therefore are rejected under the same rationale.
As per as claim 16, the combination of Abouzour and Schreter disclose:
The system of claim 15, wherein the operations further comprise: writing log records for the plurality of database transactions to a transaction log, wherein the checkpoint information specifies the recovery start point, and wherein the recovery start point corresponds to an initial log record written to the transaction log for the oldest one of the active database transactions (Schreter, e.g., [0003-0006], “...transaction log that includes a plurality of transactions performed at each of the plurality of data partitions may be generated at each of the plurality of data partitions. A second copy of a second transaction log that includes a second plurality of transactions performed at each of the one or more transaction coordinator partitions... the point-in-time recovery at each of the plurality of data partitions may be performed based at least on the first copy of the first transaction log...”) and see (Abouzour, e.g., [0074-0080], “... transaction commits, its RF/RB bitmaps are flushed to storage, the identities of the bitmaps are recorded in the transaction log...transaction manager maintains a chain of committed transactions with pointers to the associated RF/RB bitmaps and tracks the oldest transaction in the chain whose pages are still referenced by active transactions... the transaction log is replayed from the checkpointed state... the commit of T.sub.1 is replayed at clock 90, the active set is updated to W.sub.1: {131-200} because the committed range of object keys {101-130} no longer needs to be tracked...”).
As per as claim 17, the combination of Abouzour and Schreter disclose:
The system of claim 16, wherein the checkpoint information specifies, for a given one of the active database transactions, a transaction identifier and a starting log position that corresponds to an initial log record written to the transaction log for that given active database transaction (Schreter, e.g., [0003-0006], “...transaction log that includes a plurality of transactions performed at each of the plurality of data partitions may be generated at each of the plurality of data partitions. A second copy of a second transaction log that includes a second plurality of transactions performed at each of the one or more transaction coordinator partitions... the point-in-time recovery at each of the plurality of data partitions may be performed based at least on the first copy of the first transaction log...”).
As per as claim 18, the combination of Abouzour and Schreter disclose:
The system of claim 16, wherein the checkpoint information specifies the flush point, and wherein the flush point corresponds to a log record of the transaction log that is associated with the first flush operation (Abouzour, e.g., [0074-0080], “... transaction commits, its RF/RB bitmaps are flushed to storage, the identities of the bitmaps are recorded in the transaction log...transaction manager maintains a chain of committed transactions with pointers to the associated RF/RB bitmaps and tracks the oldest transaction in the chain whose pages are still referenced by active transactions... the transaction log is replayed from the checkpointed state... the commit of T.sub.1 is replayed at clock 90, the active set is updated to W.sub.1: {131-200} because the committed range of object keys {101-130} no longer needs to be tracked...”).
Allowable Subject Matter
The prior art does not teach “performing, by the database system, a second flush operation to flush, from the in-memory cache to the persistent storage, records committed since the first flush operation; and updating, by the database system, the checkpoint information to remove ones of the active database transactions that committed since the first flush operation" (Claim 7), “performing, by the database system, the database recovery routine, wherein the performing of the database recovery routine includes: accessing the checkpoint information; replaying, based on the checkpoint information, the active database transactions but excluding any committed or aborted database transactions that occurred between the recovery start point and the flush point; and replaying, without excluding committed or aborted database transactions, database transactions occurring between the flush point and a recovery end point of the database recovery routine” (Claim 8), “committing the oldest active database transaction ; performing a second flush operation to flush, from the in-memory cache to the persistent storage, committed records of the oldest active database transaction; and updating the recovery start point to correspond to another active database transaction” (Claim 11), “performing a second flush operation to flush, from the in-memory cache to the persistent storage, records committed since the first flush operation; and updating the checkpoint information to remove ones of the active database transactions that committed since the first flush operation” (Claim 13), “performing the database recovery routine, wherein the performing of the database recovery routine includes: accessing the checkpoint information; and replaying, based on the checkpoint information, the active database transactions but excluding any committed or aborted database transactions that occurred between the recovery start point and the flush point” (claim 14), “checkpoint information specifies the flush point, and wherein the operations further comprise: committing the oldest active database transaction; performing a second flush operation to flush, from the in-memory cache to the persistent storage, additional committed records corresponding to a set of transactions that includes the oldest active database transaction; and updating the recovery start point to correspond to a next oldest active database transaction and the flush point to correspond to a log record of the transaction log that is associated with the second flush operation” (Claim 19), “performing the database recovery routine, wherein the performing of the database recovery routine includes: accessing the checkpoint information; and replaying, based on the checkpoint information, the active database transactions but excluding any committed or aborted database transactions that occurred between the recovery start point and the flush point” (Claim 20). Per the instant office action, claims 7-8, 11, 13-14, and 19-20 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Additional Art Considered
The prior art made of record and not relied upon is considered pertinent to the Applicants’ disclosure.
The following patents and papers are cited to further show the state of the art at the time of Applicants’ invention with respect to database recovery routine to start up a database system in response to a database failure which accesses checkpoint information identifying a set of active database transactions that were active at a flush point that occurred before the database failure, wherein the database recovery routine, the database system replays database transactions that occurred between a recovery point and the flush point. The database transactions include the set of active database transactions but exclude any committed or aborted database transactions that occurred between the recovery point and the flush point such that less than a total number of database transactions occurring between the recovery point and the flush point are replayed.
a. Lu et al. (US PGPUB 2022/0382651, herein after Lu); “Fast Recovery And Replication Of Key-Value Stores” discloses “ perform a restart recovery after a system failure and checkpoint, and load a page mapping table from the latest system checkpoint. The key-value engine may replay to apply changes to the page mapping table from a system transaction log starting from a system transaction replay starting point”.
Lu also teaches starting from check point and replaying transaction logs [0038], [0052], [0085].
Lu further teaches replays the system transaction log, newer log records for user checkpoints may also be encountered [0090-0093].
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TUAN A PHAM whose telephone number is (571)270-3173. The examiner can normally be reached M-F 7:45 AM - 6: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, Tony Mahmoudi can be reached on 571-272-4078. 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.
/TUAN A PHAM/Primary Examiner, Art Unit 2163