DETAILED ACTION
This action is responsive to Applicant amendments filed on July 16, 2026.
The amendments filed on July 16, 2026, have been acknowledged and considered.
Claims 1, 3, 13, 17 and 19 have been amended. Claims 2 and 12 have been canceled. Claims 21-22 are new.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
Applicant's Remarks, filed July 16, 2026, has been fully considered and entered.
Accordingly, Claims 1, 3-11 and 13-22 are pending in this application. Claims 1, 3, 13, 17 and 19 have been amended. Claims 21-22 are new. Claims 1 and 17 are independent claim.
Response to Arguments
Applicant’s arguments, see pages 7-16, filed July 16, 2026, with respect to the rejection of claims 1, 3, 7-11, 13-14, 16-17 and 19-20, have been fully considered, but they are not persuasive.
Argument 1: Applicant argues on pages 9–10 of Applicant Arguments and Remarks that "Fish does not teach that the CC inserts the bad batch into a temporary table at the first (source or target) database… Fish does not teach or suggest that the MOOSQ itself is stored in DB1 118 or DB2 138… The MOOSQ is a queue/file, not a database structure".
Response to Argument 1: Examiner respectfully disagrees. Fish's Compare Client (CC) process is mapped to the claimed server and Fish's Host Server processes HS1 and HS2 are mapped to the claimed first and second agents (See Fish [0054] "two Host Server (HS) processes (e.g., on computers 104 and 106)" See also Fish [0196] "HS1 (e.g., DB1 118) and HS2 (e.g., DB2 138)").
Fish is not relied upon for a temporary table in the first database. As stated in the prior action and in the rejection below "Fish does not explicitly disclose the use of a temporary table". Fish is relied upon for the content of the batch, where the batch of flagged rows comprises the key columns of the particular table. See Fish [0085] "the MOOSQ holds the keys to all rows that were found to be out of sync" See also Fish [0090] Table 15, "Source Row Key | Target Row Key"). The temporary table in the first database comprising key columns is taught by Bourbonnais [0034, 0037]. One cannot show non-obviousness by attacking references individually where the rejection is based on a combination of references. In re Keller, 642 F.2d 413 (CCPA 1981); In re Merck, 800 F.2d 1091 (Fed. Cir. 1986). See MPEP 2145.
Additionally, Applicant's characterization that Fish never contemplates staging out-of-sync row data in a table residing in the source database is factually incorrect. See Fish [0327-0329] "if the operation type is a missing insert or missing update using the key value, select all of the columns from the source row… at a minimum, record the column values, along with the table name, and operation type into a RESYNC_MARKER table." See also Fish [0330-0333] "if the row does not exist, at a minimum, record the key column values [the key columns of the particular table], along with the table name, operation type or current time of day into a RESYNC_MARKER table." See also Fish [0337] "rows created within the table must be logged to either the database transaction log or equivalent… the transaction log must be the same as the transaction log used by the underlying source table" [i.e., the RESYNC_MARKER table resides in the same database as the source table]. Fish thus explicitly teaches writing the key column values of out-of-sync rows into a table located in the first (source) database, which is precisely the structure Applicant argues is absent from Fish. See rejection below.
Therefore, the Examiner has determined that this argument is not persuasive.
Argument 2: Applicant argues on pages 12–13 of Applicant Arguments and Remarks that in Bourbonnais "the temporary table serves as a data structure from which the merger thread fetches the row checksums. The temporary table in Bourbonnais is not being joined with the source table 104 or the target table 106," that "the merge join is performed after fetching the row checksums" and "is not used to fetch rows from the database table," and that "The merge join is performed within the application."
Response to Argument 2: This argument is moot in view of new grounds of rejection necessitated by amendment. Bourbonnais's merge join performed by the merger thread on two key/checksum streams is not relied upon in the rejection below to teach the claimed join operation.
Therefore, the Examiner has determined that this argument is not persuasive.
Argument 3: Applicant argues on pages 13–14 of Applicant Arguments and Remarks that "Li thus joins a temporary table populated from one table (T1) against a second, different table (T2)," whereas "Amended claim 1… requires a join 'between the temporary table … and the particular table of the first database' in which the temporary table is populated from that same particular table," and that "Li's join produces a joined result set that combines columns of T1 (supplied via the temporary table) with columns of the different inner table T2," while the claim requires that "The columns retrieved by the claimed join are the particular table's own columns."
Response to Argument 3: Examiner respectfully disagrees, for three independent reasons. The argument is based on a limitation not present in the claim. Claim 1 does not recite that the temporary table is "populated from that same particular table." Claim 1 recites that the temporary table is populated by "inserting the first batch of rows" and the first batch of rows is the output of the server's initial comparison, not a direct read of the particular table. What claim 1 requires of the temporary table is only that it comprise the one or more key columns of the particular table (i.e. the key columns on which the join is performed). Li teaches that the temporary table at the data source is populated with data transmitted by the server, and it carries the column on which the base table is joined. See Li [0056] "the federated database server 150 transmits the block data obtained from the data source 1 110 as the retrieval result to the data source 2 120, and inserts it into a temporary table 124 created in the data source 2 120." See also Li [0047] "the temporary table stores the block data of the data source 1 received from the server (at least containing those columns related to the join operation)."
Applicant's characterization of what Li's join returns is factually incorrect. In Li's operation mode 1, the non-related columns of T1 are not transmitted to the data source and are not part of the join. See Li [0057] "those non-related columns in the block data from the data source 1 can be kept at the server side rather than transmitted to the data source 2, and those non-related columns are replaced with an additional row pointer column… With the row pointer column, only those columns related to the join operation can be contained in the created temporary table 124."
Thus, what the join at the data source actually returns is the join key plus the inner table's own columns. See Li [0078], Form 5: result set = "Row Pointer | A3(=B1) | B2," where the row pointer is a mere identifier and B2 is a column of the inner table B retrieved from the inner table itself. The concatenation with T1's columns that Applicant relies upon occurs later, at the server, and is a separate step, See Li [0063] "at Step 6, if the row pointer column is used in the temporary table 124, the server 150 merges the result set 154 with the block data 158." Li [0085] confirms the data source's output: "transmitting at least related columns in the retrieved block data to the second data source and inserting them into a temporary table, for performing a join operation with a table in the second data source… and receiving a joined result set from the second data source."
Li's join operation at the data source therefore does exactly what claim 1 recites: it selects the columns of the base table and joins with the key/join column carried in the temporary table, to retrieve, from the base table, that table's own columns, including columns other than the join column (B2), for the rows corresponding to the values staged in the temporary table. See rejection below.
Therefore, the Examiner has determined that this argument is not persuasive.
Argument 4: Applicant argues on pages 14–15 of Applicant Arguments and Remarks that in Li's Form 4 temporary table, "column A3 includes repeated values (e.g., 1, 2, 10); therefore, column A3 is not equivalent to 'one or more key columns used to identify each row'… The temporary table of Li is not a 'temporary table comprising the one or more key columns of the particular table.'"
Response to Argument 4: Examiner respectfully disagrees. Li is not relied upon to teach that the temporary table comprises key columns, Bourbonnais is. See Bourbonnais [0034] "The global temporary tables store temporary records of row-based key values and checksums." See also Bourbonnais [0037] "The key values and checksums are inserted into a non-logged, global temporary table instance." See also Bourbonnais [0041] "The uniqueness characteristic specifies that tables have a unique property, such as a unique key, for a subset of common columns," and "the unique property is required to be the same on the source and target tables." Bourbonnais's temporary table therefore comprises the unique key columns used to identify each row. Fish also teaches that the batch inserted comprises those key columns (Fish [0085], [0090] Table 15. See Fish [0023] "A 'unique key' (UK) in each table is a set of columns within the table used to uniquely identify each row within the table").
One cannot show non-obviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413,208 USPQ 871 (CCPA 1981); In re Merck & Co., Inc., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). See MPEP 2145. See rejection below.
Therefore, the Examiner has determined that this argument is not persuasive.
Argument 5: Applicant argues on page 15 of Applicant Arguments and Remarks that "The Fish and Bourbonnais databases… are redundant data stores that are being synchronized. On the other hand, Li's data sources are heterogeneous databases. The references themselves provide no suggestion or motivation for combining Li's join technique with the database comparison systems of Fish and Bourbonnais… therefore, the rejection is based on impermissible hindsight."
Response to Argument 5: Examiner respectfully disagrees. Fish's redundant data stores are heterogeneous databases. See Fish [0050] "The invention may be used in connection with heterogeneous data stores. Heterogeneous data stores may store the exact same information differently." See also Fish [0051-0053] disclosing ORACLE_ORDER / SYBASE_ORDER example, and Fish [0106] disclose conversion "With Heterogeneous Data Stores". Bourbonnais [0028] also contemplates tables "stored in respective databases operatively connected via a network." Fish and Li are therefore in the same field of endeavor, retrieval of rows from database tables residing at remote data sources under the direction of a server, and Li [0002] discloses this "Aspects of the present invention relate generally to database information management systems."
Under KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007), a suggestion in the references is not required, and "any need or problem known in the field of endeavor at the time of invention and addressed by the patent can provide a reason for combining." The rejection below does not rely on Applicant's disclosure for its rationale, it relies on the teachings of Li [0047, 0060] and on the architectural constraints of Fish [0002] and [0054]. A rejection is not based on impermissible hindsight where the rationale is drawn from the prior art itself. In re McLaughlin, 443 F.2d 1392 (CCPA 1971); MPEP 2145(X)(A).
Therefore, the Examiner has determined that this argument is not persuasive.
Argument 6: Applicant argues on pages 15–16 of Applicant Arguments and Remarks that "Fish's row detail fetch step has no corresponding problem for Li's solution to address. Each HS process in Fish retrieves rows from a single table using one range query per bad batch record… There is no second, different 'inner table' in Fish's fetch step that must otherwise be scanned once per row of a first table; Fish's fetch involves only the one table being queried. Because the repeated-full-table-scan problem that motivates Li's hash join is structurally absent from Fish's single-table fetch, Li's articulated disk-I/O rationale provides no reason a person of ordinary skill in the art would have modified Fish's fetch step to use Li's cross-table hash join technique."
Response to Argument 6: Examiner respectfully disagrees. Fish recognizes the cost Applicant argues is absent. See Fish [0227-0228] “each HS process formulates a query to return each row that is in the range of the bad batch record… alternatively, if the same HS processes are used in both the batch retrieval step and the row detail fetch step, the HS process can cache the detailed row data during batch retrieval, anticipating that the detail might be required” Thus, Fish acknowledges that its fetch would otherwise re-read row data already retrieved during batch retrieval, and treats that repeated access as a cost worth considering. Fish also generates many such bad batch records, see Fish [0198] disclose that "a fixed number N is chosen for the 'source batch size' (for example, 10 rows)", Fish [0204, 0225] further disclose that "this is repeated for rows N+1 through 2N, 2N+1 through 3N, and so on", where "bad batches are retrieved by the CC".
Li's baseline prior art operation is itself a single-table key lookup, not a cross-table operation. Li [0037] disclose that the second sub-statement is "select T2.C2 from T2 where T2.C1=X", which is a query against one table, retrieving that table's own column, predicated on a supplied key value. Li's improvement converts N such key-predicated lookups into one join against a temporary table holding the N key values. Fish's row detail fetch is structurally based in the same way, a query against one table, predicated on supplied key values from the bad batch record (Fish [0227]). Li's rationale therefore maps directly onto Fish's fetch step.
Li's rationale is not limited to disk I/O. See Li [0039] "if the data source is a relational database system capable of applying predicates and doing join operations, it will be a good idea to take advantage of the power of the database system if it can perform some processing remotely so as to reduce the amount of data that must be returned to the server 150." See also Li [0045] "the above process may bring very high communication cost since the SQL statements and returned results are to be transmitted continuously between different physical machines." That rationale applies directly to Fish, whose entire design is driven by that same constraint, see Fish [0002] "geographic separation accompanied by limited bandwidth between data sources" See also Fish [0054] "the connection between the HS and DB is usually on the same system or over a very high-speed network, because potentially high amounts of data are flowing between each HS and DB" See also Fish [0060] (blocking and compression "reducing the amount of data that needs to be transferred over the network significantly").
The motivation to combine need not be the same as Applicant's, and need not solve the identical problem. In re Beattie, 974 F.2d 1309, 1312 (Fed. Cir. 1992); MPEP 2144(IV). It is sufficient that Fish's per bad batch record query and Li's temporary table join are known, interchangeable techniques for retrieving the rows of one table identified by a set of values supplied by the server, and that substituting one for the other yields the predictable result of retrieving those same rows. See MPEP 2143(I)(B). See rejection below.
Therefore, the Examiner has determined that this argument is not persuasive.
Claim Rejections - 35 USC § 112
Claim 3-6, 13 and 19 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 3 recites “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.” Claim 1, from which claim 3 depends, recites “the particular table comprises a plurality of columns including one or more key columns used to identify each row and one or more non-key columns” and further recites “wherein the first batch of rows comprises the one or more key columns of the particular table”. It is unclear whether claim 3 restates the key columns already required in claim 1, introduces a second, different set of key columns that the first batch of rows must comprise in addition to the key columns required by claim 1. This limitation renders the scope of claim 3 unascertainable. For the purpose of examination “one or more key columns” in claim 3 is interpreted to be “the one or more key columns”.
Regarding claims 4 and 6, which depend on claim 3, further recites “the one or more key columns”, and further confuses the antecedent basis. Claim 4, which depends on claim 3, requires that the key columns of the particular table be a subset of columns having one or more predetermined datatypes, and claim 6, which also depends on claim 3, requires that those key column comprise a key column selected by a user. It is not clear which antecedent is intended and the scope is indefinite.
Claim 5 is rejected for depending on claim 4.
Claim 13 recites "an inner join operation that selects all columns of the particular table and joins with the columns of the temporary table", where amended claim 1 recites that the join "selects the plurality of columns of the particular table and joins with the one or more key columns of the temporary table." It is unclear whether "all columns" refer to "the plurality of columns" that joins with the one or more key columns of the temporary table. Claim 13 lacks clear antecedent basis in view of claim 1's narrower recitation. Claim 19 is rejected on the same basis with respect to claim 17.
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-11, 13-14, 16-17 and 19-22 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) , and further in view of Li (US 20100082671 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 including one or more key columns used to identify each row and one or more non-key columns, (See Fish [0023] "A 'unique key' (UK) in each table is a set of columns within the table used to uniquely identify each row within the table [e.g. one or more key columns used to identify each row]. For example, in the PRODUCT table, Product Number is a unique key because it never repeats in the table. In the ORDER table, Order Number is not unique because it repeats… However, a combination of Order Number and Product Number constitutes a unique key" See also Fish [0057] "The HS then 'packs' the following data for each row into a memory buffer. That is, the HS packs all columns that make up a unique key for the row [Thus, one or more key columns] and the HS also packs a 'row hash' of the remaining columns in the row [Thus, one or more non-key columns]" See also Fish [0056] "Each row retrieved consists of one or more columns of data [Thus, the particular table comprises a plurality of columns] (as defined by the database itself or via user-supplied metadata)")
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]” See also Fish [0196] “row retrieval from source and target tables will occur in parallel in HS1 (e.g., DB1 118) and HS2 (e.g., DB2 138) [Thus, the second agent executing on the second machine, which manages DB2]" See also Fish [0054] "For maximum efficiency, the connection between the HS and DB is usually on the same system.")
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)])
wherein the first batch of rows comprises the one or more key columns of the particular table; (See Fish [0085] "After the comparison, the MOOSQ holds the keys to all rows that were found to be out of sync [Thus, the first batch of rows comprises the one or more key columns of the particular table]. Each of these keys can then be used to select the full row image from the database, to produce a list of rows that are out-of-sync." See also Fish [0090-0091] "MOOSQ Contents after Comparison
PNG
media_image1.png
262
801
media_image1.png
Greyscale
[Thus, the batch entries carry the key column values of the flagged rows]” See also Fish [0064] "the keys and hashes for the rows compared are stored" See also Fish [0188] "COOS Processing uses the row keys, hashes and related information produced by the Row Hash technique to determine which rows are possibly out of sync, and to then use that information to lookup the detailed row data")
the server causing the first agent to fetch a first set of rows by: (See Fish [0225-0227] "bad batches are retrieved by the CC [e.g. the server]… the CC requests the underlying row detail (each row's columns) from both the source (HS1) [Thus, the server causing the first agent to fetch a first set of rows] and the target (HS2); each HS process formulates a query to return each row that is in the range of the bad batch record [Thus, the first agent fetching a first set of rows from the particular table]" See also Fish [0258] "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")
inserting the first batch of rows into a temporary table in the first database, the temporary table comprising the one or more key columns of the particular table;
Fish teaches writing the flagged batch of rows into a holding structure and recording the key column values of out-of-sync rows into a table residing in the first database (See Fish [0223] "The CC process in turn writes [Thus, inserting] the bad batch record [e.g. first batch of rows] into the Maybe Out of Sync queue (MOOSQ). The MOOSQ holds the boundaries for batches that are out of sync" See also Fish [0090-0091] "MOOSQ Contents after Comparison" See also Fish [0330-0333] "if the operation is a missing delete using the key value, select all of the columns from the source row… if the row does not exist, at a minimum, record the key column values [Thus, the one or more key columns of the particular table], along with the table name, operation type or current time of day into a RESYNC_MARKER table [Thus, a table]" See also Fish [0327-0329] "at a minimum, record the column values, along with the table name, and operation type into a RESYNC_MARKER table" See also Fish [0337] "rows created within the table must be logged to either the database transaction log or equivalent (the replication change data source) — the transaction log must be the same as the transaction log used by the underlying source table [Thus, the RESYNC_MARKER table resides in the same database as the particular table (i.e. in the first database)]" See also Fish [0338] "it can store data for different table structures — it does not have to be the same structure as the underlying source table(s), as long as it can store the column values of the source table in some way")
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, the temporary table comprising the one or more key columns of the particular table, in more details. (See 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 [Thus, a temporary table in 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 [Thus, the temporary table comprising the one or more key columns of the particular table] and checksums, which are subsequently used for a row-by-row comparison when partition-based checksums do not match" See also Bourbonnais [0036-0037] "The worker threads 302 then call a stored procedure on each of the source and target databases [Thus, the insertion is performed by a database-side agent process at the first database]… The stored procedure receives the query statement as an input parameter and performs multi-row fetches against the database to extract all rows within the identified partition… The key values and checksums are inserted into a non-logged, global temporary table instance [Thus, inserting the key columns into a temporary table at the database] associated with the calling worker thread 302" See also Bourbonnais [0041] "The uniqueness characteristic specifies that tables have a unique property, such as a unique key, for a subset of common columns. At least in some embodiments, the unique property is required to be the same on the source and target tables [Thus, the key values stored in the temporary table are the key columns used to identify each row of the particular table]")
Fish teaches that the MOOSQ can be a memory queue, a file or equivalent mechanism for storing row comparison data as rows are found out of sync (Fish [0063-0066]). Bourbonnais disclose such equivalent mechanism, used for the same purpose in the same two-stage comparison, where the utility creates non-logged, global temporary tables at the respective databases which 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 (Bourbonnais [0034]).
Therefore, a person having ordinary skills in the art would have found it obvious to substitute Fish’s server side “maybe out of sync queue” with Bourbonnais’s non-logged global temporary table at the respective database, as both are known interchangeable mechanisms for holding the key values of flagged rows pending a subsequent row-level comparison, yielding the predictable result of those key values being available for that comparison.
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, wherein the join operation selects the plurality of columns of the particular table and joins with the one or more key columns of the temporary table,
Fish teaches that the database-side agent formulates and executes the retrieval operation against the particular table. (See Fish [0227] "each HS process formulates a query to return each row that is in the range of the bad batch record; for example, if a bad batch record has a beginning record with key 'B' and ending record with key 'E', then anything between those key values (inclusive) will be returned")
Fish does not explicitly disclose the use of a join between the temporary table in the first database and the particular table.
However, Li 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, wherein the join operation selects the plurality of columns of the particular table and joins with the one or more key columns of the temporary table. (See Li [0047] “a temporary table for performing the join operation with the inner table is created on the data source 2, wherein the temporary table stores the block data of the data source 1… (at least containing those columns related to the join operation) [Thus, the temporary table comprises the columns on which the join is performed]… the hash join or block nested loop join is performed on the data in the temporary table and the local data in the inner table of the data source 2 [Thus, a join operation between the temporary table and the particular table, both resident in the same database]” See also Li [0059] “performing the join operation on the matching columns in the temporary table 124 and the table T2 122 to obtain the result set [Thus, the join operation is on the matching columns of the temporary table and the particular table]" See also Li [0068, 0077-0078] “The SQL statement will retrieve… the data B.B2 from the table B [Thus, the join selects a column of the particular table], and the condition of A.A3=B.B1 should be matched [Thus, the particular table column B1 is joined with the temporary table’s column A3]… At Step 345, the join operation is performed on the temporary table and the inner table (the table B) in the data source 2… The result set returned in the server 150 is shown as the following Form 5.
PNG
media_image2.png
426
706
media_image2.png
Greyscale
[Thus, the join returns column B2 of the particular table of the rows matching the temporary table’s column A3]” See also Li [0039] "if the data source is a relational database system capable of applying predicates and doing join operations, it will be a good idea to take advantage of the power of the database system if it can perform some processing remotely [Thus, performing, by the first agent at the machine managing the first database, the join operation] so as to reduce the amount of data that must be returned to the server 150")
Fish [0227-0228] disclose that it recognizes the cost of re-reading the table during the row detail fetch where “each HS process formulates a query to return each row that is in the range of the bad batch record… alternatively, if the same HS processes are used in both the batch retrieval step and the row detail fetch step, the HS process can cache the detailed row data during batch retrieval, anticipating that the detail might be required [Thus, Fish recognizes that its fetch would otherwise re-read row data already retrieved during batch retrieval]”. Li reduces that same cost by staging the keys in a temporary table and joining it against the base table and “the number of physical accesses to the inner table can be greatly reduced” (Li [0047)] and “it is only needed to scan the original inner table… once” (Li [0060]).
Therefore, a person having ordinary skills in the art would have found it obvious to substitute Fish’s per bad batch record query with Li’s join between the temporary table and the particular table, as both are known techniques for retrieving the rows of one table identified by a set of key values, yielding the predictable result of retrieving those same rows. One would have been motivated to do so to reduce resource utilization as taught by Li [0047, 0060].
Fish-Bourbonnais in view of Li, [hereinafter Fish-Bourbonnais-Li] additionally disclose to retrieve, from the particular table, the plurality of columns, including the one or more non-key columns, of the first set of rows, and wherein the first set of rows are rows of the particular table that correspond to the first batch of rows inserted into the temporary table; and (See Li [0059] “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 [Thus, the first set of rows are the rows of the particular table corresponding to rows inserted to the temporary table]” See also Li [0078]
PNG
media_image2.png
426
706
media_image2.png
Greyscale
[Thus, the join retrieves B2, a non-key column of the particular table] See also Li [0059] "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 [Thus, the first set of rows are the base-table rows that correspond to the rows staged in the temporary table]" See also Fish [00226] “the CC requests the underlying row detail (each row's columns) [Thus, the plurality of columns, including the one or more non-key columns] from both the source (HS1) and the target (HS2)” See also Fish [0085] "Each of these keys can be used to select the full row image from the database”)
returning, by the first agent, the plurality of columns of the first set of rows from the particular table to the server; and (See Fish [0229] "the rows are returned to the CC [Thus, returning to the server]" See also Fish [0258] "The CC retrieves the row detail for the implied row set bounded by begin and end key values, from each of HS1 [Thus, returned by the first agent] and HS2" See also Li [0047] "and the joined result is returned to the server" See also Li [0077] "At Step 350, the joined result set is returned to the federated database server 150")
and 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, (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” See also Fish [0258] “The CC retrieves the row detail… from each of HS1 and HS2. Once rows have been retrieved, they are compared in the order retrieved [Thus, the server performing a second comparison of the rows received from the first and second agents]”)
wherein the second comparison is based on a literal value-by-value comparison of the plurality of columns, wherein the method is performed by one or more computing devices. (See Fish [0189] "For those rows that are in both tables, but that have different values in non-key columns, the data for the non-key columns does not have to be a row hash — it can be anything that represents the value of those columns, including the column values themselves [Thus, a literal value-by-value comparison rather than a hash comparison]” See also Fish [0259-0260] “Comparison Processing
PNG
media_image3.png
362
638
media_image3.png
Greyscale
[Thus, the second comparison operates on the literal column values of the retrieved rows]” See also Fish [0029-0031] “Two tables are synchronized (i.e., “in sync”) if the following conditions are true: …all columns within each row match all columns in the corresponding row in the other table” See also Bourbonnais claim 9 “difference types are determined based on comparing non-key values of the first and second sets of differences [Thus, literal value-by-value comparison of the plurality of columns]
Regarding claim 3, Fish-Bourbonnais teaches all limitations and motivations of claim 1, 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_image4.png
196
562
media_image4.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_image5.png
347
457
media_image5.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 13, Fish-Bourbonnais teaches all limitations and motivations of claim 1, 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 14, Fish-Bourbonnais teaches all limitations and motivations of claim 1, 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.”)
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 claim 13. Therefore, the supporting rationale of the rejection to claim 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.
Regarding claim 21, Fish-Bourbonnais teaches all of the elements of claim 10. Therefore, the supporting rationale of the rejection to claim 10 applies equally as well to those elements of claim 21.
Regarding claim 21, Fish-Bourbonnais teaches all of the elements of claim 11. Therefore, the supporting rationale of the rejection to claim 11 applies equally as well to those elements of claim 21.
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
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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