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
Information Disclosure Statement
Applicants’ Information Disclosure Statement, filed 11/06/2025, has been received, entered into the record, and considered. See attached form PTO-1449.
Claim Rejections – 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
Claims 1, 12, 20 recite a system/method/medium, comprising: “receiving… an instruction to recover a database to a first version of the database corresponding to a first point in time; identifying … a synthetic snapshot corresponding to a second point in time that is different than the first point in time; acquiring … one or more transaction logs for the database that indicate a set of data changes to the database corresponding to a time period between the second point in time and the first point in time; and generating … the first version of the database by applying the set of data changes to the synthetic snapshot of the database”.
These limitations are processes that, under their broadest reasonable interpretation, covers performance of the limitation in the mind, but for the recitation of generic computer components. That is, other than reciting "a processor, a memory" (claim 12), “a non-transitory computer readable medium” (claim 20) nothing in the claim element precludes the step from practically being performed in a human mind or with the aid of pen and paper. For example, but for the "a processor, a memory" language, “receiving… an instruction to recover a database to a first version of the database…; identifying … a synthetic snapshot corresponding to a second point in time …; acquiring … one or more transaction logs for the database that indicate a set of data changes …; and generating … the first version of the database by applying the set of data changes to the synthetic snapshot of the database…” in the context of this claim encompasses steps that can be performed mentally, with the aid of pen and paper to analyze information, gathering data and organizing data based on evaluation.
If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind, then it falls within the “Mental Processes” grouping of abstract ideas (concepts performed in the human mind including an observation, evaluation, judgment, and opinion).
This judicial exception is not integrated into a practical application. In particular, the claims recite additional element – using "a processor, a memory" to “receiving… an instruction to recover a database to a first version of the database…; identifying … a synthetic snapshot corresponding to a second point in time …; acquiring … one or more transaction logs for the database that indicate a set of data changes…”, these limitations amount to data gathering which is considered to be insignificant extra solution activity (MPEP 2106.05(g).
“generating … the first version of the database by applying the set of data changes to the synthetic snapshot of the database…”; these limitation are mere generic transmissions and presentations of collected and analyzed data which is considered to be insignificant extra solution activity (MPEP 2106.05(g).
Claims 12, 20 merely recite a system, medium comprising a processor, a memory, a non-transitory computer readable medium performing steps of method claim 1.
The processor, the memory, the non-transitory computer readable medium are recited at a high-level of generality (i.e., as a generic processor performing a generic computer function of obtaining a data stream event …; incrementing a quota value …; and transmitting … the incremented quota value…) such that they amount no more than mere instructions to apply the exception using a generic computer component. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. (see MPEP 2106.05(f)). The claim is directed to an abstract idea.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when considered separately and in combination, they do not add significantly more to the exception. Considered separately and as an ordered combination, the claimed elements do not recite additional elements that: improve a computer itself; improve another technology or technical field; improve to the functioning of the computer itself.
The limitations “receiving… an instruction to recover a database to a first version of the database…; identifying … a synthetic snapshot corresponding to a second point in time …; acquiring … one or more transaction logs for the database that indicate a set of data changes …; and generating … the first version of the database by applying the set of data changes to the synthetic snapshot of the database…” amounts to no more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The claims are not patent eligible.
Dependent claims 2-11, 13-19 merely add further details of the abstract steps recited in claims 1, 12 without including an improvement to another technology or technical field, an improvement to the functioning of the abstract idea to a particular technology environment. Therefore, dependent claims 2-11, 13-19 are also directed to non-statutory subject matter.
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 of this title, 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 factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Claims 1, 2, 4, 5, 8-13, 15, 16, 19, 20 are rejected under 35 U.S.C. 103 as being unpatentable over Chakankar et al. (US Pub No. 2019/0065322), in view of Wade et al. (US Pub No. 2012/0290802).
As to claims 1, 12, 20, a method comprising (i.e. FIG. 7 is a block diagram illustrating an example of restoring a storage volume and/or a database to a particular point in time ... the number of database transactions and a plurality of backups with respect to a timeline ... The storage volume may be restored to any particular point in time as long as the storage system stores the necessary backups. For example, a storage volume may be restored to the state at t1 or t4 because the storage system stores full backup F1 and incremental backup I4. The database may be restored to any particular point in time as long as the storage system stores the necessary backups and one or more associated transaction log file segments. A backup includes a snapshot of a database at a particular moment in time ... A transaction log file segment stores the one or more modifications to a database (e.g., add node, copy node, delete node, modify node). Each modification is a transaction in the transaction log file, [0136]):
receiving, at a storage appliance, an instruction to recover a database to a first version of the database corresponding to a first point in time (i.e. The storage system may restore the database to the state of the database at any of the transactions between the 101st transaction and the 150th transaction using a combination of the full backup F1 and the transaction log file segment L2, [0139]; A system may go offline (e.g., the system has been infected with a virus, infected with malware, experienced a hardware failure, etc.). It may be desirable to restore the system to a particular point in time using a file system metadata snapshot tree corresponding to a backup instance of the entire storage volume, [0037]; Secondary storage system 112 may protect a large volume of applications while supporting tight business requirements (recovery time objective (RTO) and recovery point objective (RPO)). Secondary storage system 112 may unify end-to-end protection infrastructure—including target storage, provide backup, replication of data, disaster recovery, and/or cloud tiering, [0064]);
identifying, at the storage appliance, a synthetic snapshot corresponding to a second point in time that is different than the first point in time (i.e. The closest backup instance captured before the desired restore point is identified. The closest backup instance (e.g., a copy of the backup instance) is modified using a database transaction log by applying the database transaction(s) that occur in between the creation of the backup instance and the desired restore point to generate modified backup data that can be used to restore the database to the desired restore point, [0038]; The storage system may restore the database to the state of the database at any of the transactions between the 251st transaction and the 300th transaction using a combination of the incremental backup I4 and the transaction log file segment L5 ... a corresponding modification may be made to the file snapshot tree corresponding to the database to reflect the database at the particular transaction, [0143]);
acquiring, at the storage appliance, one or more transaction logs for the database that indicate a set of data changes to the database corresponding to a time period between the second point in time and the first point in time (i.e. Primary storage system 102 may be configured to send a transaction log file segment to another storage system, such as secondary storage system 112 ... A backup (full or incremental) includes the data associated with a database at a particular moment in time ... a first backup of a database may correspond to the database at the 100th transaction. A second backup of the database may correspond to the database at the 200th transaction. A transaction log file segment may be associated with transactions 50-200 of the database. A request may be received to restore the database to any transaction between the 100th transaction and the 200th transaction, [0046]); and
generating, by the storage appliance, the first version of the database by applying the set of data changes to the synthetic snapshot of the database (i.e. to restore a database to a particular moment in time represented by star 702 ... subsequently apply the modifications stored in transaction log files segments L2, L3, L5 to restore the database to the specified moment in time represented by star 702, [0144]; Secondary storage system 112 may be configured to restore a database to a particular point in time in between backups. A system may go offline (e.g., the system has been infected with a virus, infected with malware, experienced a hardware failure, etc.) It may be desirable to restore the system and its associated database to a particular point in time ... a first backup may represent the state of a database after the nth transaction. A second backup may represent the state of the database after the n+100 transaction. The database may be restored to any transaction between transactions n and n+100 as long as the transaction log file segment includes a record of transactions n to n+100, [0059]).
Although Chakankar implicitly teaches the term "synthetic" (synthetic snapshot) (i.e. A file system metadata snapshot tree corresponding to the backup may be created. Metadata associated with the database may indicate the file system metadata snapshot tree corresponding to the version of the database to be restored, [0059]; , the database may be restored to the particular moment in time represented by star 702 by applying the corresponding modifications corresponding to the transactions stored in transaction log file segment L5 to the file snapshot tree corresponding to the incremental backup at transaction 250, [0144]), Chakankar does not clearly state this term.
Wade teaches this term (i.e. Processing system 430 executes software 450 to create a synthetic snapshot from a changed block list, [0051]; In the event of a system failure, data management system 400 could then merge the snapshot of the base state of virtual disk file 415 and the synthetic snapshot of the changed block list from block bitmap 425 to restore a recent state of the virtual disk file 415, which would include the file saved by the user on virtual storage volume 431, [0056]; changes to the secondary storage volume 140 may be tracked and captured. As changes are made to the data items in the secondary storage volume 140, corresponding changes are made to the primary storage volume 130. Any method may be used to generate a snapshot from the changes made to the data, such as by converting changed block lists into snapshots. In some examples, the changed block list from which the snapshot is created may itself be generated according to the method described above with respect to FIG. 2. Other methods of obtaining changed block lists from which to create snapshots may also be utilized, [0049]).
It would have been obvious to one of ordinary skill of the art having the teaching of Chakankar, Wade before the effective filing date of the claimed invention to modify the system of Chakankar to include the limitations as taught by Wade. One of ordinary skill in the art would be motivated to make this combination in order to create a synthetic snapshot from a changed block list in view of Wade ([0051]), as doing so would give the added benefit of restoring a recent state of the virtual disk file, as taught by Wade ([0056]).
As to claims 2, 13, Chakankar teaches:
performing one or more read operations, or one or more write operations, or both, for the first version of the database based at least in part on generating the first version of the database (i.e. the database may be restored to a particular point in time that does not exactly align to when a backup was created. The closest backup instance captured before the desired restore point is identified. The closest backup instance (e.g., a copy of the backup instance) is modified using a database transaction log by applying the database transaction(s) that occur in between the creation of the backup instance and the desired restore point to generate modified backup data that can be used to restore the database to the desired restore point, [0038]).
As to claims 4, 15, Chakankar teaches:
transferring one or more files associated with the first version of the database, wherein the one or more files are transferred to a server executing the database or to an external application (i.e. A request may be received to restore the database to any transaction between the 100th transaction and the 200th transaction ... a transaction log file policy indicates that the transaction log file is to be sent on a periodic basis (e.g., hourly, daily, weekly, monthly, etc.), [0046]; a backup policy indicates ... a periodic basis (e.g., hourly, daily, weekly, monthly, etc.) ... are to be backed up when a threshold size of data has changed, [0044]).
As to claims 5, 16, Chakankar teaches the one or more files are transferred using a server message block (SMB) protocol or a network file system (NFS) protocol (i.e. File system manager 117 is configured to maintain file system metadata in a file system metadata snapshot tree structure and database file data in a corresponding database file snapshot tree, [0050]; Secondary storage system 112 is comprised of a plurality of N nodes 111, 113, 115, [0099]).
As to claims 8, 19, Chakankar teaches the synthetic snapshot is generated in accordance with a first frequency for generating synthetic snapshots of the database, wherein the first frequency is greater than a second frequency for acquiring snapshots of the database from a server executing the database (i.e. the transaction log file is to be sent on a periodic basis (e.g., hourly, daily, weekly, monthly, etc.) ... the transaction log file segment is to be sent after a certain number of transactions (e.g., 50 transactions, 100 transactions, etc.), [0046]; a backup policy indicates ... a periodic basis (e.g., hourly, daily, weekly, monthly, etc.) ... are to be backed up when a threshold size of data has changed, [0044]).
As per claim 9, Chakankar teaches the synthetic snapshot is generated based at least in part on detecting that a quantity of updates to the database between a third point in time and the second point in time has exceeded a threshold quantity of updates (i.e. FIG. 7 is a block diagram illustrating an example of restoring a storage volume and/or a database to a particular point in time, [0136]; In the example shown, time t1 corresponds to the 100th transaction of the database. At time t1, a full backup F1 of the database is stored to the storage system, [0137]; Time t2 corresponds to the 150th transaction of the database. At time t2, a transaction log file segment L2 is stored to the storage system, [0139]; Time t3 corresponds to the 200th transaction of the database. At time t3, a transaction log file segment L3 is stored to the storage system. Transaction log file segment L3 includes a record of transactions 151-200, [0140]; Time t4 corresponds to the 250th transaction of the database. At time t4, an incremental backup I4 of the database is stored to the storage system. The incremental backup I4 represents the state of the database after 250 transactions. The storage system may restore the database to the state of the database at the 250th transaction using only the incremental backup I4, [0141]).
As per claim 10, Chakankar teaches the second point in time corresponding to the synthetic snapshot is closer to the first point in time than a third point in time corresponding to a first snapshot (i.e. FIG. 7 is a block diagram illustrating an example of restoring a storage volume and/or a database to a particular point in time, [0136]; In the example shown, time t1 corresponds to the 100th transaction of the database. At time t1, a full backup F1 of the database is stored to the storage system, [0137]; Time t2 corresponds to the 150th transaction of the database. At time t2, a transaction log file segment L2 is stored to the storage system, [0139]; Time t3 corresponds to the 200th transaction of the database. At time t3, a transaction log file segment L3 is stored to the storage system. Transaction log file segment L3 includes a record of transactions 151-200, [0140]; Time t4 corresponds to the 250th transaction of the database. At time t4, an incremental backup I4 of the database is stored to the storage system. The incremental backup I4 represents the state of the database after 250 transactions. The storage system may restore the database to the state of the database at the 250th transaction using only the incremental backup I4, [0141]).
As per claim 11, Chakankar teaches the synthetic snapshot comprises a snapshot that is generated, by the storage appliance and using a database engine, by applying a second set of data changes to a first snapshot of the database, the second set of data changes between a third point in time and the second point in time, the third point in time corresponding to the first snapshot and the second point in time subsequent to the third point in time, and the set of data changes indicated by a plurality of database transaction logs (i.e. FIG. 7 is a block diagram illustrating an example of restoring a storage volume and/or a database to a particular point in time, [0136]; In the example shown, time t1 corresponds to the 100th transaction of the database. At time t1, a full backup F1 of the database is stored to the storage system, [0137]; Time t2 corresponds to the 150th transaction of the database. At time t2, a transaction log file segment L2 is stored to the storage system, [0139]; Time t3 corresponds to the 200th transaction of the database. At time t3, a transaction log file segment L3 is stored to the storage system. Transaction log file segment L3 includes a record of transactions 151-200, [0140]; Time t4 corresponds to the 250th transaction of the database. At time t4, an incremental backup I4 of the database is stored to the storage system. The incremental backup I4 represents the state of the database after 250 transactions. The storage system may restore the database to the state of the database at the 250th transaction using only the incremental backup I4, [0141]).
Claims 3, 6, 7, 14, 17, 18 are rejected under 35 U.S.C. 103 as being unpatentable over Chakankar et al. (US Pub No. 2019/0065322), in view of Wade et al. (US Pub No. 2012/0290802), as applied to claims above, and further in view of GRIFFITH et al. (US Pub No. 201/50019909).
As to claims 3, 14, Chakankar teaches the storage appliance performs the one or more read operations or the one or more write operations during a time window and for an application of a server executing the database (i.e. A system may go offline (e.g., the system has been infected with a virus, infected with malware, experienced a hardware failure, etc.). It may be desirable to restore the system to a particular point in time using a file system metadata snapshot tree corresponding to a backup instance of the entire storage volume, [0037]).
Although Chakankar do not expressly teach the term time window, GRIFFITH teaches this term (i.e. If a primary database node fails to send a heartbeat within a designated time-window, a takeover node may conclude that the primary node has become inactive and begin a database recovery operation, [0026]; can select as the waiting time, any length of time from the grace period up to the time to apply all the log entries to snapshot tables 420, [0097]).
It would have been obvious to one of ordinary skill of the art having the teaching of Chakankar, Wade, GRIFFITH before the effective filing date of the claimed invention to modify the system of Chakankar, Wade to include the limitations as taught by GRIFFITH. One of ordinary skill in the art would be motivated to make this combination in order to use the waiting time window to make the determination whether to halt the affected node later than the grace period, in view of GRIFFITH ([0098]), as doing so would give the added benefit of ending the concurrency of for example Node-A and Node-B, and allowing Node-A to resume the primary role in the cluster, as taught by GRIFFITH ([0108]).
As to claims 6, 17, Chakankar, Wade do not seem to specifically teach the following limitations, but GRIFFITH teaches:
determining, by the storage appliance, that the synthetic snapshot of the
database is to be generated based at least in part on detecting that a server executing the database is unable to provide a first snapshot of the database to the storage appliance within a threshold time interval (i.e. a method, system, and computer program product for speculative recovery using storage snapshot in a clustered database; detects a failure in a first computing node, the first computing node serving the database in a cluster of computing nodes, [0007]);
instantiating, by the storage appliance, a database engine to generate the synthetic snapshot of the database (i.e. creates, using a processor and a memory, a snapshot of data of the database; applies, using the processor and the memory, a subset of log entries to the snapshot, the applying modifying the snapshot to result in a modified snapshot; preserves an access of the first computing node to the data of the database; aborts, responsive to receiving a signal of activity from the first computing node during the applying and after a grace period has elapsed, the applying such that the first computing node can continue serving the database in the cluster, [0007]);
generating, by the storage appliance, the synthetic snapshot of the database using the database engine by applying a second set of data changes to a second snapshot of the database corresponding to a third point in time that is different than the first point in time and the second point in time, the second set of data changes being to the database and corresponding to a time period between the third point in time and the second point in time (i.e. According to one embodiment, other actions for the takeover of the database after a permanent failure are as follows—after having finished the log replay on snapshot tables 420, Node-B disrupts disk access for Node-A, such as by setting reserves on storage 416. An embodiment recognizes that database instance 404 might have still been operational on Node-A and may have added further entries to the transaction log after snapshot datastore 430 was created. The two images of the database, sparsely populated log-applied snapshot 420 and data 414 as modified by database instance 404 during Node-B's log replay, are rejoined. The rejoining preserves the changes made by Node-B during the log replay as well as any transaction records Node-A might have added to data 414 after the creation of snapshot 420. Node-B replays, such as via a function of takeover application 456, these still uncommitted records from the log replay. Node-B acquires remaining resources from Node-A for database operation, and bring the database to an operational state, ready to process requests, [0095]; In view 602 of log 600, in the midst of Node-A writing a transaction record starting at LSN 10025, snapshot tables 420 in FIG. 4 is created as the beginning of a takeover event and contains the log up to LSN 10025. Log replay operation on snapshot tables 420 commits records up to LSN 10020 and discard LSN 10025 because LSN 10025 belongs to an incomplete transaction on snapshot tables 420, [0116]).
It would have been obvious to one of ordinary skill of the art having the teaching of Chakankar, Wade, GRIFFITH before the effective filing date of the claimed invention to modify the system of Chakankar, Wade to include the limitations as taught by GRIFFITH. One of ordinary skill in the art would be motivated to make this combination in order to detect a failure in a first computing node, applying a subset of log entries to the snapshot, modify the snapshot to result in a modified snapshot in view of GRIFFITH ([0007]), as doing so would give the added benefit that responsive to receiving a signal of activity from the first computing node during the applying and after a grace period has elapsed, the applying such that the first computing node can continue serving the database in the cluster, as taught by GRIFFITH ([0007]).
As to claims 7, 18, GRIFFITH teaches:
terminating, by the storage appliance, the database engine after generating the synthetic snapshot using the database engine (i.e. In case the failure is permanent, e.g., when Node-A fails to transmit heartbeats after the waiting period as well, takeover application 456 performs further takeover actions for the database after the records present in log 418 are applied to snapshot tables 420 in snapshot datastore 430. One such further action applies the changes in snapshot datastore 430 to datastore 410, [0093]; Thus, at the expense of some extra disk space and a slight I/O performance impact while snapshot 420 is being used, an embodiment achieves an elastic time window, with the length of the window being anywhere between the grace period and the time to complete the log replay, for the decision on the right recovery action, i.e., whether to leave database instance 404 active on Node-A or instead activate database instance 454 on Node-B, [0096]).
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 §§ 706.02(l)(1) - 706.02(l)(3) 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 obviousness-type double patenting as being unpatentable over claims 1-16 of US Patent No. 12/411,866 B2 and claims 1-17 of US Patent No. 11/561,999 B2. Claims 1-16 of US Patent No. 12/411,866 B2 and claims 1-17 of US Patent No. 11/561,999 B2 contain every element of claims 1-20 of the instant application and as such anticipate claims 1-20 of the instant application.
“A later patent claim is not patentably distinct from an earlier patent claim if the later claim is obvious over, or anticipated by, the earlier claim. In re Longi, 759 F.2d at 896, 225 USPQ at 651 (affirming a holding of obviousness-type double patenting because the claims at issue were obvious over claims in four prior art patents); In re Berg, 140 F.3d at 1437, 46 USPQ2d at 1233 (Fed. Cir. 1998) (affirming a holding of obviousness-type double patenting where a patent application claim to a genus is anticipated by a patent claim to a species within that genus). “ ELI LILLY AND COMPANY v BARR LABORATORIES, INC., United States Court of Appeals for the Federal Circuit, ON PETITION FOR REHEARING EN BANC (DECIDED: May 30, 2001).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Koza et al. (US Pub. 2014/0279907) – discloses processing the database log records of the database transaction log; generating a snapshot of the database log records at first periodic intervals, wherein each snapshot includes database log records for pending transactions; and in response to an interruption in processing of the database log records, utilizing a snapshot to restore database log records for the pending transactions and resuming processing of the database transaction log from a position succeeding the database log records of the selected snapshot.
Park et al. (US Pub. 2017/0116089) discloses processing events of an event stream and performing recovery of events during system failure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MIRANDA LE whose telephone number is (571)272-4112. The examiner can normally be reached M-F 7AM-5PM.
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 on 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.
/MIRANDA LE/ Primary Examiner, Art Unit 2153
Prosecution Insights