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
A request for continued examination under 37 CFR 1.114, including the fee set
forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this
application is eligible for continued examination under 37 CFR 1.114, and the fee set
forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action
has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 03/30/26
has been entered.
Response to Amendment
This action is in response to applicant's arguments and amendments filed on
03/30/26. which are in response to USPTO Office Action mailed on 12/31/25
Applicant's arguments and amendments have been considered with the results that
follow: THIS ACTION IS MADE NON-FINAL.
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 is rejected on the ground of nonstatutory double patenting as being
unpatentable over claims 1,5-9,11,15-19,21 and 25-29 of Patent No. 11, 593, 345. Although the conflicting claims are not identical, they are not patentably distinct from each other because over claims 1,5-9,11,15-19,21 and 25-29 of Patent No. 11, 593, 345 contains every element of claim 1-20 of the instant application no. 18/967,679 and as such anticipates claim 1-20 of the instant application No. 18/967,679.
Both claim features of the instant application No. 18/967,679 and Patent No.
11, 593, 345 can be compared as follows:
Instant Application 18/967,679
Patent No. 11, 593, 345
1. A system comprising: at least one hardware processor; and at least one memory storing instructions that, when executed by the at least one hardware processor, cause the at least one hardware processor to perform steps comprising: storing a table comprising a plurality of rows, organized into a plurality of partitions; identifying partitions involved in a time interval by retrieving one or more DML, the row bitsets marking rows previously modified by data manipulation (DML) operations performed on the table, and combining the one or more row bitsets for each partition using a position-wise OR operation to generate a selection vector for the respective partition; scanning a subset of rows of the plurality of partitions using the selection vector, wherein the selection vector identifies rows to be scanned based on the combined row bitsets
splitting the subset of rows into a first subset of rows that were indicated as being deleted or updated and a second subset of rows that were indicated as being inserted; setting one or more action attributes for the first subset of rows and the second subset of rows separately; and combining the first subset of rows and the second subset of rows with one or more set action attributes to generate change data capture information showing changes made to the table in the time interval.
1. (Currently Amended) A method comprising: performing one or more operations on a table including at least a first micro-partition; in response to performing the one or more operations, removing the first micro-partition and adding at least a second micro-partition; generating a plurality of row bitsets for the micro-partitions involved in the one or more operations, the row bitsets indicating rows modified by the one or more operations, wherein the plurality of row bitsets include one inserted row bitset for marking newly inserted and new versions of updated rows, one deleted row bitset for marking newly deleted rows, and one updated row bitset for marking previous versions of updated rows, wherein the deleted and updated row bitsets are generated in a scanback row set operator (RSO) during one or more update, delete, or merge operations, wherein the inserted row bitsets are generated in an insert RSO during one or more insert, update, merge, or copy operations; based on the plurality of row bitsets, scanning a subset of rows in the table, the subset of rows marked as being modified by the row bitsets; splitting the scanned subset of rows into a first subset and a second subset, the first subset including rows that were newly deleted or newly updated and the second subset including rows that were newly inserted; in a first branch, processing the first subset of rows; in a second branch, processing the second subset of rows; unioning results of processing the first and second branches to generate change data capture information showing changes made to the table in a specified time interval.
2. The system of claim 1, wherein the plurality of row bitsets are generated for a plurality of micro-partitions in the table involved in one or more operations, the plurality of row bitsets include including one inserted row bitset for marking newly inserted and new versions of updated rows, one deleted row bitset for marking newly deleted rows, one updated row bitset for marking previous versions of updated rows, the deleted and updated row bitsets being generated in a scanback row set operator (RSO) during one or more update, delete, or merge operations, and the inserted row bitsets being generated in an insert RSO during one or more insert, update, merge, or copy operations.
1. (Currently Amended) A method comprising: performing one or more operations on a table including at least a first micro-partition; in response to performing the one or more operations, removing the first micro-partition and adding at least a second micro-partition; generating a plurality of row bitsets for the micro-partitions involved in the one or more operations, the row bitsets indicating rows modified by the one or more operations, wherein the plurality of row bitsets include one inserted row bitset for marking newly inserted and new versions of updated rows, one deleted row bitset for marking newly deleted rows, and one updated row bitset for marking previous versions of updated rows, wherein the deleted and updated row bitsets are generated in a scanback row set operator (RSO) during one or more update, delete, or merge operations, wherein the inserted row bitsets are generated in an insert RSO during one or more insert, update, merge, or copy operations; based on the plurality of row bitsets, scanning a subset of rows in the table, the subset of rows marked as being modified by the row bitsets; splitting the scanned subset of rows into a first subset and a second subset, the first subset including rows that were newly deleted or newly updated and the second subset including rows that were newly inserted; in a first branch, processing the first subset of rows; in a second branch, processing the second subset of rows; unioning results of processing the first and second branches to generate change data capture information showing changes made to the table in a specified time interval.
3. The system of claim 1, the steps further comprising: based on the scanning, generating rows from the table with a plurality of metadata columns, wherein a first metadata column indicates an original partition name for the respective row, wherein a second metadata column indicates an original row number for the respective row.
5. (Original) The method of claim 1, further comprising: based on the scanning, generating rows from the table with a plurality of metadata columns, wherein a first metadata column indicates an original partition name for the respective row, wherein a second metadata column indicates an original row number for the respective row.
4. The system of claim 3, wherein a third metadata column includes a deleted flag indicating whether the respective row was deleted based on the plurality of row bitsets, wherein a fourth metadata column includes an updated flag indicating whether the respective row was updated based on the plurality of row bitsets, and wherein a fifth metadata column includes an inserted flag indicating whether the respective row was inserted based on the plurality of row bitsets.
6. (Original) The method of claim 5,
wherein a third metadata column includes a deleted flag indicating whether the respective row was deleted based on the plurality of row bitsets, wherein a fourth metadata column includes an updated flag indicating whether the respective row was updated based on the plurality of row bitsets, and wherein a fifth metadata column includes an inserted flag indicating whether the respective row was inserted based on the plurality of row bitsets.
5. The system of claim 4, wherein a first branch processes the first subset of rows that were deleted or updated based on the deleted and updated flags, and wherein a second branch processes the second subset of rows that were inserted based on the inserted flags.
7. (Previously Presented) The method of claim 6, wherein the first branch processes the first subset of rows that were deleted or updated based on the deleted and updated flags, and wherein the second branch processes the second subset of rows that were inserted based on the inserted flags.
6. The system of claim 5, the steps further comprising: in the first branch, setting an action attribute for each row in the first subset to delete and setting an update attribute for each row in the first subset based on the update flag.
8. (Original) The method of claim 7, further comprising: in the first branch, setting an action attribute for each row in the first subset to delete and setting an update attribute for each row in the first subset based on the update flag.
7. The system of claim 6, the steps further comprising: in the second branch, setting the action attribute for each row in the second subset to insert and setting the update attribute for each row in the second subset based on a value of the original partition name for the respective row.
9. (Original) The method of claim 8, further comprising: in the second branch, setting the action attribute for each row in the second subset to insert and setting the update attribute for each row in the second subset based on the value of the original partition name for the respective row.
Conclusions/Points of Contacts
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MULUEMEBET GURMU whose telephone number is (571)270-7095. The examiner can normally be reached M-F 9am - 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, Tony Mahmoudi can be reached at 5712724078. 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.
/MULUEMEBET GURMU/Primary Examiner, Art Unit 2163