DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Remarks
In response to communication files on December 22, 2025, claims 1, 11, and 12 are amended and claims 10 and 21 are cancelled by applicant's request. Therefore, claims 1-9 and 11-20 are presently pending in the application.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-9 and 11-20 are rejected under 35 U.S.C. 103 as being unpatentable over Bretl et al. (US Pub. 2002/0138483) (Eff filing date of app: 01/30/2001) (Hereinafter Bretl) in view of Wang (US Pat. 5,263,155) (Eff filing date of app: 2/21/1991).
As to claims 1 and 11-12, Bretl teaches a method for validating database transactions executed in a
receiving a commit statement that is part of a transaction, wherein the transaction is initiated by a client to be executed on the
returning an acknowledgment to the client that the transaction is committed, wherein the acknowledgment is returned upon validation of the transaction (see p. 35, “The term "BreakSerializationReleaseLocks (cuwriteSet)" indicates success of the commit from the concurrent update queue and that the transaction is removed from the concurrent update queue and the locks are released.”).
Bretl does not expressly teach distributed database system; and
validating the transaction in a Pessimistic manner by identifying one or more conflicting read operations from other transactions that have read from the data cells modified during the execution of the transaction and, in response, placing a dependency on the other transactions prior to placing a commit pause on data cells modified during the execution of the transaction, wherein the commit pause enables an atomicity of a distributed transaction commitment.
Wang teaches a system for selectively registering and blocking request initiated by optimistic and pessimistic transactions, see abstract, in which he teaches distributed database system (see fig. 2 and col. 4, ln 30-31, “FIG. 2 a depiction of a multi-processor system with a distributed database having shared objects.”); and
validating the transaction in a Pessimistic manner by identifying one or more conflicting read operations from other transactions that have read from the data cells modified during the execution of the transaction (see col. 1, ln 20-24, “Consider a program which reads an object, increments its value, and stores the resulting value back into the object. If this program is executed simultaneously in two transactions, there is a potential for having an incorrect result stored in the object. Both transactions may read the same value, the value originally stored in the object.”) and, in response, placing a dependency on the other transactions prior to placing a commit pause on data cells modified during the execution of the transaction (see col. 5, ln 21-23, “DBMS 114 also includes a wait queue 420, in which it stores pessimistic transactions waiting for access to particular objects.” And col. 6 ln, 42-47, “DBMS 114 calls upon lock table manager 414 to maintain lock table 418, which for each lock contains a record with an object identifier indicating which object is locked by the lock, the transaction type (optimistic or pessimistic) for the transaction which holds the lock, and the lock type (read or write).”), wherein the commit pause enables an atomicity of a distributed transaction commitment (see fig. 9 and 10, characters 806 and 904, where the pause/queue happen then release lock and commit).
It would have been obvious to a person having ordinary skill in the art at the time the invention was made to have modified Bretl by the teaching of Wang because distributed database system; and validating the transaction in a Pessimistic manner…, would enable the method because “it only checks for conflict locks when processing pessimistic transactions. Therefore, DBMS 114 only places pessimistic transactions into a wait state in conflict situations.”.
As to claims 2 and 13, Bretl as modified teaches wherein prior to receiving the commit statement, the method further comprises:
receiving at least one non-commit statement (see Bretl, abstract, “The method includes determining whether a database update conflicts with another database”); and
executing tasks included in each of the at least one non-commit statement in an optimistic manner (see Bretl, abstract, “The method includes determining whether a database update conflicts with another database update, applying an optimistic concurrency control for each database update that does not conflict with another database update”).
As to claims 3 and 14, Bretl as modified teaches wherein the transaction includes a collection of non-commit statements, wherein a non-commit statement causes execution of one or more tasks, wherein a task includes an execution of at least one read operation, at least one write operation, or both (see Bretl, p. 2, “In database systems a transaction is a mechanism that allows multiple users to atomically perform in isolation database modifications …, for example, a write/write conflict occurs when an object modified in one transaction (e.g., by one user or process) is modified by another concurrent transaction (e.g., by another user or process). For example, when a transaction (e.g., by a first user) writes an object and executes …, the transaction cannot commit successfully if in the meantime another transaction (e.g., by a second user) has committed a modification of that object”).
As to claims 4 and 15, Bretl as modified teaches wherein executing tasks in an optimistic manner further comprises:
allowing statements of other transactions to independently access a plurality of data cells in the database system, wherein the plurality of data cells are modified by one or more tasks of the at least one non-commit statement (see Bretl, p. 2, “For example, when a transaction (e.g., by a first user) writes an object and executes complex behavior based upon the state of that object, the transaction cannot commit successfully if in the meantime another transaction (e.g., by a second user) has committed a modification of that object” and p. 4, “However, optimistic concurrency controls are susceptible to livelock and process starvation wherein a transaction is prevented from committing because successive other transactions are committed first”).
As to claims 5 and 20, Bretl as modified teaches wherein validating the transaction in the pessimistic manner further comprises:
waiting for other transactions to commit (see Bretl, p. 4, “However, optimistic concurrency controls are susceptible to livelock and process starvation wherein a transaction is prevented from committing because successive other transactions are committed first”).
As to claims 6 and 16, Bretl as modified teaches The method further comprising:
causing a validation of each write operation performed during execution of the received transaction (see Bretl, p. 22-23, commit transaction).
As to claims 7 and 17, Bretl as modified teaches wherein causing the validation of each write operation further comprises:
placing the commit pause on the data cells modified by each of the write operations (see Bretl, fig. 2, character 50 and p. 22, block transaction).
As to claims 8 and 18, Bretl as modified teaches The method further comprising:
scanning a write vector of the transaction to identify data cells modified by each of the write operations (see Bretl, p. 2, isolation database modification);
for each identified data cell, identifying one or more conflicting read operations, wherein each of the conflicting read operations is of a conflicting transaction, wherein each conflicting transaction is different from the transaction (see Bretl, p. 2, “a write/write conflict occurs when an object modified in one transaction (e.g., by one user or process) is modified by another concurrent transaction (e.g., by another user or process).” Where the second user concurrent transaction can be read); and
placing a dependency between the transaction and a conflicting transaction (see Bretl, p. 2, “the transaction cannot commit successfully if in the meantime another transaction (e.g., by a second user) has committed a modification of that object.”).
As to claims 9 and 19, Bretl as modified teaches The method further comprising:
waiting until the dependencies between the transaction and the conflicting transaction are released (see Bretl, p. 3, “When a transaction locks an object, other transactions are restricted from accessing the object until the transaction releases its lock.” and p. 35, “The term "BreakSerializationReleaseLocks (cuwriteSet)" indicates success of the commit from the concurrent update queue and that the transaction is removed from the concurrent update queue and the locks are released.”); and
returning a validation acknowledgment (see Bretl, p. 35, “The term "BreakSerializationReleaseLocks (cuwriteSet)" indicates success of the commit from the concurrent update queue and that the transaction is removed from the concurrent update queue and the locks are released.”).
As to claims 10 and 21, Bretl as modified teaches wherein the database system is a distributed database system (see Bretl, p. 13, “transactions T1, T2, and T3 allow different users or processes to atomically perform in isolation database modifications that are guaranteed to be consistent”).
Response to Arguments
Applicant’s arguments with respect to claim(s) 1 and 11-12 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BELIX M ORTIZ DITREN whose telephone number is (571)272-4081. The examiner can normally be reached M-F 9am -5pm.
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, Amy Ng can be reached at 571-270-1698. 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.
BELIX M. ORTIZ DITREN
Primary Examiner
Art Unit 2164
/Belix M Ortiz Ditren/Primary Examiner, Art Unit 2164
Prosecution Insights