DETAILED ACTION
This communication is responsive to the instant application filed on 11/12/2024.
Claims 1, 20-21 are independent claims.
Claims 1-39 are pending in this application and are presented for examination on merits.
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 .
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 11/12/2024, 12/04/2024, 03/31/2025, 05/01/2025, 05/21/2025, 10/21/2025, and 07/02/2026 have been considered and recorded. The submission is in compliance with the provisions of 37 CFR §1.97. See form PTO-1449 singed and attached hereto.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-39 are rejected under 35 U.S.C. 112, second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which applicant regards as the invention.
Regarding claim 1, the phrase "determining if the transaction can commit,…" in line 6 renders the claim indefinite because it is unclear whether the limitation(s) following the phrase are under condition "if... not...". Claim 20 (line 9) and claim 21 (line 7) are rejected by the same reasons as claim 1, respectively. Appropriate correction is required.
In addition, claim 1 recites the optional word “can” in lines 6 and line 9 renders the claim indefinite because it is unclear whether the limitation(s) following the optional language of “cannot” being occur. Appropriate clarification/correction is required. Similar rejection is applied to claim 20 and claim 21 as well.
Claims 2-19 and 22-39 are also rejected because of dependency to independent claims 1 and 21.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-39 are rejected under 35 U.S.C. 101 because the claims are directed to an abstract idea.
Regarding claim 1, the claim recites language of:
“during a validation of a transaction, identifying conditional conflicts and their corresponding conflicting transactions, wherein the corresponding conflicting transactions are reading-transactions conflicting with the transaction;
for each conditional conflict, determining if the transaction can commit, with respect to the conditional conflict, before the corresponding conflicting transaction;
placing an active protective declaration, issued by the transaction and sourced by a corresponding conflicting transaction, when the transaction can commit, with respect to the conditional conflict, before the corresponding conflicting transaction;
marking the transaction as dependent on the corresponding conflicting transaction when the transaction cannot commit before the corresponding conflicting transaction; and
when validation conditions are met, placing a commit pause on data cells modified by the transaction, thereby allowing the transaction to commit before any corresponding conflicting transactions.”
a/ Analysis under Step 2A, Prong I:
Regarding claim 1, the limitations/steps of “during a validation of a transaction, identifying conditional conflicts and their corresponding conflicting transactions, wherein the corresponding conflicting transactions are reading-transactions conflicting with the transaction;” and “for each conditional conflict, determining if the transaction can commit, with respect to the conditional conflict, before the corresponding conflicting transaction”, as drafted, are mental processes that, under its broadest reasonable interpretation, cover performance of the limitations in the concepts that performed in the human mind (e.g., an observation, evaluation, judgment, option, etc.) but for the recitation of at least generic computer’s component(s) in “a non-distributed database system”. Thus, if a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mental human mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas (see MPEP 2106.04(a)(2), part III).
**** Similar analysis to independent claims 20 and 21, respectively.
b/ Analysis under Step 2A, Prong II:
The remaining limitations in claims 1 and 20-21 do not appear to be tied to a practical application and also do not amount to significantly more than the abstract idea. Claim 1 recites an additional element, e.g., “a non-distributed database system”, claims 20-21 recites “one or more processors”, which are known as generic computing components using as tools to perform the computing instructions of the above indicated steps of “identify …”, “determine…”, such that it amounts no more than mere instructions to apply the exception using the generic computing components (see Mayo, 566 U.S. AT 84). Next, the additional steps of “placing an active protective declaration…”, “making the transaction…”, and “placing a commit pause…” are insignificant extra solution activities under step 2A prong II because these steps do not specify of how to data processing so that it does not impose any meaningful limits on practicing the abstract idea. See MPEP 2106.04(a)-(c), (e)-(h).
c/ Analysis under Step 2B:
Furthermore, independent claims 1, and 20-21 do not include additional elements/limitations beyond the judicial exception that, alone or in combination, are not “well-understood, routine, conventional” (see MPEP 2106.05(d)). As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of using “one or more processor”, “a non-distributed database system”, “a non-transitory computer-readable medium” as tools for performing the above steps of identifying, determining, placing, making, placing amount to no more than mere instructions/functions to apply the exception using the highly generic computing components that are well-understood, routine, conventional amount to no more than implementing the abstract idea with a computerized system. Next, the additional step of ““placing an active protective declaration…”, “making the transaction…”, and “placing a commit pause…” represent an insignificant extra solution activity because this additional step including in the claims as the computing functions to apply the exception using a generic computer components that are well-understood, routine, conventional activity to a skill artisan in the relevant technical field of gathering data via network, see Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362.
For the at least above reasons, independent claims 1, and 20-21 are not patented eligibility.
Claims 2-19 and 22-39 depend on independent claims 1 and 21 and include all the limitations of claims 1 and 21. Therefore, claims 2-19 and 22-39 recite the limitations that may direct to abstract idea.
Regarding dependent claim 2, the claim recites further additional limitation of “identifying non-conditional conflicts and their related conflicting transactions”, as drafted, is mental processing that falls within the “Mental Processes”. For this reason, the additional element/limitation in the claim is considered both individually and as an ordered combination does not amount to significantly more than the abstract idea.
Regarding dependent claim 3, the claim recites further additional limitations of “wherein the validation conditions include: the transaction is neither conditionally dependent nor non-conditionally dependent on any conflicting transactions; all non-conditional conflicts are processed; all conditional conflicts are processed; the transaction does not have any evaluation-pending validations or evaluation-deferred validations; and any active protective declarations issued by the transaction are not in use by a challenging process” that do not appear to be tied to a practical application. These additional elements represent insignificant extra solution activity. The limitations are provided further the claim language in definition of the validation conditions to the transaction, all non-conditional conflicts, and the active protective declarations that do not amount to more than generally linking the use of a judicial exception to a particular technological environment or field of use. For this reason, the additional element/limitation in the claim is considered both individually and as an ordered combination does not amount to significantly more than the abstract idea
Regarding dependent claims 4-7, the claims recite further additional limitations of “waiting until the validation conditions are met”, “processing all non-conditional conflicts”, “for each non-conditional conflict, marking the transaction as dependent on the corresponding conflicting transaction”, and “removing any protective declarations issued by the transaction that were sourced by the corresponding conflicting transaction”, and “processing all conditional conflicts” that do not appear to be tied to a practical application and do not amount to significantly more than the abstract idea. These additional elements/limitations represent insignificant extra solution activity. These additional limitations generally describes the further validation conditions and the non-conditional conflicts of the transactions that is well-understood, routine, conventional activity to a skill artisan in the relevant technical field of data gathering via network, see Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362. Thus, these additional limitation and/or element are considered both individually and as an ordered combination do not amount to significantly more than the abstract idea.
Regarding dependent claims 8-9, the claims recite further additional limitations of “checking if an epsilon checking procedure can be performed; when the epsilon checking procedure can be performed: performing an epsilon checking procedure on the transaction to determine if an epsilon principle is satisfied, wherein the epsilon checking procedure evaluates a value of a predicate on a data-cell set immediately before and immediately after committing the transaction; issuing the active protective declaration for a specific predicate of a data-cell set, when the epsilon principle is satisfied; and issuing an inactive conditionally-dependent protective declaration for a specific predicate on a specific data-cell set, when the epsilon principle is not satisfied”, and “when the epsilon checking procedure cannot be performed: issuing an inactive evaluation-pending protective declaration, sourced by the conflicting transaction, wherein the inactive evaluation-pending protective declaration is issued for a specific predicate on a specific data-cell-set”, which do not appear to be tied to a practical application and also do not amount to significantly more than the judicial exception as abstract idea (see MPEP §2106.05 (a)-(c), (e)-(h)). Furthermore, these additional elements/limitations represent insignificant extra solution activity. These additional limitations generally describes the further procedure of checking data, e.g., epsilon, can be or cannot be performed, then issuing a protective declaration being satisfied or not satisfied that is well-understood, routine, conventional activity to a skill artisan in the relevant technical field of data gathering via network, see Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362. Therefore, the additional limitations/elements in the indicated dependent claims are considered both individually and as an ordered combination do not amount to significantly more than the abstract idea.
Regarding dependent claims 10-11, the claims recite further additional limitations of “committing the transaction immediately after placing the commit pause on data cells modified by the transaction”, and “releasing the commit pause; removing non-conditional dependencies of other transactions on the transaction; removing all the active protective declarations issued by the transaction; and removing all protective declarations sourced by the transaction”, which do not appear to be tied to a practical application and also do not amount to significantly more than the judicial exception as abstract idea (see MPEP §2106.05(a)-(c), (e)-(h)). These additional limitations represent insignificant extra solution activity that are well-understood, routine, conventional activity to a skill artisan in the relevant technical field of gathering data, see Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362. For these reasons, the additional limitations/elements in the indicated dependent claims are considered both individually and as an ordered combination do not amount to significantly more than the abstract idea.
Regarding dependent claim 12, the claim recites further additional limitations of
“wherein the corresponding conflicting transaction is a reading-transaction, and wherein reading data cells by the reading-transaction further comprises: creating a read vector entry in a read-vector of the reading-transaction; scanning write vectors of other pending transactions to identify conflicting writing-transactions; for each identified conflicting writing-transactions, sending a validation message to the conflicting writing-transaction; and reading the data cells by the reading-transaction” which do not appear to be tied to a practical application and also do not amount to significantly more than the judicial exception as abstract idea (see MPEP §2106.05(a)-(c), (e)-(h)). These additional limitations represent insignificant extra solution activity that are well-understood, routine, conventional activity to a skill artisan in the relevant technical field of gathering and transmitting data via network, see Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362. For these reasons, the additional limitations/elements in the indicated dependent claims are considered both individually and as an ordered combination do not amount to significantly more than the abstract idea.
Regarding dependent claims 13-17, the claims recite further additional limitations of a conditional conflict, and its state to be “is determined…”, as drafted, are mental processes that, under its broadest reasonable interpretation, covers performance of the limitation in the mental concepts performed in the mind (e.g., an observation, evaluation, judgment, option, etc.) but for the recitation of generic computer’s component(s). If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mental mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. See MPEP 2106.04(a)(2), part III. For these reasons, the additional limitations/elements in the indicated dependent claims are considered both individually and as an ordered combination do not amount to significantly more than the abstract idea.
Regarding dependent claims 18-19, the claims recite further additional limitations of “wherein tasks in the transaction are executed in an optimistic manner, and wherein the transaction is validated in a pessimistic manner”, and “resolving pseudo-deadlocks by applying a forced challenging procedure”, which do not appear to be tied to a practical application and also do not amount to significantly more than the judicial exception as abstract idea. The additional elements/limitations are mere “apply it” (or an equivalent), see Alice Corp. v. CLS Bank, 573 U.S. 208, 221, 110 USPQ2d 1976, 1982-83 (2014); Mayo Collaborative Servs. V. Prometheus Labs. Inc., 566 U.S. 66, 72, 101 USPQ2d 1961, 1965; and Alice Corp., 573 U.S. at 223, 110 USPQ2d at 1983, (see MPEP 2106.05(f)) that do not amount to more than generally linking the use of a judicial exception to a particular technological environment or field of use. For these reasons, the additional elements in the indicated dependent claims are considered both individually and as an ordered combination do not amount to significantly more than the abstract idea.
Regarding dependent claims 22-39, the claims are essentially the same or at least similar recitation as claims 2-19 except that they set forth the claimed invention as a system rather than a method respectively and correspondingly, therefore are rejected under the same reasons set forth in rejections of dependent claims 2-19.
For at least above reasons, claims 1-39 are not drawn to eligible subject matter as they are directed to an abstract idea.
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.
Claims 1-2, 4-5, 7, 10-11, 13-18, 20-22, 24-25, 27, 30-31, 33-38 are rejected under 35 U.S.C. 103 as being unpatentable over Wang, US Patent No. 5,263,155 (hereinafter as “Wang”) in view of Murthy et. al., Pub. No. 2022/0067029 A1 (hereinafter as “Murthy”), and further in view of Mohammad Dashti et al., “Repairing Conflicts among MVCC Transactions”, published on 3/02/2026 (hereinafter as “Dashti”).
Regarding claim 1, Wang teaches: a method for managing execution of database transactions in a non-distributed database system (Fig. 1 is shown a non-distributed database system, Fig. 6 at element 114 - DBMS), comprising:
during a validation of a transaction, identifying conditional conflicts and their corresponding conflicting transactions (Fig. 4 via conflict table indicates conditional conflicts; Fig. 10, element 916 via validate transaction, col. 1, lines 49-56), wherein the corresponding conflicting transactions are reading-transactions conflicting with the transaction (Fig. 4 via “READ” transaction in conflict table);
for each conditional conflict, determining if the transaction can commit, with respect to the conditional conflict, before the corresponding conflicting transaction (Fig. 6, element 410; and col. 2, lines 3-5 via the “committed state”); and
when validation conditions are met, placing a commit pause on data cells modified by the transaction, thereby allowing the transaction to commit before any corresponding conflicting transactions (Fig. 6, element 416 and 420 via “Wait”=pause).
Wang does not explicitly teach: “placing an active protective declaration, issued by the transaction and sourced by a corresponding conflicting transaction, when the transaction can commit, with respect to the conditional conflict, before the corresponding conflicting transaction; marking the transaction as dependent on the corresponding conflicting transaction when the transaction cannot commit before the corresponding conflicting transaction.”
In the same field of endeavor (i.e., data processing), Murthy teaches:
placing an active protective declaration (Fig. 4A is shown the transaction 400 with the statement 405 as a declarative query language which is interpreted as the active protective declaration), issued by the transaction and sourced by a corresponding conflicting transaction, when the transaction can commit, with respect to the conditional conflict, before the corresponding conflicting transaction (Fig. 2, elements 200; Fig. 4A, statement lines 400 and 405, see further in pars. [0002-3] e.g., “non-distributed databases represent transactions using a declarative query language (e.g., SQL)”, [0006], [0011], [0016] and [0037]).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to combine the teachings of the cited references because the teachings of Murthy would have provided Wang with the active protective declaration for allowing a skill artisan in motivation to perform execution statements of the transactions when transaction is perform a committing process (Murthy: Abstract; and pars. [0002-3] and [0006-11, 16, and 37]).
Wang and Murthy do not explicitly teach: “marking the transaction as dependent on the corresponding conflicting transaction when the transaction cannot commit before the corresponding conflicting transaction.”
In the same field of endeavor (i.e., data processing), Dashti teaches:
marking the transaction as dependent on the corresponding conflicting transaction when the transaction cannot commit before the corresponding conflicting transaction (page 1, col. 2 at first and second paragraphs, e.g., “identifying the dependencies among different operations”/transaction(s); and page 3, col. 2, Fig. 2 and Definition 3.1).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to combine the teachings of the cited references because the teachings of Dashti would have provided Wang and Murthy with the marked transaction as dependent on the corresponding conflicting transaction when the transaction cannot commit before the corresponding conflicting transaction for allowing a skill artisan in motivation to perform the identifying and repairing conflicts among the proposed optimistic and pessimistic transactions (Dashti: Abstract; and page 1 at Introduction section).
Regarding claim 2, Dashti teaches: “identifying non-conditional conflicts and their related conflicting transactions” (page 1, col. 1 at third paragraph and col. 2).
Regarding claim 4, Wang, and Dashti, in combination, teach: “waiting until the validation conditions are met” (Wang: Fig. 6, elements 416 and 420 via “Wait” queue for commit=validation; and Dashti: page 6, col. 1 at last paragraph, e.g., “… the validation process stops after finding the first invalid predicate…”).
Regarding claim 5, Wang and Dashti, in combination, teach: “processing all non-conditional conflicts” (Wang: Fig. 6 at element 410; and Dashti: page 6 at col. 1 via “not abort” means no conditional conflicts).
Regarding claim 7, Wang and Dashti, in combination, teach: “processing all conditional conflicts” (Wang: see Fig. 8 via optimistic and pessimistic conditional conflicts occurs via checking conflict exist or not at elements 704 and 712; and Dashti: page 1, col. 2, last paragraph via “repair conflicting transactions”).
Regarding claim 10, Wang teaches: committing the transaction immediately after placing the commit pause on data cells modified by the transaction (Figs. 4-5 disclosed data cells; and Fig. 8, element 707 at waiting=pause until released deadlock; and Fig. 10, element 904, e.g., “release all locks and commit update; col. 2, lines 41-51: “enable pessimistic transactions to wait for locks on objects to which they need access, while allowing optimistic transactions to forge ahead without waiting for locks to release…”).
Regarding claim 11, Wang teaches:
releasing the commit pause (Fig. 8, elements 706-707, e.g., releasing the wait queue equivalent to the releasing the commit pause);
removing non-conditional dependencies of other transactions on the transaction (Figs. 9-10, elements 800, 802, 904, and 1002);
removing all the active protective declarations issued by the transaction (Fig. 9, element 800 – “Release a Lock”, and element 802 – “Remove Lock from the lock table” state such that the unlock/remove the protective declaration to continue commit/valid update transaction; Fig. 10, element 904; col. 2, lines 12-15: “At commit time, the intentions list of the transaction is incorporated into the committed state of the database and all associated locks held by the transaction are released” wherein the release lock is interpreted as remove the active protective declaration for commit the transaction); and
removing all protective declarations sourced by the transaction (col. 7, lines 8-10 via “the transaction is removed from wait queue 420; and col. 7, lines 20-24: “FIG. 9 shows the method by which DBMS 114 releases a lock. The procedure commences at entry point 800. It then continues to step 802 in which, using lock table manager 414, it removes the lock table entry for the lock being released” wherein the lock table is interpreted as sourced by transaction, and further in lines 25-30: “In step 804, DBMS 114 calls upon lock table manager 414 to obtain information from lock table 418. It then uses this information to determine if there is in lock table 418, any lock if the same type as the lock being released. If such is the case, DBMS 114 can return to the calling program, in step 810.”).
Regarding claim 13, Dashti teaches the conditional conflict in the states of “optimistic” and “pessimistic” types (see page 1, col. 1, section 1 “Introduction” in paragraph 1, and col. 2, paragraph 1; and page 2, col. 1, section 2: “write-write conflicts in MV3C… when a write-write conflict is detected”) such that Dashti teaches : a conditional conflict is determined (page 2, col. 1, section 2: “write-write conflicts in MV3C… when a write-write conflict is detected”) based, in part, on at least one predicate in the corresponding conflicting transaction (page 3, col. 1, second paragraph: “conflicting transactions”; and page 3, col. 1, section 3 at second paragraph: disclosed “The failure possibility stems from having a predicate in that fragment of the program, which might not pass the validation phase… have an invalid predicate inside them are rolled back and re-executed”; and further in page 5, col. 1 at Fig. 4 for conditional conflict base on the predicate execution between the validation and commit stages).
Regarding claim 18, Wang and Dashti, in combination, teach: wherein tasks in the transaction are executed in an optimistic manner, and wherein the transaction is validated in a pessimistic manner (Wang: Abstract: “concurrency control in a system having both pessimistic and optimistic transactions…”; and Dashti: page 1, col. 1 in third paragraph, e.g., “an optimistic MVCC algorithm”; and col. 2 at second paragraph, e.g., “proposed pessimistic algorithms”).
Claims 20-22, 24-25, 27, 30-31, 33, and 38 are rejected in the analysis of above claims 1-2, 4-5, 7, 10-11, 13, and 18; and therefore, the claims are rejected on that basis.
Claims 3, 19, 23, and 39 are rejected under 35 U.S.C. 103 as being unpatentable over Wang, Murthy, and Dashti, and further in view of Loring et al., US Pub. No. 2025/0103572 A1 (hereinafter as “Loring”).
Regarding claim 3, the claim is rejected by the same reasons set forth above to claims 1-2. Furthermore, Wang, Murthy and Dashti, in combination, teach: wherein the validation conditions include:
the transaction is neither conditionally dependent nor non-conditionally dependent on any conflicting transactions (Dashti: pages 1 at col. 2 via identifying dependencies among different operations/transactions); all non-conditional conflicts are processed; all conditional conflicts are processed; the transaction does not have any evaluation-pending validations or evaluation-deferred validations (Dashti: page 1, col. 1 at third paragraph and col. 2).
However, Wang, Murthy, and Dashti do not explicitly teach the claim feature: “any active protective declarations issued by the transaction are not in use by a challenging process.”
In the same field of endeavor (i.e., data processing), Loring teaches: “any active protective declarations issued by the transaction are not in use by a challenging process” (Loring: par. [0026] “… To facilitate that a given transaction is committed to a table, existing database systems can employ varying approaches including Online Transactional Processing (OLTP) techniques… it is also increasingly important to ensure such transactions execute and complete in a concurrent manner that protects the integrity and consistency of the data in such a distributed environment”, and par. [0321] “to protect from constraint violation, T1 (or T2) should do the following:”, [0322] “1. Insert a record in the base table: <1, abc@gmail.com|Dimitris>...” to [323-324] via protective declaration protocols).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to combine the teachings of the cited references because the teachings of Loring would have provided Wang and Murthy, and Dashti with the above indicated limitation for allowing a skill artisan in motivation to perform the transaction executes and complete without using challenge process via active protective declaration to protect against any constraint violation (Loring: pars. [0026, 0321-324]).
Regarding claim 19, the claim is rejected by the same reasons set forth above to claim 1. However, Wang, Murthy, and Dashti do not explicitly teach the claim feature: “resolving pseudo-deadlocks by applying a forced challenging procedure.”
In the same field of endeavor (i.e., data processing), Loring teaches: “resolving pseudo-deadlocks by applying a forced challenging procedure” (par. [0135] “a query statement of SELECT . . . FOR UPDATE, the transaction manager API offers StatementContext::lock (Key), which allows rows to be locked without writing a value to them. The implementation of lock ( ) follows the write protocol, except that it writes a special sentinel value to indicate the absence of a value (distinct from SQL NULL). A SELECT . . . FOR UPDATE statement may also be forced to restart several times before the statement finishes successfully. Once it does, subsequent statements in the transaction will recognize the existence of this key as an indication that they hold the lock”; and pars. [0162] via “deadlocks can be handled by deadlock detection”, and [0163], [0170-177] and [0179] via a deadlock detection and resolution protocol).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to combine the teachings of the cited references because the teachings of Loring would have provided Wang and Murthy, and Dashti with the above indicated limitations for allowing a skill artisan in motivation to applying a forced challenging to resolve deadlock protocol/pseudo code of the transactions (Loring: pars. [0057, 135, 162-163, and 170-179]).
Claims 23 and 39 are rejected in the analysis of above claims 3 and 19; and therefore, the claims are rejected on that basis.
Claims 6 and 26 are rejected under 35 U.S.C. 103 as being unpatentable over Wang, Murthy, and Dashti, and in view of Blue, US Pub. No. 2006/0242644 A1 (hereinafter as “Blue”).
Regarding claim 6, the claim is rejected by the same reasons set forth above to claim 1-2 and 5. Furthermore, Wang, Murthy and Dashti, in combination, teach: “for each non-conditional conflict, marking the transaction as dependent on the corresponding conflicting transaction” (Dashti: page 1 col. 2, and page 6 at col. 1 via “not abort” means no conditional conflicts).
However, Wang, Murthy and Dashti do not explicitly teach claim feature: “removing any protective declarations issued by the transaction that were sourced by the corresponding conflicting transaction.”
In the same field of endeavor (i.e., data processing), Blue teaches: “removing any protective declarations issued by the transaction that were sourced by the corresponding conflicting transaction” (pars. [0073] using Lock() function to declare the protection from read/write access, and [0074] e.g., “…The CRWLockAccess declaration is parameterized by the name of the lock that protects the relevant resource…”, and release=remove the any protective declarations (e.g., lock from read, and lock from write) via using the Unlock() function, e.g., “After the reading instructions at line L8 have executed, inner scope is exited at line L9, causing the destructor for lck to execute. This destructor effectively causes the instruction "Lock_A.UnLockData (CRWLock::ReadLock)" to be issued, thereby setting in motion the process shown in FIG. 6, whereby the lock is released”).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to combine the teachings of the cited references because the teachings of Blue would have provided Wang, Murthy, Dashti with the above indicated limitations for allowing a skill artisan in motivation to lock and unlock function for improve protective declaration as access control read/write transactions in (Blue: pars. [0068-74]).
Claim 26 is rejected in the analysis of above claim 6; and therefore, the claim is rejected on that basis.
Claims 12 and 32 are rejected under 35 U.S.C. 103 as being unpatentable over Wang, Murthy, and Dashti, and further in view of Katsipoulakis et al., US Patent No. 12,007,990 B1 (hereinafter as “Katsipoulakis”).
Regarding claim 12, the claim is rejected by the same reasons set forth above to claim 1. However, Wang, Murthy, and Dashti do not explicitly teach: “creating a read vector entry in a read-vector of the reading-transaction; scanning write vectors of other pending transactions to identify conflicting writing-transactions; for each identified conflicting writing-transactions, sending a validation message to the conflicting writing-transaction; and reading the data cells by the reading-transaction.”
In the same field of endeavor (i.e., data processing), Katsipoulakis teaches:
creating a read vector entry in a read-vector of the reading-transaction (col. 18, lines 33-67: in the pseudo-code for reading transaction, in particular functions: … Read(Key, key);… “Future<void> bulkInsert(std::vector<std::pair<Key, Value>> data); Future<void> bulkUpdate(std::vector<std::pair<Key, Value>>” which implements creating a read vector entry (key, value));
scanning write vectors of other pending transactions to identify conflicting writing-transactions (again in the pseudo-code in col. 18, lines 33-67, including in particular, insert/write function: ““Future<void> bulkInsert(std::vector<std::pair<Key, Value>> data); Future<void> bulkUpdate(std::vector<std::pair<Key, Value>>” which implements creating a read vector entry (key, value)” and in particular scan protocols in col. 19, lines 1-33 including: “{FINALIZED, ABORTED, RESTARTED, DEADLOCKED}; Result finalize( ); private: ID transactionID; Private int statementNumber; Private int restartCount = 0; Timestamp readTimestamp; // Conflict Management Bool hasConflicts( ); Std::vector<Timestamp> getConflictingIDs( );}; and col. 27, lines 16-21: “indicate which inserting keys violate a constraint and should continue processing even if a violation of the constraint is detected. semi_future<vector<pair<WriteTimestamp, boolean>>>bulkInsert(KVPairs&&,…” ).
for each identified conflicting writing-transactions, sending a validation message to the conflicting writing-transaction (Abstract: “The subject technology determines that the set of statements includes at least one statement defining a first constraint, and a second statement indicating that the first constraint is statement deferrable for performing validation of the first constraint”; and col. 23, lines 10-16 via postponing constraint validation until the end of each statement or transaction execution such that “the subject technology resolves an undefined result issue in parallel execution on constraint validation or help the user to simplify their database usage to use the deferred constraint”); and
reading the data cells by the reading-transaction (see col. 3, lines 65-67: “Each of the multiple micro-partitions can include numerous rows and columns making up cells of database data…”; col. 10, lines 43-46: “each transaction includes one or more tasks or operations (e.g., read operation, write operation, database statement, user defined function, and the like) to perform.”, and lines 60-64: “Each of the transactions may be executed concurrently by the execution platform 110 in which different operations are performed (e.g., a respective read operation or write operation are executed from each of the transactions by the execution platform 110)”; and col. 18, lines 39-67 via read() function/protocol for reading data, for instance, function read(Key, key), readRange(Key from, Key to), wherein the key is implemented in data cells of rows and columns in the database table(s); and col. 21, lines 22-35).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to combine the teachings of the cited references because the teachings of Katsipoulakis would have provided Wang, Murthy, and Dashti, with the above indicated limitations for allowing a skill artisan in motivation to perform the multiversion concurrent control transactions during the validation process for any conflict occurs in the reading and writing operations (Katsipoulakis: Figs. 4-5; col. 10, lines 29-65, and or entire document).
Claim 32 is rejected in the analysis of above claim 12; and therefore, the claim is rejected on that basis.
Claims 14-17 and 34-37 are rejected under 35 U.S.C. 103 as being unpatentable over Wang, Murthy, and Dashti, and in view of SCHRETER et al., US Pub. No. 2016/0147906 A1 (hereinafter as “Schreter”).
Regarding claim 14, the claim is rejected by the same reasons set forth above to claim 1. However, Wang, Murthy, and Dashti do not explicitly teach: “wherein a state of a conditional conflict is determined as a stay-in state when evaluated values of the at least one predicate on a data cell set immediately before and immediately after committing the transaction are a Boolean value true, wherein the stay-in state provides that there is no potential dependency between the transaction and the corresponding conflicting transaction with respect to the conditional conflict.”
Schreter teaches: wherein a state of a conditional conflict is determined as a stay-in state when evaluated values of the at least one predicate on a data cell set immediately before and immediately after committing the transaction are a Boolean value true, wherein the stay-in state provides that there is no potential dependency between the transaction and the corresponding conflicting transaction with respect to the conditional conflict (Figs. 2-3 via the states, and 4A-4B via Boolean values, e.g., true and false predicates).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to combine the teachings of the cited references because the teachings of Schreter would have provided Wang, Murthy, and Dashti with the above indicated limitations after committing the transaction are a Boolean value true for allowing a skill artisan in motivation to perform the multiversion concurrency commit status of the transactions during the validation process.
Regarding claim 15, the claim is rejected by the same reasons set forth above to claim 1. However, Wang, Murthy, and Dashti do not explicitly teach: “wherein a state of a conditional conflict is determined as a stay-out state when evaluated values of the at least one predicate on a data cell set immediately before and immediately after committing the transaction is a Boolean value false, wherein the stay-out state provides that there is no potential dependency between the transaction and the corresponding conflicting transaction with respect to the conditional conflict.”
Schreter teaches: wherein a state of a conditional conflict is determined as a stay-out state when evaluated values of the at least one predicate on a data cell set immediately before and immediately after committing the transaction is a Boolean value false, wherein the stay-out state provides that there is no potential dependency between the transaction and the corresponding conflicting transaction with respect to the conditional conflict (Figs. 2-3 via the states, and 4A-4B via Boolean values, e.g., true and false predicates).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to combine the teachings of the cited references because the teachings of Schreter would have provided Wang, Murthy, and Dashti with the above indicated limitations after committing the transaction is a Boolean value false for allowing a skill artisan in motivation to perform the multiversion concurrency commit status of the transactions during the validation process
Regarding claim 16, the claim is rejected by the same reasons set forth above to claim 1. However, Wang, Murthy, and Dashti do not explicitly teach: “wherein a state of a conditional conflict is determined as a move-in state when evaluated values of the at least one predicate on a data cell set immediately before committing the transaction is a Boolean value false, and the evaluated value of the predicate immediately after committing the transaction is a Boolean value true, wherein the move-in state does not allow the transaction to commit before the corresponding conflicting transaction.”
Schreter teaches: wherein a state of a conditional conflict is determined as a move-in state when evaluated values of the at least one predicate on a data cell set immediately before committing the transaction is a Boolean value false, and the evaluated value of the predicate immediately after committing the transaction is a Boolean value true, wherein the move-in state does not allow the transaction to commit before the corresponding conflicting transaction (Figs. 2-3 via the states, and 4A-4B via Boolean values, e.g., true and false predicates).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to combine the teachings of the cited references because the teachings of Schreter would have provided Wang, Murthy, and Dashti with the above indicated limitations before committing the transaction is a Boolean value false for allowing a skill artisan in motivation to perform the multiversion concurrency commit status of the transactions during the validation process
Regarding claim 17, the claim is rejected by the same reasons set forth above to claim 1. However, Wang, Murthy, and Dashti do not explicitly teach: “wherein a state of a conditional conflict is determined as a move-out state when evaluated values of the at least one predicate on a data cell set immediately before committing the transaction is a Boolean value true, and the evaluated value of the predicate immediately after committing the transaction is a Boolean value false, wherein the move-out state does not allow the transaction to commit before the corresponding conflicting transaction.”
Schreter teaches: wherein a state of a conditional conflict is determined as a move-out state when evaluated values of the at least one predicate on a data cell set immediately before committing the transaction is a Boolean value true, and the evaluated value of the predicate immediately after committing the transaction is a Boolean value false, wherein the move-out state does not allow the transaction to commit before the corresponding conflicting transaction (Figs. 2-3 via the data cell set and various states, and 4A-4B via Boolean values, e.g., true and false predicates).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to combine the teachings of the cited references because the teachings of Schreter would have provided Wang, Murthy, and Dashti with the above indicated limitations before committing the transaction is a Boolean value true for allowing a skill artisan in motivation to perform the multiversion concurrency commit status of the transactions during the validation process
Claims 34-37 are rejected in the analysis of above claims 14-17; and therefore, the claims are rejected on that basis.
Allowable Subject Matter
Claims 8 and 9 are objected to as being dependent upon the above rejected base claims, but would be allowable if rewritten in independent form including all of the limitations of claims 8 and 9, and the rejected base claims 1 and 20. Similar objection is applied to claims 28 and 29 as considered a whole together with the rejected base claim 21, respectively.
Prior Arts
The prior art made of record on form PTO-892 and not relied upon is considered pertinent to applicant's disclosure. Applicant is required under 37 C.F.R. § 1.111(c) to consider these references fully when responding to this action.
It is noted that any citation to specific, pages, columns, lines, or figures in the prior art references and any interpretation of the references should not be considered to be limiting in any way. A reference is relevant for all it contains and may be relied upon for all that it would have reasonably suggested to one having ordinary skill in the art. See In re Heck, 699 F.2d 1331, 1332-33, 216 USPQ 1038, 1039 (Fed. Cir. 1983) (quoting In re Lemelson, 397 F.2d 1006, 1009, 158 USPQ 275,277 (CCPA 1968)); Merck & Co. v. Biocraft Laboratories, 874 F.2d 804, 10 USPQ2d 1843 (Fed. Cir.), cert. denied, 493 U.S. 975 (1989).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Jessica N. Le whose telephone number is (571)270-1009. The examiner can normally be reached M-F 9:30 am - 5:30 pm (EST).
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, SHERIEF BADAWI can be reached at (571) 272-9782. 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.
/Jessica N Le/Examiner, Art Unit 2169
/SHERIEF BADAWI/Supervisory Patent Examiner, Art Unit 2169
Prosecution Insights