DETAILED ACTION
This action is responsive to Request for Continued Examination filed on March 20, 2026.
The amendments filed on February 13, 2026 have been acknowledged and considered.
Claims 1 and 17 have been amended.
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 .
Continued Examination Under 37 CFR 1.114
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 March 20, 2026 has been entered.
Response to Amendment
Applicant's Remarks, filed February 13, 2026, has been fully considered and entered.
Accordingly, Claims 1-20 are pending in this application. Claims 1 and 17 have been amended. Claims 1 and 17 are independent claim. In light of Applicant amendments, the objection to the Specification because of informalities has been withdrawn.
Response to Arguments
Applicant’s arguments, see pages 6-12, filed February 13, 2026, with respect to the rejection of claims 1-20, have been fully considered, but they are not persuasive.
Argument 1: Applicant argues on page 9 of Applicant Arguments and Remarks " Fish does not teach or suggest, "a first machine manages the first database," "a second machine manages the second database," "the first machine executes a first agent," "the second machine executes a second agent,”… as recited in claim 1, as amended."
Response to Argument 1: Examiner respectfully disagrees. Fish paragraphs [0011-0013, 0054, 0056] still teaches the amended claim limitations by using a first computer 104 that includes a first database 118, and a second computer 106 that includes a second database 138, where each computer have a Host Service (HS) process (e.g. first/second agents) used to retrieve table data for each table to be compared. See rejection below.
Therefore, the Examiner has determined that this argument is not persuasive.
Argument 2: Applicant argues on page 12 of Applicant Arguments and Remarks "Bourbonnais does not teach "causing the first agent to fetch a first set of rows by" "inserting the first batch of rows into a temporary table in the first database," "performing, by the first agent, a join operation between the temporary table in the first database and the particular table of the first database to form the first set of rows," and "returning, by the first agent, the plurality of columns of the first set of rows to the server," as recited in claim 1… Bourbonnais also does not teach or suggest the second comparison is based on a value-by-value comparison of the plurality of columns.”
Response to Argument 2: Examiner respectfully disagrees. Fish-Bourbonnais teaches the argued limitations. Fish paragraphs [0022, 0090, 0263] teaches a process [e.g. first agent] in turn writes [Thus, insert] the bad batch record [e.g. first batch of rows] into the Maybe Out of Sync queue (MOOSQ) [i.e. table]. Where this table holds the boundaries for batches that are out of sync
Fish, does not explicitly disclose the use of a temporary table.
However, Bourbonnais paragraphs [0029, 0034] teaches inserting the first batch of rows into a temporary table at the first database in more details by using table comparison utility that compares tables in three sequential stages including a preprocessing stage [e.g. initial comparison], a differencing stage, and a cleanup stage. Where in the pre-processing stage it creates non-logged, global temporary tables [i.e. temporary table] at the respective databases [e.g. at the first database] storing temporary records [Thus, inserting the first batch of rows into a temporary table] of row-based key values and checksums [e.g. batch of rows], which are subsequently used for a row-by-row comparison when partition-based checksums do not match instance”)
Fish writes batch records which may be out of sync into a “maybe out of sync” table based on a row comparison, Bourbonnais writes the of row-based key values and checksums on into a non-logged global temporary table at the respective database storing records based on an initial row comparison.
Therefore, a person having ordinary skills in the art would have found it obvious to substitute
Fish’s maybe out of sync table with Bourbonnais’s non-logged global temporary table at the respective database, as both represent known and interchangeable techniques for writing/accessing required data, yielding predictable results and improving performance by reducing logging overhead.
Fish further in view of Bourbonnais [Fish paragraphs 0226-0227, 0263] additionally disclose performing, by the first agent, a join operation between the temporary table in the first database and the particular table of the first database to form the first set of rows, and return the plurality of columns of the first set of rows to the server, by executing a second step, based on the MOOSQ table that holds the boundaries for batches that are out of sync to determine the exact row set [e.g. first set of rows] that is out of sync, where the process requests the underlying row detail (each row's columns) [e.g. the plurality of columns of the first set of rows] from both the source (HS1) and the target (HS2) each HS process formulates a query [e.g. performing an operation] to return [Thus, returning] each row [Thus, to form a first set of rows] that is in the range of the bad batch record.
Fish does not explicitly disclose the use of a join between the temporary table in the first database and the particular table.
However, Bourbonnais paragraphs [0035-0038] teaches performing, by the first agent, a join operation between the temporary table in the first database and the particular table of the first database to form the first set of rows by selecting the boundary key values for each partition from the source table to generate query statements to fetch specific partitions from the source and the target tables, where a merger thread [e.g. first agent] assigns the corresponding query statement that describes the respective partition, fetching from the global temporary table [i.e. temporary table], and initiate a merge-compare sub-stage and performs a merge join on the key values [Thus, perform a join operation between the temporary table and the particular table in the first database to form the first set of rows].
Thus, a person having ordinary skills in the art would have found it obvious to substitute or supplement Fish’s queries with Bourbonnais merge join query, as both represent known and interchangeable techniques for accessing required data, yielding predictable results and effectively reducing data transfer overhead, as the database returns a final joined result.
Further, Fish-Bourbonnais (Bourbonnais [0048], Claim 9) teach performing the second comparison based on a value-by-value comparison of the plurality of columns, by determining difference types based on comparing non-key values of the first and second sets of differences [Thus, based on a value-by-value comparison of the plurality of columns], wherein the first set of differences is generated via a first comparison operation comparing a set of rows between the source and target tables, wherein the second set of differences is generated via a second comparison [Thus performing a second comparison] operation restricted to comparing a subset of rows [e.g. a second set of rows corresponding to the second batch of rows] between the source and target tables, to which the first set of differences [Thus, of the first set of rows] pertains. See rejection below.
Therefore, the Examiner has determined that this argument is not persuasive.
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 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.
Claims 1-3, 7-14, 16-17 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Fish (US Patent Application Publication No. US 20060212465 A1), in view of Bourbonnais (US Patent Application Publication No. US 20140372374 A1).
Regarding claim 1, Fish teaches a method comprising: a server performing an initial comparison of rows in a particular table of a first database and rows in a corresponding table of a second database, (See Fish [0054-0062] “One aspect of the invention is to compare tables using a row hash technique. Consider the situation where the table data to be compared resides in database 1 (DB1) and database 2 (DB2). A Compare Client (CC) process (e.g., implemented as the conditional synchronization check module 158) establishes connectivity to two Host Server (HS) processes (e.g., on computers 104 and 106), one for each table to compare. One Host Server process is used to retrieve table data for each table to be compared… Each row retrieved consists of one or more columns of data (as defined by the database… Rows are sorted in unique key order from both DB1 and DB2. The row comparison thread within the CC then compares rows from table 1 with rows in table 2. Table 1 is designated as the “source table” (ST) and table 2 is designated the “target table” (TT). [Thus, performing an initial comparison of rows in a particular table of a first database and rows in a corresponding table of a second database]”)
wherein the particular table comprises a plurality of columns, a first machine manages the first database, a second machine manages the second database, the first machine executes a first agent, the second machine executes a second agent, the initial comparison is based on a row hash comparison, and (See Fish [0011-0013] “FIG. 1 illustrates a computer network 100 configured in accordance with an embodiment of the invention. The network 100 includes a first computer 102, a second computer 104, and a third computer 106… Computer 104 [e.g. first machine] includes… a first database (DB1) 118 [e.g. manages the first database]… Computer 106 [e.g. second machine] also includes… a second database (DB2) 138 [e.g. manages the second database].” See also Fish [0054, 0056] “One aspect of the invention is to compare tables using a row hash technique [e.g. initial comparison based on a row hash comparison]. Consider the situation where the table data to be compared resides in database 1 (DB1) and database 2 (DB2). A Compare Client (CC) process (e.g., implemented as the conditional synchronization check module 158) establishes connectivity to two Host Server (HS) processes [e.g. first/second agents] (e.g., on computers 104 and 106 [e.g. the first machine executes a first agent, the second machine executes a second agent]), one for each table to compare… Each HS process then retrieves each row from its corresponding table [e.g. the particular table], sorted in unique key order. Each row retrieved consists of one or more columns of data [Thus, the particular table comprises a plurality of columns]”)
performing the initial comparison generates a first batch of rows that are flagged as being out of sync to be fetched from the first database and a second batch of rows that are flagged as being out of sync to be fetched from the second database; (See Fish [0062-0063] “ The row comparison thread within the CC then compares rows from table 1 with rows in table 2. Table 1 is designated as the “source table” (ST) and table 2 is designated the “target table” (TT). The comparison proceeds as follows: out-of-sync rows are accumulated, in order, to a “maybe out of sync queue” (MOOSQ)” [Thus, generates a first batch of rows that are flagged as being out of sync to be fetched from the first database and a second batch of rows that are flagged as being out of sync to be fetched from the second database] See also Fish [0190-0197] “tables are compared using a batch hash technique. In one embodiment, the batch hash technique is broken into two phases for descriptive purposes (although they may be run simultaneously):
1. Bad Batch Determination
2. Row Detail Fetch and Compare
Once these phases are completed, a MOOSQ holds the “maybe out of sync” row set (as with the Row Hash technique)… Bad Batch Determination may be implemented as follows. As with the Row Hash technique, Host Server processes retrieve rows from the source and target tables. The column data for each row is standardized after selection to allow for heterogeneous cases… specific row and column subsets can be selected from each table… row retrieval from source and target tables will occur in parallel in HS1 (e.g., DB1 118) and HS2 (e.g., DB2 138) Using the retrieved rows, HS1 subsequently builds and sends batches of row information to HS2” See also Fish [0223-0224] “ The MOOSQ holds the boundaries for batches [e.g. first, second batches of rows] that are out of sync. This means that at least one row per batch was out of sync, and perhaps more. At this point, a second step occurs to determine the exact row set that is out of sync. This step is known as “row detail fetch” [Thus, flagged as being out of sync to be fetched from the databases (e.g. first, second database)])
the server causing the first agent to fetch a first set of rows by: inserting the first batch of rows into a temporary table in the first database; (See Fish [0263] “The CC process [e.g. first agent] in turn writes [Thus, insert] the bad batch record [e.g. first batch of rows] into the Maybe Out of Sync queue (MOOSQ). [i.e. table] The MOOSQ holds the boundaries for batches that are out of sync” See also Fish [0090] “MOOSQ Contents after Comparison” See also Fish [0055] “The HS processes and CC process may be located anywhere in a network (including on the same systems as each other, some on the same system, or all on different systems). It is also possible that the CC and HS components on one of the systems run in the same process [e.g. first agent].”)
PNG
media_image1.png
196
562
media_image1.png
Greyscale
Fish, does not explicitly disclose the use of a temporary table.
However, Bourbonnais teaches inserting the first batch of rows into a temporary table at the first database in more details. (See Bourbonnais [0029] “the replication environment is an active-active replication environment, in which changes to any of the source table and the target table are synchronized to the other table. Synchronization between the source and target tables in an active-active replication environment may be maintained by an asynchronous replication process… the techniques disclosed herein provide an application configured to verify data consistency between source and target tables for which synchronization is maintained via a replication process. In a particular embodiment, the application is a table comparison utility” See also Bourbonnais [0034] “ The table comparison utility, also referred to as a comparison utility, is a parallel utility that compares tables in three sequential stages including a preprocessing stage [e.g. initial comparison], a differencing stage, and a cleanup stage. In the pre-processing stage… The parallel utility then creates non-logged, global temporary tables at the respective databases [e.g. at the first database] storing the source and target tables. The global temporary tables store temporary records [Thus, inserting the first batch of rows into a temporary table] of row-based key values and checksums [e.g. batch of rows], which are subsequently used for a row-by-row comparison when partition-based checksums do not match instance”)
Fish writes batch records which may be out of sync into a “maybe out of sync” table based on a row comparison, Bourbonnais writes the of row-based key values and checksums on into a non-logged global temporary table at the respective database storing records based on an initial row comparison.
Therefore, a person having ordinary skills in the art would have found it obvious to substitute
Fish’s maybe out of sync table with Bourbonnais’s non-logged global temporary table at the respective database, as both represent known and interchangeable techniques for writing/accessing required data, yielding predictable results and improving performance by reducing logging overhead.
Fish further in view of Bourbonnais, [hereinafter Fish-Bourbonnais] additionally disclose performing, by the first agent, a join operation between the temporary table in the first database and the particular table of the first database to form the first set of rows; and (See Fish [0263, 0226-0227] “The CC process [e.g. first agent] in turn writes the bad batch record into the Maybe Out of Sync queue (MOOSQ) [e.g. the temporary table]. The MOOSQ holds the boundaries for batches that are out of sync… At this point, a second step occurs to determine the exact row set [e.g. first set of rows] that is out of sync. This step is known as “row detail fetch”… the CC requests the underlying row detail (each row's columns) from both the source (HS1) and the target (HS2) each HS process formulates a query [e.g. performing an operation] to return each row [Thus, to form a first set of rows] that is in the range of the bad batch record [Thus, between the particular table of the first database and the temporary table]” See also Fish [0055] "It is also possible that the CC and HS components on one of the systems run in the same process [e.g. first agent]" )
Fish does not explicitly disclose the use of a join between the temporary table in the first database and the particular table.
However, Bourbonnais teaches performing, by the first agent, a join operation between the temporary table in the first database and the particular table of the first database to form the first set of rows; and (See Bourbonnais [0035-0038] “The comparison utility in the differencing stage includes a pool of cooperative threads including a main thread 204, a partitioner thread 206, merger threads 210 1-n and worker threads… the partitioner thread 206 selects the boundary key values for each partition from the source table 104… where the source table 104 is stored in a source database 202… uses the boundary key values to generate query statements to fetch specific partitions from the source and the target tables… each merger thread 210 [e.g. first agent] creates two worker threads 302 1-2, including a worker thread that interacts with the source database [e.g. first database] exclusively and a worker thread that interacts with the target database exclusively. For each partition, the merger thread 210 assigns the corresponding query statement that describes the respective partition… for fetching from the global temporary table [i.e. temporary table]. After earning the permit, the merger thread 210 sends a merge request to the worker threads 302 to initiate a merge-compare sub-stage… The merger thread 210 then performs [Thus, performing by the first agent] a merge join on the key values [Thus, perform a join operation between the temporary table and the particular table in the first database to form the first set of rows]” See also Bourbonnais [0048] “the merger threads can be regarded as agents 402 1-n [e.g. first, second agents] configured to determine differences between the source and target tables.”)
A person having ordinary skills in the art would have found it obvious to substitute or supplement Fish’s queries with Bourbonnais merge join query, as both represent known and interchangeable techniques for accessing required data, yielding predictable results and effectively reducing data transfer overhead, as the database returns a final joined result.
Fish-Bourbonnais further teach returning, by the first agent, the plurality of columns of the first set of rows to the server; (See Fish [0263, 0226-0227] “The CC process [e.g. first agent] in turn writes the bad batch record into the Maybe Out of Sync queue (MOOSQ) [e.g. the temporary table]. The MOOSQ holds the boundaries for batches that are out of sync… At this point, a second step occurs to determine the exact row set [e.g. first set of rows] that is out of sync. This step is known as “row detail fetch”… the CC requests the underlying row detail (each row's columns) [e.g. the plurality of columns of the first set of rows] from both the source (HS1) and the target (HS2) each HS process formulates a query to return [Thus, returning] each row [Thus, the plurality of columns of the first set of rows] that is in the range of the bad batch record [Thus, between the particular table of the first database and the temporary table]” See also Fish [0055] "It is also possible that the CC and HS components on one of the systems run in the same process [e.g. first agent]" See also Fish [0258-0260] “In the row detail fetch step, each bad batch record is retrieved from the BBQ by the CC. The CC retrieves the row detail for the implied row set bounded by begin and end key values, from each of HS1 and HS2. Once rows have been retrieved, they are compared in the order retrieved.”
PNG
media_image2.png
402
601
media_image2.png
Greyscale
[Thus, returning the plurality of columns of the first set of rows] The MOOSQ at this point contains the rows [e.g. first set of rows] that maybe out of sync.”)
the server performing a second comparison of the first set of rows received from the first agent and a second set of rows corresponding to the second batch of rows received from the second agent, wherein the second comparison is based on a value-by-value comparison of the plurality of columns, wherein the method is performed by one or more computing devices. (See Bourbonnais [0048] “the merger threads can be regarded as agents 402 1-n [e.g. first, second agents] configured to determine differences [e.g. first, second comparisons] between the source and target tables. The determined differences are inserted as difference entries into a difference queue, whereafter the difference reporter thread processes the difference entries and records results in a difference table accordingly.” See also Bourbonnais claim 9 “difference types are determined based on comparing non-key values of the first and second sets of differences [Thus, based on a value-by-value comparison of the plurality of columns], wherein the first set of differences is generated via a first comparison operation comparing a set of rows between the source [e.g. from the first agent] and target tables [e.g. from the second agent], wherein the second set of differences is generated via a second comparison [Thus performing a second comparison] operation restricted to comparing a subset of rows [e.g. a second set of rows corresponding to the second batch of rows] between the source and target tables, to which the first set of differences [Thus, of the first set of rows] pertains”)
Regarding claim 2, Fish-Bourbonnais teaches all limitations and motivations of claim 1, wherein performing the initial comparison comprises a row hash comparison. (See Fish [0054] “One aspect of the invention is to compare tables using a row hash technique.” See also Fish [0090] “MOOSQ Contents after Comparison [e.g. initial comparison]”)
PNG
media_image1.png
196
562
media_image1.png
Greyscale
Regarding claim 3, Fish-Bourbonnais teaches all limitations and motivations of claim 2, wherein the first batch of rows of the particular table in the first database comprises one or more key columns of rows that are not identical to a row in the corresponding table in the second database based on the row hash comparison. (See Fish [0090] “MOOSQ Contents after Comparison”
PNG
media_image1.png
196
562
media_image1.png
Greyscale
Thus, first batch of rows of the particular table in the first database [e.g. source] comprises one or more key columns of rows that are not identical to a row in the corresponding table in the second database [e.g. target] based on the row hash comparison.)
Regarding claim 7, Fish-Bourbonnais teaches all limitations and motivations of claim 1, wherein: the first database is of a first type, the second database is of a second type that is different from the first type, and performing the initial comparison comprises converting columns of the particular table in the first database and columns of the corresponding table in the second database to a standardized data type format. (See Fish [0050-0053] “The invention may be used in connection with heterogeneous data stores [e.g. the first database is of a first type, the second database is of a second type that is different from the first type]. Heterogeneous data stores may store the exact same information differently. For example:
PNG
media_image3.png
347
457
media_image3.png
Greyscale
In each of these tables, the value of the data is actually the same, but represented differently.” See also Fish [0117, 0193] “Using the Heterogeneous Data Stores example, data is standardized for both ORACLE_ORDER and SYBASE_ORDER tables… The column data for each row is standardized after selection to allow for heterogeneous cases [Thus, converting columns of the particular table in the first database and columns of the corresponding table in the second database to a standardized data type format]”)
Regarding claim 8, Fish-Bourbonnais teaches all limitations and motivations of claim 1, wherein: performing the initial comparison generates a plurality of batches of rows that are flagged as being out of sync to be fetched from the first database and a plurality of batches of rows that are flagged as being out of sync to be fetched from the second database, and performing the second comparison comprises performing a comparison of a plurality of sets of rows received from the first agent and a plurality of sets of rows received from the second agent. (See Fish [0027] “a specific subset of rows (as defined by a unique key) is designated the “source” in TABLE1 [Thus, to be fetched from the first database] and the “target” in TABLE2, while another subset of rows is designated the “source” in TABLE2 [Thus, to be fetched from the second database] and the “target” in TABLE1” See also Fish [0190-0197] “tables are compared [Thus, performing the initial/second comparison] using a batch hash technique. In one embodiment, the batch hash technique is broken into two phases for descriptive purposes (although they may be run simultaneously):
1. Bad Batch Determination
2. Row Detail Fetch and Compare
Once these phases are completed, a MOOSQ holds the “maybe out of sync” row set (as with the Row Hash technique) [e.g. plurality of sets of rows received from the first agent / second agent] … Bad Batch Determination may be implemented as follows. As with the Row Hash technique, Host Server processes retrieve rows from the source and target tables. The column data for each row is standardized after selection to allow for heterogeneous cases… specific row and column subsets can be selected from each table… row retrieval from source and target tables will occur in parallel in HS1 (e.g., DB1 118) and HS2 (e.g., DB2 138) Using the retrieved rows, HS1 subsequently builds and sends batches of row information to HS2 [Thus, generates a plurality of batches of rows that are flagged as being out of sync to be fetched from the first database and a plurality of batches of rows that are flagged as being out of sync to be fetched from the second database]” See also Fish [0223-0224] “ The CC process in turn writes the bad batch record into the Maybe Out of Sync queue (MOOSQ). The MOOSQ holds the boundaries for batches [e.g. first, second batches of rows] that are out of sync. This means that at least one row per batch was out of sync, and perhaps more. At this point, a second step occurs to determine the exact row set that is out of sync. This step is known as “row detail fetch” [Thus, flagged as being out of sync to be fetched from the databases (e.g. first, second database)]”)
Bourbonnais also teaches performing the second comparison comprises performing a comparison of a plurality of sets of rows received from the first agent and a plurality of sets of rows received from the second agent. (See Bourbonnais [0048] “the merger threads can be regarded as agents 402 1-n [e.g. first, second agents] configured to determine differences [e.g. first, second comparisons] between the source and target tables. The determined differences are inserted as difference entries into a difference queue, whereafter the difference reporter thread processes the difference entries and records results in a difference table accordingly.” See also Bourbonnais claim 9 “difference types are determined based on comparing non-key values of the first and second sets of differences, wherein the first set of differences is generated via a first comparison operation comparing a set of rows between the source [e.g. from the first agent] and target tables [e.g. from the second agent], wherein the second set of differences is generated via a second comparison [Thus performing a second comparison] operation restricted to comparing a subset of rows [e.g. sets of rows received from the second agent] between the source and target tables, to which the first set of differences pertains”)
Regarding claim 9, Fish-Bourbonnais teaches all limitations and motivations of claim 1, further comprising the server causing results of the second comparison to be presented in a graphical user interface. (See Bourbonnais [0071-0076 “the application 102 outputs at least one of: (i) an indication that at least one difference in the set of persistent differences [e.g. results of the second comparison] is a persistent difference and (ii) an indication that at least one difference in the set of transient differences in a transient difference… FIG. 17 is a block diagram illustrating components of a networked system 1700 configured to determine differences between a source table and a target table… The output device 1716 may be any device for providing output [e.g. results of the second comparison to be presented] to a user of the computer 1702… the output device 1716 may be any conventional display screen… For example, a display screen with an integrated touch-screen [e.g. in a graphical user interface] may be used.)
Regarding claim 10, Fish-Bourbonnais teaches all limitations and motivations of claim 1, wherein the second database is a replicated copy of the first database. (See Fish [0025, 0027-0030] “if replication is being used to move data from database PRIMARY to database BACKUP, database PRIMARY and tables within it are considered to be a “source” and BACKUP and tables within it are considered to be the “target”… a specific subset of rows (as defined by a unique key) is designated the “source” in TABLE1 and the “target” in TABLE2, while another subset of rows is designated the “source” in TABLE2 and the “target” in TABLE1 either table can modify any row, and that row is then copied to the other system… Two tables are synchronized (i.e., “in sync”) if the following conditions are true: all rows in one table can be found in the other table, as identified by a unique key (corresponding rows) [Thus, the second database is a replicated copy of the first database]”)
Regarding claim 11, Fish-Bourbonnais teaches all limitations and motivations of claim 1, wherein the first database is a replicated copy of the second database. (See Fish [0025, 0027-0030] “if replication is being used to move data from database PRIMARY to database BACKUP, database PRIMARY and tables within it are considered to be a “source” and BACKUP and tables within it are considered to be the “target”… a specific subset of rows (as defined by a unique key) is designated the “source” in TABLE1 and the “target” in TABLE2, while another subset of rows is designated the “source” in TABLE2 and the “target” in TABLE1 either table can modify any row, and that row is then copied to the other system… Two tables are synchronized (i.e., “in sync”) if the following conditions are true: all rows in one table can be found in the other table, as identified by a unique key (corresponding rows) [Thus, first database is a replicated copy of the second database]”)
Regarding claim 12, Fish-Bourbonnais teaches all limitations and motivations of claim 1, wherein the temporary table includes a column for each key column of the particular table used to flag the first batch of rows as being out of sync. (See Fish [0090] “MOOSQ [e.g. temporary table] Contents after Comparison”
PNG
media_image1.png
196
562
media_image1.png
Greyscale
Thus, the temporary table includes a column for each key column of the particular table used to flag the first batch of rows as being out of sync.)
Regarding claim 13, Fish-Bourbonnais teaches all limitations and motivations of claim 12, wherein the join operation comprises an inner join operation that selects all columns of the particular table and joins with the columns of the temporary table. (See Bourbonnais [0038] “the merger thread 210 competes with the other merger threads for a permit for fetching from the global temporary table. After earning the permit, the merger thread 210 sends a merge request to the worker threads 302 to initiate a merge-compare sub-stage. During the merge-compare sub-stage, the two worker threads 302 working on the partition fetch the key and corresponding row-based checksum from the global temporary tables, sorted by key order, and pass them to the merger thread 210 via a checksum item queue. The merger thread 210 then performs a merge join [e.g. inner join] on the key values [e.g. all columns of the particular table] to discover differences on a row-by-row basis [Thus, joins with the columns of the temporary table]”
Examiner notes that a merge join provides an output that is generated by joining two sorted data sets using a full, left, or inner join. See https://learn.microsoft.com/en-us/sql/integration-services/data-flow/transformations/merge-join-transformation?view=sql-server-ver17)
Regarding claim 16, Fish-Bourbonnais teaches all limitations and motivations of claim 1, wherein the temporary table comprises a global temporary table or a private temporary table. (See Bourbonnais [0034] “ The table comparison utility, also referred to as a comparison utility, is a parallel utility that compares tables… The parallel utility then creates non-logged, global temporary tables at the respective databases storing the source and target tables. The global temporary tables store temporary records of row-based key values and checksums, which are subsequently used for a row-by-row comparison when partition-based checksums do not match. [Thus, the temporary table comprises a global temporary table]”)
Regarding claim 17, Fish-Bourbonnais teaches all of the elements of claim1. Therefore, the supporting rationale of the rejection to claim 1 applies equally as well to those elements of claim 17.
Regarding claim 19, Fish-Bourbonnais teaches all of the elements of claims 12-13. Therefore, the supporting rationale of the rejection to claims 12-13 applies equally as well to those elements of claim 19.
Regarding claim 20, Fish-Bourbonnais teaches all of the elements of claim 9. Therefore, the supporting rationale of the rejection to claim 9 applies equally as well to those elements of claim 20.
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Fish-Bourbonnais, in view of Li (US Patent Application Publication No. US 20100082671 A1).
Regarding claim 14, Fish-Bourbonnais teaches all limitations and motivations of claim 1, wherein the join operation comprises a hash join operation. (See Fish [0190-0193] ”tables are compared using a batch hash technique… features enabling overlapping rows and columns apply equally to the Batch Hash technique—specific row and column subsets can be selected from each table [e.g. a hash join operation].”)
However, Li teaches wherein the join operation comprises a hash join operation. (See Li [0059] “A hash join operation comprises the following steps: performing the hash algorithm on the temporary table 124 to form a hash table, so that the original columns having the same or similar hash result value will be considered as the same hash columns; thus, first comparing the hash table with the table T2 122, and then in the case that the result value is matching, searching the temporary table 124 for the corresponding matching columns; afterwards, performing the join operation on the matching columns in the temporary table 124 and the table T2 122 to obtain the result set.”)
It would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to modify Fish-Bourbonnais which compare tables using a batch hash technique, where specific row and column subsets can be selected from each table, to incorporate the teachings of Li of using a hash join for comparing tables for matching columns.
One would be motivated to do so to reduce disk I/O cost (Li 0059).
Allowable Subject Matter
Claims 4-6, 15 and 18 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 and any intervening claims. After sufficient search and analysis, Examiner concluded that the claimed invention has been recited in such a manner that dependent claims 4, 6, 15 and 18 are not taught by any prior reference found through search. The primary reason for allowance of the claims in this case, is the inclusion of the limitations “"the particular table in the first database has no index, and the one or more key columns are a subset of columns of the particular table having one or more of a predetermined set of datatypes.”, “the particular table in the first database has no index, and the one or more key columns comprise a key column selected by a user.”, and “wherein the particular table of the first database has no index columns.” which are not found in the prior art of record. Incorporating claims 4, 6, 15 and 18 into independent claims would put claims in condition for allowance.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to OSCAR WEHOVZ whose telephone number is (571)272-3362. The examiner can normally be reached 8:00am - 5:00pm ET.
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, APU M MOFIZ can be reached at (571) 272-4080. 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.
/OSCAR WEHOVZ/Examiner, Art Unit 2161
/APU M MOFIZ/Supervisory Patent Examiner, Art Unit 2161
Prosecution Insights