DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application is being examined under the pre-AIA first to invent provisions.
Response to Amendment
The amendment filed 10/17/2025 has been entered. Claims 1-5, 7-11, and 13-17 have been amended. Claims 1-18 remain pending in the application.
Response to Arguments
Claim Rejections - 35 U.S.C.§ 103
Regarding the newly amended claim 1, Applicant argues that “Plattner fails to disclose the amended features of claim 1. For example, claim 1 is amended to recite a method of providing a transaction manager operably coupled to a database "containing both row and column storage engines configured to provide at least one persistent data structure for each transaction of a plurality of each transactions.'' Plattner merely appears to disclose "a column-oriented data structure" and does not disclose a database including a "row... storage engine configured to provide at least one persistent data structure," since Plattner' s "column-oriented data processing component" appears to be limited to generating a column-oriented data structure and not a row-oriented data structure.
Examiner respectfully submits that Plattner discloses in Abstract (A system includes a relational database management system component and a column-oriented data processing component. The relational database system component stores database information in a row format. The column oriented data processing component stores the database information in a column format, Plattner, Abstract) , Fig. 9 and also column 2, lines 25-32 that (“Said computer program comprises a relational database management system component that stores said database information in a row format and a column-oriented data processing component that stores said database information in a column format.”). Therefore, Plattner discloses
a hybrid database system comprising both row-oriented relational database management system component (MaxDB)and a column-oriented data processing component (TREX) stores database information in row format and processes database update requests, which necessarily entails maintaining persistent data structures such as tables and indexes. Accordingly, Plattner discloses “a database containing both row and column storage engines configured to provide at least one persistent data structure”.
In response, Examiner relies on a new combination of references.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP §§ 706.02(l)(1) - 706.02(l)(3) for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1, 6-7, 12-13 and 18 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-3 of U.S. Patent No. 11921760 B2. Although the claims at issue are not identical, they are not patentably distinct from each other because they are obvious variants of each other.
The chart below shows the correspondence between the claims in the current application and the claims in the patent.
Current Application
U.S. Patent No.11921760 B2
1. A computer-implemented method comprising:
a database-containing both row and column storage engines configured to provide at least one persistent data structure for each transaction of a plurality of each transactions,
generating a transaction token that specifies data to be visible for a transaction on the database,
the transaction token including a transaction identifier for identifying committed transactions and uncommitted transactions, generating a first persistent data structure including a first index characterizing differences in transaction identifier data,
the first index storing the transaction identifier in each row and in a first designated column of the first persistent data structure,
responsive to determining the transaction identifier identifies a committed transaction,
and replacing the transaction identifier in the designated column of the first index with the computed identifier,
storing the computed identifier in a second designated column of a second persistent data structure including a second index characterizing historical transaction data,
and locking one or more records of the database using the transaction identifier and the computed identifier to execute the transaction;
and executing the plurality of transactions of the database with the transaction manager.
1. A method comprising:
2. storing the second identifier associated with one or more records in the database in every row and in the column of the second persistent data structure
generating a transaction token specifying that changes to a database by a first transaction are visible to a second transaction
generating an index as a first persistent data structure including a column of first identifiers, the transaction token including a first identifier for identifying committed transactions in the column of first identifiers,
2. storing the second identifier associated with one or more records in the database in every row and in the column of the second persistent data structure
the transaction token including a first identifier for identifying committed transactions in the column of first identifiers,
replacing the second identifier in the column of the second persistent data structure with a third identifier for an uncommitted transaction that becomes committed, the second persistent data structure characterizing changes to the first persistent data structure.
2. storing the second identifier associated with one or more records in the database in every row and in the column of the second persistent data structure.
4. The method of claim 1, wherein the first persistent data structure includes at least one of a main index or a history index.
1. locking a first record of the database;
2.wherein locking the first record further comprises storing the second identifier associated with one or more records in the database in every row and in the column of the second persistent data structure.
executing the second transaction using the transaction token
6. The computer-implemented method in accordance with claim 1, wherein the plurality of transactions of the database are distributed transactions.
3. The method in accordance with claim 1, wherein transactions of the database are distributed transactions.
Claims 7 and 13 correspond to claim 1, and are rejected accordingly.
Claims 12 and 18 correspond to claim 6, and are rejected accordingly.
Each patent claim in the above chart contains all the limitations recited in the corresponding claim of the instant application. In other words, each patent claim is either 1) narrower than or 2) substantially equivalent to the corresponding claim of the instant application. It would have been obvious to a person of ordinary skill in the data processing art at the time the invention was made to omit elements when the remaining elements perform as before. A person of ordinary skill could have arrived at the present claims by omitting the details of the patent claims. See In re Karlson (CCPA) 136 USPQ 184, decided January 16, 1963 (“Omission of element and its function in combination is obvious expedient if remaining elements perform same functions as before.”).
Claim 1 is provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over ” US11921760 B2” further in view of US 20040249838 (hereinafter Hinshaw)
Regarding claim 1, ‘US11921760 B2 ‘ discloses the features of claim 1 of the instant application as shown above,
‘US11921760 B2 does not explicitly teach:
providing a transaction manager operably coupled to a database for each transaction of a plurality of each transactions, the transaction manager configured to perform operations comprising: designating a last computed transaction with a computed identifier; using the transaction identifier and the computed identifier; with the transaction manager.
However Hinshaw discloses:
providing a transaction manager operably coupled to a database for each transaction of a plurality of each transactions, the transaction manager configured to perform operations comprising:
(Hinshaw, paragraph 10: transaction has an associated transaction identifier that uniquely identifies the transaction; an invisibility list that identifies other transactions whose effects are to be invisible to the transaction; and an isolation level that describes whether and when changes made by other transactions are to be visible to the transaction; paragraph 52, line 6- TIDs are assigned to transactions by the TxMgr (Transaction Manager); paragraph 57: The purpose of the invisibility list is to encapsulate exceptions to the basic rule or visibility – namely that a transaction can by default “see” the changes produced by other transactions with TIDs that are less than or equal to its own TID, but cannot "see" that changes produced by transactions with TIDs that are greater than its own TID)
designating a last computed transaction with a computed identifier,
(Hinshaw, [0165] the Invisibility List 203 of the new transaction is computed by finding all transactions in the TxJournal having TIDs 201 that are less than the TID of the selected transaction and Transaction End Times 208 greater than the specified "as-of" time. This ensures that the new transaction sees the changes made by all transactions that committed prior to the specified time and does not see changes made by any transactions that committed after the specified time.
using the transaction identifier and the computed identifier;
(Hinshaw, [0112] the TID 201 (FIG. 5) of the transaction that requested the record is compared to the CreatorTID value stored in the Creator TID field 600-1-2 (FIG. 6) in the record. If the CreatorTID value is ordered after the TID value, then the record was created by a transaction that did not commit before the requestor' s transaction started. The record is "too new", and is considered invisible at step 1603 …invisible records are flagged as being invisible, and are temporarily stored in memory, so that a concurrency control component of the transaction manager 103 can establish locks on the invisible record.)
with the transaction manager.
(Hinshaw, paragraph 52, line 6- TIDs are assigned to transactions by the TxMgr (Transaction Manager);
Therefore, it would have been obvious to a person of ordinary skill in the art at the time of invention was made to incorporate the teaching of “US11921760B2 “ with the teaching of Hinshaw to improve the availability of the system during recovery by allowing new user queries and transactions to proceed concurrently with recovery and also to improve the ability to efficiently support "as-of" queries and also eliminates the need to introduce delays and aborts for resolving read-write conflicts, (Hinshaw, [0011])
Claims 1, 6-7, 12-13 and 18 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-3 and 10 of U.S. Patent No. 11188577 B2. Although the claims at issue are not identical, they are not patentably distinct from each other because they are obvious variants of each other.
The chart below shows the correspondence between the claims in the current application and the claims in the patent.
Current Application
U.S. Patent No. 11188577 B2
A computer-implemented method comprising:
providing a transaction manager operably coupled to a database-containing both row and column storage engines configured to provide at least one persistent data structure for each transaction of a plurality of each transactions,
the transaction manager configured to perform operations comprising: generating a transaction token that specifies data to be visible for a transaction on the database
,the transaction token including a transaction identifier for identifying committed transactions and uncommitted transactions,
generating a first persistent data structure including a first index characterizing differences in transaction identifier data,
the first index storing the transaction identifier in each row and in a first designated column of the first persistent data structure,
responsive to determining the transaction identifier identifies a committed transaction, designating a last computed transaction with a computed identifier
and replacing the transaction identifier in the designated column of the first index with the computed identifier,
storing the computed identifier in a second designated column of a second persistent data structure including a second index characterizing historical transaction data,
and locking one or more records of the database using the transaction identifier and the computed identifier to execute the transaction; and executing the plurality of transactions of the database with the transaction manager.
1. A method comprising:
generating, by a transaction manager,
2. storing the TID associated with one or more records in the plurality of records in the database in every row of the at least one row and in the at least one column of the delta index.
1. generating, by a transaction manager,
a transaction token specifying that changes to a database by one or more of a plurality of transactions are visible to a transaction of the plurality of transactions associated with the transaction manager and that changes to the database by others of the plurality of transactions are not visible to the transaction associated with the transaction manager;
the transaction token including a maximum visible computed identifier for identifying a plurality of committed transactions and a plurality of uncommitted transactions,
generating an index of the plurality of records in the database as a persistent data structure, generating, by a transaction manager, a transaction token specifying that changes to a database by one or more of a plurality of transactions
2. storing the TID associated with one or more records in the plurality of records in the database in every row of the at least one row and in the at least one column of the delta index.
replacing the TID in the at least one column of the delta index with a computed identifier (CID) for an uncommitted transaction of the plurality of uncommitted transactions that become committed.
replacing the TID in the at least one column of the delta index with a computed identifier (CID) for an uncommitted transaction of the plurality of uncommitted transactions that become committed.
10. The method of claim 1, wherein the index includes at least one of a main index or a history index.
1. replacing the TID in the at least one column of the delta index with a computed identifier (CID) for an uncommitted transaction of the plurality of uncommitted transactions that become committed.
and performing record-level locking of a first record in a plurality of records of the database using the transaction token to execute the transaction by at least: generating an index of the plurality of records in the database as a persistent data structure, the index having a column for computed identifiers,… generating a delta index having a at least one row and at least one column including a transaction identifier (TID) in the at least one column,
by a transaction manager…execute the transaction
6. The computer-implemented method in accordance with claim 1, wherein the plurality of transactions of the database are distributed transactions.
3. The method in accordance with claim 1, wherein the transactions of the database are distributed transactions.
Claims 7 and 13 correspond to claim 1, and are rejected accordingly.
Claims 12 and 18 correspond to claim 6, and are rejected accordingly.
Each patent claim in the above chart contains all the limitations recited in the corresponding claim of the instant application. In other words, each patent claim is either 1) narrower than or 2) substantially equivalent to the corresponding claim of the instant application. It would have been obvious to a person of ordinary skill in the data processing art at the time the invention was made to omit elements when the remaining elements perform as before. A person of ordinary skill could have arrived at the present claims by omitting the details of the patent claims. See In re Karlson (CCPA) 136 USPQ 184, decided January 16, 1963 (“Omission of element and its function in combination is obvious expedient if remaining elements perform same functions as before.”).
Claim 1 is provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over ” US11188577B2” further in view of US 20040249838 (hereinafter Hinshaw)
Regarding claim 1, ” US11188577B2” discloses the features of claim 1 of the instant application as shown above,
” US11188577B2” does not explicitly teach:
designating a last computed transaction with a computed identifier,
However Hinshaw discloses:
designating a last computed transaction with a computed identifier,
(Hinshaw, [0165] the Invisibility List 203 of the new transaction is computed by finding all transactions in the TxJournal having TIDs 201 that are less than the TID of the selected transaction and Transaction End Times 208 greater than the specified "as-of" time. This ensures that the new transaction sees the changes made by all transactions that committed prior to the specified time and does not see changes made by any transactions that committed after the specified time.)
Therefore, it would have been obvious to a person of ordinary skill in the art at the time of invention was made to incorporate the teaching of “US11921760B2 “ with the teaching of Hinshaw to improve the availability of the system during recovery by allowing new user queries and transactions to proceed concurrently with recovery and also to improve the ability to efficiently support "as-of" queries and also eliminates the need to introduce delays and aborts for resolving read-write conflicts, (Hinshaw, [0011])
Claims 1, 6-7, 12-13 and 18 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-2 of U.S. Patent No. 10185737 B2. Although the claims at issue are not identical, they are not patentably distinct from each other because they are obvious variants of each other.
The chart below shows the correspondence between the claims in the current application and the claims in the patent.
Current Application
U.S. Patent No. 10185737 B2
1.A computer-implemented method comprising:
providing a transaction manager operably coupled to a database containing both row and column storage engines configured to provide at least one persistent data structure for each transaction of a plurality of each transactions,
the transaction manager configured to perform operations comprising: generating a transaction token that specifies data to be visible for a transaction on the database, the transaction token including a transaction identifier for identifying committed transactions and uncommitted transactions,
generating a first persistent data structure including a first index characterizing differences in transaction identifier data,
the first index storing the transaction identifier in each row and in a first designated column of the first persistent data structure, responsive to determining the transaction identifier identifies a committed transaction, designating a last computed transaction with a computed identifier
and replacing the transaction identifier in the designated column of the first index with the computed identifier,
storing the computed identifier in a second designated column of a second persistent data structure including a second index characterizing historical transaction data,
and locking one or more records of the database using the transaction identifier and the computed identifier to execute the transaction; and executing the plurality of transactions of the database with the ransaction manager.
1. A computer-implemented method for managing transactions of a database, the method comprising:
generating, by a transaction manager, a transaction token specifying that changes to the database by some of a plurality of transactions
in the database as a persistent data structure,…, storing a transaction identifier (TID)..in the database in every row and in a TID column of the delta index,
generating, by a transaction manager, a transaction token specifying that changes to the database by some of a plurality of transactions are visible to a transaction associated with the transaction manager and that changes to the database by others of the plurality of transactions are not visible to the transaction associated with the transaction manager,
the transaction token including a maximum visible computed identifier that identifies a plurality of committed transactions and a plurality of uncommitted transactions;
generating a main/history index of the plurality of records in the database as a persistent data structure, the main/history index having a computed identifier column, generating a delta index having rows and columns, storing a transaction identifier (TID) associated with one or more records in the plurality of records in the database in every row and in a TID column of the delta index, and for each uncommitted transaction of the first record that becomes committed replacing the TID associated with the first record in the TID column of the delta index with a computed identifier
replacing the TID associated with the first record in the TID column of the delta index with a computed identifier
and storing only the computed identifier in the main/history index persistent data structure.
performing record-level locking of a first record in a plurality of records of the database using the transaction token to execute the transaction by generating a main/history index of the plurality of records in the database as a persistent data structure, the main/history index having a computed identifier column,
6. The computer-implemented method in accordance with claim 1, wherein the plurality of transactions of the database are distributed transactions.
2. The computer-implemented method in accordance with claim 1, wherein the transactions of the database are distributed transactions.
Claims 7 and 13 correspond to claim 1, and are rejected accordingly.
Claims 12 and 18 correspond to claim 6, and are rejected accordingly.
Each patent claim in the above chart contains all the limitations recited in the corresponding claim of the instant application. In other words, each patent claim is either 1) narrower than or 2) substantially equivalent to the corresponding claim of the instant application. It would have been obvious to a person of ordinary skill in the data processing art at the time the invention was made to omit elements when the remaining elements perform as before. A person of ordinary skill could have arrived at the present claims by omitting the details of the patent claims. See In re Karlson (CCPA) 136 USPQ 184, decided January 16, 1963 (“Omission of element and its function in combination is obvious expedient if remaining elements perform same functions as before.”).
Claim 1 is provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over ” US10185737B2” further in view of in view of US 20040249838 (hereinafter Hinshaw)
Regarding claim 1, ” US10185737B2” discloses the features of claim 1 of the instant application as shown above,
” US10185737B2” does not explicitly teach:
designating a last computed transaction with a computed identifier,
However Hinshaw discloses:
designating a last computed transaction with a computed identifier,
(Hinshaw, [0165] the Invisibility List 203 of the new transaction is computed by finding all transactions in the TxJournal having TIDs 201 that are less than the TID of the selected transaction and Transaction End Times 208 greater than the specified "as-of" time. This ensures that the new transaction sees the changes made by all transactions that committed prior to the specified time and does not see changes made by any transactions that committed after the specified time.)
Therefore, it would have been obvious to a person of ordinary skill in the art at the time of invention was made to incorporate the teaching of “US11921760B2 “ with the teaching of Hinshaw to improve the availability of the system during recovery by allowing new user queries and transactions to proceed concurrently with recovery and also to improve the ability to efficiently support "as-of" queries and also eliminates the need to introduce delays and aborts for resolving read-write conflicts, (Hinshaw, [0011])
Claims 1, 6-7, 12-13 and 18 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-2 of U.S. Patent No. 9009182 B2. Although the claims at issue are not identical, they are not patentably distinct from each other because they are obvious variants of each other.
The chart below shows the correspondence between the claims in the current application and the claims in the patent.
Current Application
U.S. Patent No. 9009182 B2
A computer-implemented method comprising: providing a transaction manager operably coupled to a database-containing both row and column storage engines configured to provide at least one persistent data structure for each transaction of a plurality of each transactions, the transaction manager configured to perform operations comprising:
generating a transaction token that specifies data to be visible for a transaction on the database,
the transaction token including a transaction identifier for identifying committed transactions and uncommitted transactions,
generating a first persistent data structure including a first index characterizing differences in transaction identifier data, the first index storing the transaction identifier in each row and in a first designated column of the first persistent data structure, responsive to determining the transaction identifier identifies a committed transaction,
designating a last computed transaction with a computed identifier and replacing the transaction identifier in the designated column of the first index with the computed identifier,
storing the computed identifier in a second designated column of a second persistent data structure including a second index characterizing historical transaction data,
and locking one or more records of the database using the transaction identifier and the computed identifier to execute the transaction; and
executing the plurality of transactions of the database with the transaction manager.
1. A computer-implemented method for managing distributed transactions of a database, the method comprising:
providing a transaction manager for each of a plurality of transactions of the database, each transaction manager configured to perform functions comprising:
the database containing both row and column storage engines,
generating a transaction token specifying that changes to the database by some of the plurality of transactions are visible to a transaction associated with the transaction manager
the transaction token including a transaction identifier (TID) and a maximum visible computed identifier for identifying a plurality of committed transactions and a plurality of uncommitted transactions;
2. generating a main/history index as a persistent data structure
1.storing the TID in every row and in a TID column of the delta index.
identifying a plurality of committed transactions and a plurality of uncommitted transactions;
designating a last computed transaction with a computed identifier (CID);
2. using the TID and CID to execute the transaction further comprises: generating a main/history index as a persistent data structure, the main/history index having a CID column.
2. wherein performing record-level locking of records of the database using the TID and CID to execute the transaction further comprises:
executing the plurality of transactions of the database with each transaction manager.
6. The computer-implemented method in accordance with claim 1, wherein the plurality of transactions of the database are distributed transactions.
1. A computer-implemented method for managing distributed transactions of a database,
Claims 7 and 13 correspond to claim 1, and are rejected accordingly.
Claims 12 and 18 correspond to claim 6, and are rejected accordingly.
Each patent claim in the above chart contains all the limitations recited in the corresponding claim of the instant application. In other words, each patent claim is either 1) narrower than or 2) substantially equivalent to the corresponding claim of the instant application. It would have been obvious to a person of ordinary skill in the data processing art at the time the invention was made to omit elements when the remaining elements perform as before. A person of ordinary skill could have arrived at the present claims by omitting the details of the patent claims. See In re Karlson (CCPA) 136 USPQ 184, decided January 16, 1963 (“Omission of element and its function in combination is obvious expedient if remaining elements perform same functions as before.”).
Claim Rejections - 35 USC § 103
The following is a quotation of pre-AIA 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action:
(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the manner in which the invention was made.
Claims 1-18 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over US 2004/0249838 A1 (hereinafter Hinshaw) in view of US 9,626,421 B2 (hereinafter Plattner) in further view of US 2006/0167960 Al (hereinafter Lomet)
Regarding claim 1, Hinshaw discloses: A computer-implemented method comprising: providing a transaction manager operably coupled to a database configured to provide at least one persistent data structure for each transaction of a plurality of each transactions, (Hinshaw, [0042]controls a persistent storage device, for example, a disk 130. The distributed database is stored on one or more disks. Portions of the database can be copied from the disk 130 and stored in the memory 120. The database stores records in tables; abstract, A multi-version database system controls visibility of data during transaction processing. A transaction includes a transaction identifier that identifies the transaction and an invisibility list of transactions whose effects are invisible to the transaction; [0050] FIG. 3, a Transaction Manager (TxMgr) data structure 221 used by the TxMgr 103 shown in FIG. 1. The TxMgr data structure 221 contains a list 211 of transaction data structures, contiguous in memory.)
the transaction manager configured to perform operations comprising: generating a transaction token that specifies data to be visible for a transaction on the database, ( Hinshaw, paragraph 10: transaction has an associated transaction identifier that uniquely identifies the transaction; an invisibility list that identifies other transactions whose effects are to be invisible to the transaction; and an isolation level that describes whether and when changes made by other transactions are to be visible to the transaction; paragraph 52, line 6- TIDs are assigned to transactions by the TxMgr (Transaction Manager); paragraph 57: The purpose of the invisibility list is to encapsulate exceptions to the basic rule or visibility – namely that a transaction can by default “see” the changes produced by other transactions with TIDs that are less than or equal to its own TID, but cannot "see" that changes produced by transactions with TIDs that are greater than its own TID; abstract, A multi-version database system controls visibility of data during transaction processing. A transaction includes a transaction
identifier that identifies the transaction and an invisibility list of transactions whose effects are invisible to the transaction. Changes made by other transactions are visible
to the transaction based on the isolation level of the transaction; [0046] To allow concurrent access to such a database in a multi user environment, records are tagged with Transaction Identifiers (TIDs) that indicate by whom a record was created or marked obsolete)
the transaction token including a transaction identifier for identifying committed transactions and uncommitted transactions, (Hinshaw, See paragraph 56: A transaction also contains state information, including an indication of whether the transaction is active, committed or aborted, paragraph 113: TID value stored in the Creator TID field of the record is known to be ordered at the same time or before the requesting transaction’s TID. Sometimes this will mean that the record was created by a transaction that committed before the requesting transaction started … It is also possible that the record was created by a transaction that has not yet committed. These two cases are differentiated by the Invisibility List of the requesting transaction, paragraphs 114 – 11; [0165] the Invisibility List 203 of the new transaction is computed by finding all transactions in the TxJournal having TIDs 201 that are less than the TID of the selected transaction and Transaction End Times 208 greater than the specified "as-of" time;)
generating a first persistent data structure including a first index characterizing differences in transaction identifier data, the first index storing the transaction identifier in each row and in a first designated column of the first persistent data structure, (Hinshaw, Figures 5 – 7; [0042] The database stores records in tables. Each record stored on the disk has an associated logical address used to locate the record on the disk; [0071] Each record includes the three system control fields (Record ID 600-n-1, CreatorTID 600-n-2, and Deleter TID 600-n-3; [0113] These two cases are differentiated by the Invisibility List 203 (FIG. 5) of the requesting transaction. If the TID value stored in the Creator TID field 600-1-2 of the record is also stored in the requesting transaction's Invisibility List 203, then the record was created by an active transaction, one that started, but has not committed before the requesting transaction started.)
responsive to determining the transaction identifier identifies a committed transaction, (Hinshaw, [0056] A transaction 200 also contains state information 202, including an indication of whether the transaction is active, committed or aborted… When the TxMgr 103 commits a transaction, the state of the transaction 202 is committed; [0125] As the TxMgr 103 commits transactions,...If the TID of the committed transaction is greater than the TID of the Read Committed isolation mode transaction, the TxMgr 103 adds the TID of the committed transaction to the visibility-list portion of the Read Committed isolation mode transaction's Invisibility List 203.)
designating a last computed transaction with a computed identifier (Hinshaw, [0058] The IL 203 contains a vector of TIDs 206; [0165] the Invisibility List 203 of the new transaction is computed by finding all transactions in the TxJournal having TIDs 201 that are less than the TID of the selected transaction and Transaction End Times 208 greater than the specified "as-of" time. This ensures that the new transaction sees the changes made by all transactions that committed prior to the specified time and does not see changes made by any transactions that committed after the specified time; Figure 3 and paragraph 50: Individual transactions can be referenced by their index within this [Transaction Manager data structure])… This information includes the …, the index of the oldest transaction in the list 211 and the index of the newest transaction in the list 211; [0058] The IL 203 contains a vector of TIDs 206; [0059]information is organized as rows within tables, so that the low water mark 209 and the high water mark 210 are kept on a per-table basis. The low water mark 209 for a given table and a given transaction is the oldest record version either created or deleted in the given table by the given transaction. The high water mark 210 for a given table and a given transaction is the most recent record version either created or deleted in the given table by the given transaction. The low water marks 209 and the high water marks 210 are used to reduce the amount of time required to perform rollback and recovery operations. Instead of scanning an entire table, these operations can start at the low water mark 209 and end at the high water mark 210.)
storing the computed identifier in a second designated column of a second persistent data structure including a second index characterizing historical transaction data, (Hinshaw, [0058] The IL 203 contains a vector of TIDs 206; [0050] Individual transactions can be referenced by their index within this list 211. The TxMgr data structure 221 contains other information 212 useful for transaction processing. This information includes the current number of transactions in the list 211, the size of the list 211, the index of the oldest transaction in the list 211 and the index of the newest transaction in the list 211; [0165] the Invisibility List 203 of the new transaction is computed)
and locking one or more records of the database using the transaction identifier and the computed identifier to execute the transaction; (Hinshaw paragraphs 0111, The Repeatable read isolation level guarantees that a transaction will never see two different versions of the same information. If a transaction "sees" a record in a given state once, then subsequent queries continue to "see" the record in the same state, regardless of whether other transactions committed modifications to the record in the interim. The Serializable isolation level, the level with the highest safety, makes it appear that each transaction is the only transaction executing on the system. While transactions may access and manipulate information in the database concurrently in real time, the transactions behave as if they executed in serial order, with exclusive access to the database; [0165] the Invisibility List 203 of the new transaction is computed by finding all transactions in the TxJournal having TIDs 201 that are less than the TID of the selected transaction and Transaction End Times 208 greater than the specified "as-of" time. This ensures that the new transaction sees the changes made by all transactions that committed prior to the specified time and does not see changes made by any transactions that committed after the specified time; [0112] the TID 201 (FIG. 5) of the transaction that requested the record is compared to the CreatorTID value stored in the Creator TID field 600-1-2 (FIG. 6) in the record. If the CreatorTID value is ordered after the TID value, then the record was created by a transaction that did not commit before the requestor' s transaction started. The record is "too new", and is considered invisible at step 1603 …invisible records are flagged as being invisible, and are temporarily stored in memory, so that a concurrency control component of the transaction manager 103 can establish locks on the invisible record.)
and executing the plurality of transactions of the database with the transaction manager. (Hinshaw, [0046]; [0037]A distributed database consists of many nodes, each of which may have different capabilities. A Data Base Host (DB-Host) 100 node is capable of originating new transactions. These transactions can execute queries, which may acquire resources that reside locally to the DB-Host 100 or remotely on another node. The DB-Host 100 comprises three software components, a Query Execution Manager 101, a Transaction Manager 103, and a Resource Usage Manager 102)
However Hinshaw does not clearly disclose:
a database containing both row and column storage engines configured to provide at least one persistent data structure for each transaction of a plurality of each transactions; and replacing the transaction identifier in the designated column of the first index with the computed identifier,
However Plattner discloses:
a database containing both row and column storage engines configured to provide at least one persistent data structure for each transaction of a plurality of each transactions (Plattner, column 2, line 28- a relational database management system component that stores said database information in a row format and a column-oriented data processing component that stores said database information in a column format; column 4, line 19- The present invention proposes an architecture, which is based on the utilization of main memory technology in combination with a column-oriented data structure)
At the time the invention was made, it would have been obvious to a person of ordinary skill in the data processing art to incorporate teaching of Plattner into Hinshaw’s overall method, for the benefit of providing short response times for reporting directly on transactional data and to use a data structure that provides fast read access
as well as efficient write access, (Plattner, column 6, lines 40-45) and also to allow
fast data retrieval while concurrently updating its data set, (Plattner, column 9, lines 51-52)
However Hinshaw in view of Plattner does not clearly disclose:
and replacing the transaction identifier in the designated column of the first index with the computed identifier,
However Lomet discloses:
and replacing the transaction identifier in the designated column of the first index with the computed identifier, (Lomet teaches at least in paragraph 6 lines 9 – 11 and paragraph 123 replacing a TID with a “transaction time assigned to the transaction” (analogous to the claimed “computed identifier”) after commit. After the transaction is committed, the transaction time would replace the transaction ID and be the only data stored in association with the committed transaction;[0007] To make this timestamping possible, the mapping of transaction ID to timestamp must be made persistent; [0056] There needs to be a way of stably recording the mapping between transaction ID (which is placed in the record at update time) and that transaction's timestamp. This is usually done by maintaining some form of persistent <transaction ID: timestamp> mapping; )
At the time the invention was made, it would have been obvious to a person of ordinary skill in the data processing art to incorporate Lomet’s concept into Hinshaw in view of Plattner’s overall method, for the benefit of providing a more efficient data transaction environment by keeping the records and associated data up-to-date.
Claims 7 and 13 correspond to claim 1, and are rejected accordingly.
Regarding claim 2, Hinshaw in view of Plattner in view of Lomet discloses all of the features with respect to claim 1 as outlined above. Claim 2 further recites:
searching the second index with the computed identifier to determine the transaction identifier. (Hinshaw, [0079], the TxMgr 103 determines for every transaction Ti on this list of transactions 211 whether the transaction exits. If so, at step 805 the TxMgr 103 checks if the TID of the transaction Ti is less than the TID of the new transaction.)
Claims 8 and 14 correspond to claim 2, and are rejected accordingly.
Regarding claim 3, Hinshaw in view of Plattner in view of Lomet discloses all of the features with respect to claim 1 as outlined above. Claim 3 further recites: wherein the transaction token includes a first parameter characterizing the transaction as at least one of a read-only transaction or a write transaction. (Hinshaw, [0124],e.g. a Read Committed transaction; [0099]-[0105]; [0112]-[0117], e.g. [0099] The record 110-2… is modified by deleting record 110-2 and creating record 110-5. For example, to change the numeric value stored in the numeric value field 110-2-6 of record 110-6 from 40 to 75, "5000" (the TID of the hypothetical transaction performing the modification) is stored in the Deleter TID field 110-2-3. Then a new version of the record is created; [0111] The Repeatable read isolation level guarantees that a transaction will never see two different versions of the same information. If a transaction "sees" a record in a given state once, then subsequent queries continue to "see" the record in the same state; [0116] Sometimes that will mean that the record was deleted by a transaction that committed before the requesting transaction started… It is also possible that the record was deleted by a transaction that has not yet committed;)
Claims 9 and 15 correspond to claim 3, and are rejected accordingly.
Regarding claim 4, Hinshaw in view of Plattner in view of Lomet discloses all of the features with respect to claim 1 as outlined above. Claim 4 further recites: wherein the transaction token includes a second parameter characterizing the transaction as a closed transaction such that the transaction is committed or rolled back, (Hinshaw, [0101]- [0103], e.g. [0101] If the value stored in the next record's Creator TID field 600-1-2 is the same as the TID 201 of the aborting transaction, then the record was created by the aborting transaction. In this case, at step 1503, the record's Deleter TID field 600-1-3 is set to the reserved Aborted TID value (corresponding to rolled back (closed transaction); [0112] invisible records are flagged as being invisible, and are temporarily stored in memory,)
the second parameter configured to cause to expunge corresponding transaction data. (Hinshaw, [0117] At step 1610, the value of the Deleter TID field 600-1-3 of the record is compared against each of the values stored in the requesting transaction's Invisibility List 203. If the TID stored in the record's Deleter TID field 600-1-3 is found on the requesting transaction's Invisibility List 203 then the record deletion has not yet committed. The record is returned as visible at step 1612. If the TID stored in the record's Deleter TID field 600-1-3 is not found on the requesting transaction's Invisibility List 203, then the record deletion has committed. At step 1611, the record is flagged as being invisible)
However Hinshaw does not clearly disclose:
the row and column storage engines
However Plattner discloses:
the row and column storage engines (Plattner, column 2, line 28- a relational database management system component that stores said database information in a row format and a column-oriented data processing component that stores said database information in a column format; column 4, line 19- The present invention proposes an architecture, which is based on the utilization of main memory technology in combination with a column-oriented data structure)
At the time the invention was made, it would have been obvious to a person of ordinary skill in the data processing art to incorporate teaching of Plattner into Hinshaw’s overall method, for the benefit of providing short response times for reporting directly on transactional data and to use a data structure that provides fast read access as well as efficient write access, (Plattner, column 6, lines 40-45) and also to allow fast data retrieval while concurrently updating its data set, (Plattner, column 9, lines 51-52)
Claims 10 and 16 correspond to claim 4, and are rejected accordingly.
Regarding claim 5, Hinshaw in view of Plattner in view of Lomet discloses all of the features with respect to claim 1 as outlined above. Claim 5 further recites: wherein the transaction token includes a third parameter characterizing the computed identifier as that of a last committed transaction, the third parameter configured to query the second index. (Hinshaw, [0147] the ability of the TxMgr 103component… the ability to read the latest committed data; [0147]-[0149]; [0162] With Read Committed isolation, it is sufficient for the given transaction to see all transactions that had committed (and only such transactions) as of the specified time; [0163] performing an "as-of' query with read committed isolation. At step 2000, the TxMgr 103 consults a transaction journal (TxJournal), to find transactions that started on or after the specified "as-of" time, by comparing the transactions' Transaction Start Time 207 field to the specified "as-of' time. From this subset, at step 2001, the TxMgrl03 selects the transaction with a Transaction Start Time 208 that is closest to the specified "as-of' time.)
Claims 11 and 17 correspond to claim 5, and are rejected accordingly.
Regarding claim 6, Hinshaw in view of Plattner in view of Lomet discloses all of the features with respect to claim 1 as outlined above. Claim 6 further recites: wherein the plurality of transactions of the database are distributed transactions.
(Hinshaw, [0046]; [0037]A distributed database consists of many nodes, each of which may have different capabilities. A Data Base Host (DB-Host) 100 node is capable of originating new transactions. These transactions can execute queries, which may acquire resources that reside locally to the DB-Host 100 or remotely on another node. The DB-Host 100 comprises three software components, a Query Execution Manager 101, a Transaction Manager 103, and a Resource Usage Manager 102.)
Claims 12 and 18 correspond to claim 6, and are rejected accordingly.
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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Faezeh Forouharnejad whose telephone number is (571)270-7416. The examiner can normally be reached on generally Monday through Friday.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Shah Sanjiv can be reached on (571)272-4098. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center and Private PAIR to authorized users only. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free)
/F.F. /
Examiner, Art Unit 2166
/SANJIV SHAH/Supervisory Patent Examiner, Art Unit 2166