DETAILED ACTION
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 .
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1 and 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Gandhi et al (US 7,478,099 B1) in view of Holenstein et al (US 20050021567 A1).
As to claims 1 and 14, Gandhi teaches A method comprising:
obtaining, by a compute device, transaction data indicative of transactions (NOTE: Examiner interprets the state indicator to mean any indicator or flag which acknowledges a change to data (see specification [0026], [0030], [0032], and [0033]). Gandhi column 3, line 38 through column 4, line 53 discloses receive transaction data (i.e. obtaining), rather than placing transaction data directly into the production database, data associated with the transaction that is stored within the production database can remain accessible in a read-only state during transaction processing while corresponding data in the staging database is modified (i.e. state indicator) with the transaction data arriving from the agent to the store process. Once an agent has successfully transmitted all partitions of data in a given transaction to a store process and the store process has committed these partitions to the staging database, the staging and production databases can then be synchronized to allow the production data to reflect all changes (i.e. state indicator) associated with the transaction. Thereafter, the production database can be returned to its normal read-write state. The agent software process divides the extra-large dataset into a plurality of partitions and transmits the plurality of partitions to a store system or process in the order in which the partitions are to be inserted into the staging database (i.e. chronological order). The store system, using the techniques explained herein, then transmits the plurality of partitions to the staging database rather than directly to the production database. In particular, upon receiving the first partition of the extra-large dataset from the agent, the database transaction collecting process (i.e. operating as part of a store process) disengages the staging database from synchronicity with the production database via a call to a lock manager. This prevents representative data from being written to the production database until the dataset (i.e., the plurality of partitions in the dataset) has been received at, and stored in the staging database and copied to the production database.);
providing, by the compute device, the transaction data to a staging table to prevent overwrites of data present in a target data set with older data (Gandhi column 4, lines 1-53 discloses The database transaction collecting process as disclosed herein operates on a staging database that is in communication with a production database, and receives a dataset from an agent software process. In one embodiment, the dataset is an extra-large dataset, and has been divided into partitions prior to being received at the staging database. Prior to a transaction occurring, tables in a staging database (i.e. staging tables) are kept in synchronicity with corresponding tables in a production database such that changes to production data (e.g. a console setting a parameter of a device in a storage array) are immediately reflected in the corresponding table in the staging database. Thus during periods where no transaction is taking place, the staging and production databases contain a set of corresponding tables (for those tables that are subject to staging as described herein). Prevents representative data from being written to the production database (i.e. overwritten) until the dataset (i.e., the plurality of partitions in the dataset) has been received at, and stored in the staging database and copied to the production database.); and
selectively writing data, by the compute device, from the staging table to the target data set to reconstruct a chronological sequence associated with the transactions based on the state indicator (Gandhi column 7, line 20 through column 8, line 54 discloses the data residing in the staging database is sequentially inserted into the production database based on changed data (i.e. modified transactions) over time, via agents.).
Gandhi does teach a SANs environment which allows data collected from a large SAN resource such as a storage array that has many thousands of devices configured as logical entities to store data in the SAN (Gandhi column 2, lines 27-56 and column 8, lines 8-19), but fails to teach transactions associated with threads of a multithreaded environment.
However, Holenstein teaches transactions associated with threads of a multithreaded environment (Holenstein [0196] discloses multiple parallel paths are provided for data item modifications or transactions to flow from the source database to the target database. Threads are implemented as similar processes running in parallel).
Before the effective filing date, it would have been obvious to one of ordinary skill in the art, to modify the teachings of Gandhi to incorporate the Ensuring Referential Integrity In Multi-threaded Replication Engines as taught by Holenstein for the purpose of ensuring that data replicated do not result in replication-induced database corruption or inconsistency.
Claim(s) 2-13 and 15-26 is/are rejected under 35 U.S.C. 103 as being unpatentable over Gandhi et al (US 7,478,099 B1) in view of Holenstein et al (US 20050021567 A1), and further in view of BECKER et al (US 20230044115 A1).
As to claims 2 and 15, Gandhi and Holenstein fail to teach provide the transaction data comprises to write an obtained state indicator indicative of a chronological status associated with each transaction in the corresponding record of the staging table.
However, BECKER teaches provide the transaction data comprises to write an obtained state indicator indicative of a chronological status associated with each transaction in the corresponding record of the staging table (BECKER Figure 2 shows a tabular representation of a portion of staging table 200. Staging table 200 is associated with a single database object. Each record represents a data change collected by staging system 110 for the associated database object. Each record of staging table 200 includes a key of the database object, one or more non-key fields, an operation type associated with the data change (e.g., Insert, Update, Delete), a sequence ID, and a package ID. BECKER [0035] discloses The sequence ID (i.e. obtained state indicator) indicates the temporal order of the data change with respect to other data changes received from producer job 122. The sequence IDs (i.e. obtained state indicator) may be used to ensure that the collected data changes are applied in the correct order. The sequence IDs may comprise monotonically increasing numbers, timestamps, or any other suitable data.).
Before the effective filing date, it would have been obvious to one of ordinary skill in the art, to modify the teachings of Gandhi and Holenstein to incorporate the PARALLEL READS OF DATA STAGING TABLE as taught by BECKER for the purpose of increasing data throughput by allowing multiple consumer jobs to operate in parallel with respect to same source data.
As to claims 3 and 16, BECKER teaches write an obtained state indicator comprises to write an obtained timestamp having millisecond precision or a globally unique identifier (BECKER [0035] discloses The sequence ID (i.e. obtained state indicator) indicates the temporal order of the data change with respect to other data changes received from producer job 122. The sequence IDs (i.e. obtained state indicator) may be used to ensure that the collected data changes are applied in the correct order. The sequence IDs may comprise monotonically increasing numbers, timestamps, or any other suitable data.).
As to claims 4 and 17, BECKER teaches provide the transaction data comprises to write data indicative of whether each record represents an insertion or an update (BECKER Figure 2 shows a tabular representation of a portion of staging table 200. Staging table 200 is associated with a single database object. Each record represents a data change collected by staging system 110 for the associated database object. Each record of staging table 200 includes a key of the database object, one or more non-key fields, an operation type associated with the data change (e.g., Insert, Update, Delete), a sequence ID, and a package ID.).
As to claims 5 and 18, BECKER teaches selectively write data from the staging table comprises to perform operations to prevent out of order writes to the same location in the target data set (BECKER [0047] discloses ensure that changes to specific records are processed in chronological order while allowing parallel processing of other changes).
As to claims 6 and 19, BECKER teaches to perform operations to prevent out of order writes to the same location in the target data set comprises to determine the target location as a function of one or more data fields of the corresponding record in the staging table that define a unique identifier for a transaction (BECKER [0032] discloses a transaction within source system 120 may update several non-key fields of a particular record of a particular data table 125, where the record is associated with a unique key value of the data table 125. BECKER [0047] discloses ensure that changes to specific records are processed in chronological order while allowing parallel processing of other changes).
As to claims 7 and 20, BECKER teaches to perform operations to prevent out of order writes comprises to perform the one or more operations as a function of whether a data field in the staging table indicates that the corresponding record represents an insertion or an update (BECKER Figure 2, [0032], and [0034] shows a tabular representation of a portion of staging table 200. Staging table 200 is associated with a single database object. Each record represents a data change collected by staging system 110 for the associated database object. Each record of staging table 200 includes a key of the database object, one or more non-key fields, an operation type associated with the data change (e.g., Insert, Update, Delete), a sequence ID, and a package ID.).
As to claims 8 and 21, BECKER teaches to perform operations to prevent out of order writes to the same location comprises to requeue a candidate update represented in the staging table in response to a determination that no records are associated with the target location (NOTE: BECKER [0035] discloses The sequence IDs may comprise monotonically increasing numbers, timestamps, or any other suitable data. BECKER [0047]-[0055] discloses a transaction queue includes any records representing a package having a status of “open”. It will be assumed that process 1200 is being executed by a first-initiated consumer job upon staging table 200 of FIG. 2, and that no transaction queue records currently exist. Accordingly, flow proceeds to S1220 to set a read lock on staging table 200, which corresponds to a subject table of a source system 120. No other consumer job is able to read staging table 200 while the first consumer job possesses the lock. BECKER then discloses that records are read and updated until no qualifying records remain to be read from staging table 200 (i.e. requeuing).).
As to claims 9 and 22, BECKER teaches to perform operations to prevent out of order writes to the same location comprises to determine whether a candidate update represented in the staging table has a state indicator indicative of an earlier time than one or more other updates in the staging table associated with the target location (NOTE: BECKER [0035] discloses The sequence IDs may comprise monotonically increasing numbers, timestamps, or any other suitable data. BECKER Figures 13 and 15 show a stage table comprising candidate updates to records with a sequence ID in descending order (i.e. possible timestamps in descending order). BECKER [0047] discloses ensure that changes to specific records are processed in chronological order while allowing parallel processing of other changes. This seems to suggest that records would be updated in a chronological order based on the earliest timestamp to latest timestamp in order to prevent over writes.).
As to claims 10 and 23, BECKER teaches to prevent, in response to a determination that the candidate update does have a state indicator indicative of an earlier time, writing of the candidate update to the target data set (NOTE: BECKER [0035] discloses The sequence IDs may comprise monotonically increasing numbers, timestamps, or any other suitable data. BECKER Figures 13 and 15 show a stage table comprising candidate updates to records with a sequence ID in descending order (i.e. possible timestamps in descending order). BECKER [0047] discloses ensure that changes to specific records are processed in chronological order while allowing parallel processing of other changes. This seems to suggest that records would be updated in a chronological order based on the earliest timestamp to latest timestamp in order to prevent over writes. IF no other candidate update (e.g. a single Sequence ID) would be processed immediately.).
As to claims 11 and 24, BECKER teaches to prevent writing of the candidate update to the target data set comprises to dequeue the candidate update from the staging table (BECKER [0055] discloses Once the records have been successfully processed, the read records are deleted from the staging table and the corresponding record is deleted from the transaction queue (i.e. dequeued) at S1290.).
As to claims 12 and 25, BECKER teaches write, in response to a determination that the candidate update does not have a state indicator indicative of an earlier time, the candidate update to the target data set (NOTE: BECKER [0035] discloses The sequence IDs may comprise monotonically increasing numbers, timestamps, or any other suitable data. BECKER Figures 13 and 15 show a stage table comprising candidate updates to records with a sequence ID in descending order (i.e. possible timestamps in descending order). BECKER [0047] discloses ensure that changes to specific records are processed in chronological order while allowing parallel processing of other changes. This seems to suggest that records would be updated in a chronological order based on the earliest timestamp to latest timestamp in order to prevent over writes. IF no other candidate update (e.g. a single Sequence ID) would be processed immediately.).
As to claims 13 and 26, BECKER teaches perform the one or more operations as a function of whether a data field in the staging table indicates that the corresponding record represents an insertion or an update comprises to write, for each record associated with an insertion, the record to the target data set (BECKER Figure 2, [0032], and [0034] shows a tabular representation of a portion of staging table 200. Staging table 200 is associated with a single database object. Each record represents a data change collected by staging system 110 for the associated database object. Each record of staging table 200 includes a key of the database object, one or more non-key fields, an operation type associated with the data change (e.g., Insert, Update, Delete), a sequence ID, and a package ID.).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Bourbonnais et al (US 20180113771 A1) - Provided are techniques for transaction consistency query support for replicated data from recovery log to external data stores. An external data store is populated with records using entries of a change data table. The change data table has entries for each transaction that has committed and is to be replicated, and each of the entries stores information for each log entry in a recovery log from a database management system. Each log entry identifies a transactional change of data and a transaction completion indicator of one of commit and abort. In response to receiving a query about a transaction of the transactions, a set of records are retrieved from the external data store for the transaction. From the set of records, records whose sequence identifier values are larger than a maximum transaction commit sequence identifier are removed. From the set of records, remaining records having transaction consistency are returned.
Holenstein et al (US 9904721 B1) - Methods and apparatus are provided for performing source-side merging of distributed transactions prior to replication, wherein a distributed transaction occurs at a plurality of nodes. A first node includes a database and an audit trail that stores database change events from the database of the first node. One or more other nodes each include a database and an audit trail that stores database change events from the database of the respective node. In use, a transaction is initiated which updates the database of the first node and the database at one or more of the other nodes. The database updates are captured in the audit trails of the respective nodes involved with the transaction. The first node receives and merges the database change events from the audit trails of each of the nodes involved in the transaction. The merged database change events are replicated via a replication engine only from the first node.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JARED M BIBBEE whose telephone number is (571)270-1054. The examiner can normally be reached Monday-Thursday 8AM-6PM.
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 MOFIZ can be reached at 5712724080. 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.
/JARED M BIBBEE/Primary Examiner, Art Unit 2161
Prosecution Insights