Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-8, 10-15, 17-18, 20-22, and 24-33 are rejected under 35 U.S.C. 103 as being unpatentable over Bishop et al. (US Pre-Grant Publication 2016/0378819) in view of Lee et al. (US Pre-Grant Publication 2018/0322157).
As to claim 1, Bishop teaches a computer-implemented method for executing a conflicting transaction, the method comprising:
receiving, from a client device at a first computing node of a plurality of computing nodes (see Bishop paragraphs [0006] and [0018]. A database client may interact with a computing system),
a first transaction directed to reading, at a first [transactionID], a key … , wherein the key comprises a plurality of versions each comprising a respective value and a respective [transactionID] for the value (see Bishop paragraph [0061]. A reader receives a transaction number to read data. It is noted that the transaction numbers function in the same way as timestamps in the claimed subject matter. Also see paragraph [0059], which shows how a key comprises a plurality of versions each with respective values and transaction numbers); and
executing, in response to receiving the first transaction, the first transaction, the execution of the first transaction comprising:
identifying, based on the first [transactionID], the respective value of a corresponding version of the plurality of versions of the key, wherein the respective [transactionID] of the corresponding version of the key comprises a second [transactionID] (see Bishop paragraphs [0059] and [0061]-[0070] generally. It is noted that a read attempt receives a transaction number. This transaction number is compared to transaction numbers in a transaction table);
determining the respective value of the corresponding version of the key comprises an intent, wherein the intent was written by a second transaction at the second [transactionID] (see Bishop paragraphs [0061]-[0070] generally and paragraph [0072]. The system may determine that a respective value of a key is an uncommitted transaction, and thus an intent); and
determining a type of the second transaction comprises a simple-committed type (see paragraphs [0061]-[0070]. While Bishop does not explicitly use the identifier “simple-committed type,” Bishop does show each of the claimed considerations to the extent claimed to determine whether a transaction is trustworthy and can be read. This status is being read as the “simple-committed type”),
the type of the second transaction comprising the simple-committed type when
(i) each of one or more intents written by the second transaction were written at the second [transactionID], wherein the one or more intents comprise the intent (see paragraphs [0061]-[0070]. The Transaction number of each transaction (TxVal) is compared to the Transaction number of the reader (TxIsolationVal). The intent of each transaction is the value associated with each transaction number),
(ii) the second [transactionID] is equivalent to a commit timestamp for the second transaction (see paragraphs [0068]-[0070]. The TransactionID is treated as the equivalent of a committed timestamp if the transaction may be trustworthy), and
(iii) zero of the one or more intents were removed during execution of the second transaction (see paragraph [0070]. Deleted rows are not considered to exist);
determining, based on the determination the type of the second transaction comprises the simple-committed type, a provisional value included in the intent as a read value for the first transaction (see Bishop paragraph [0072]. An uncommitted value, or intent, may still be read in some circumstances); and
sending, to the client device, the read value for the first transaction (see paragraphs [0019] and [0071]-[0072]. Results of queries are returned to a transaction reader).
Bishop does not clearly teach:
included in a plurality of replicas of a partition, the plurality of replicas of the partition being stored by a plurality of computer-readable storage media of the plurality of computing nodes;
timestamps as transactionIDs;
Lee teaches:
included in a plurality of replicas of a partition, the plurality of replicas of the partition being stored by a plurality of computer-readable storage media of the plurality of computing nodes (see Lee paragraph [0121]. There are various nodes in Lee. Nodes contain replicas of tables stored in other nodes. See paragraphs [0236] and [0243]-[0244] for distributed computer readable media);
timestamps as transactionIDs (see Lee paragraphs [0113] and Table 1. Transactions are recorded with timestamps).
It would have been obvious to one of ordinary skill in the art before the earliest filing date of the invention to have modified the teachings of Bishop by the teachings of Lee because both references are directed to performing reads and writes of multiversioned key values. Lee merely provides to Bishop the ability of recording transactions in multiple replicas, which will increase data redundancy in Bishop and help the system of Bishop to endure adverse events.
As to claim 2, Bishop as modified teaches the method of claim 1, wherein the intent comprises the provisional value and a pointer to a transaction record corresponding to the second transaction, wherein the transaction record indicates a status of the second transaction (see Bishop paragraph [0072]).
As to claim 3, Bishop as modified teaches the method of claim 1, wherein the identifying the respective value of the corresponding version of the plurality of versions of the key further comprises:
identifying, based on the second timestamp being less than or equal to the first timestamp, the respective value of the corresponding version of the plurality of versions of the key (see Bishop paragraphs [0061]-[0070]).
As to claim 4, Bishop as modified teaches the method of claim 1, further comprising:
determining the respective value of the corresponding version of the key comprises a committed value, wherein the committed value was committed by the second transaction at the second timestamp (see Bishop paragraphs [0061]-[0070]); and
determining the committed value as the read value for the first transaction (see Bishop paragraphs [0061]-[0070]).
As to claim 5, Bishop as modified teaches the method of claim 1, further comprising:
determining, based on the determination the respective value of the corresponding version of the key comprises the intent, the corresponding version of the key is not a most recent version of the key, the determining comprising:
identifying a key history corresponding to the key, wherein the key history comprises indications of the plurality of versions of the key (see Bishop paragraph [0061]. If multiple rows are considered trustworthy, the row with the highest transaction number value is used);
comparing the second timestamp to the respective timestamps of the plurality of versions of the key included in the key history (see Bishop paragraph [0061]. If multiple rows are considered trustworthy, the row with the highest transaction number value is used. Because a highest transaction number is determined, it would be obvious that a comparison be made); and
determining, based on the comparison of the second timestamp to the respective timestamps of the plurality of versions of the key, at least one timestamp of the respective timestamps of the plurality of versions of the key is greater than the second timestamp (see Bishop paragraph [0061]. If multiple rows are considered trustworthy, the row with the highest transaction number value is used).
As to claim 6, Bishop as modified teaches the method of claim 5, wherein the determining the provisional value included in the intent as the read value for the first transaction further comprises:
determining, based on the determination the corresponding version of the key is not the most recent version of the key, the provisional value included in the intent as the read value for the first transaction (see Bishop paragraph [0072]).
As to claim 7, Bishop as modified teaches the method of claim 1, further comprising:
determining, based on the determination the respective value of the corresponding version of the key comprises the intent, the corresponding version of the key is a most recent version of the key, the determining comprising:
identifying a key history corresponding to the key, wherein the key history comprises indications of the plurality of versions of the key (see Bishop paragraph [0061]);
comparing the second timestamp to the respective timestamps of the plurality of versions of the key included in the key history (see Bishop paragraph [0061]); and
determining, based on the comparison of the second timestamp to the respective timestamps of the plurality of versions of the key, the second timestamp is greater than each of the respective timestamps of the plurality of versions of the key (see Bishop paragraph [0061]).
As to claim 8, Bishop as modified teaches the method of claim 7, further comprising:
determining, based on the determination the corresponding version of the key is the most recent version of the key, the type of the second transaction comprises the simple-committed type (see Bishop paragraph [0061]).
As to claim 10, Bishop as modified teaches the method of claim 1, wherein the determining the provisional value included in the intent as the read value for the first transaction further comprises:
determining, based on the type of the second transaction comprising the simple- committed type, the provisional value included in the intent as the read value for the first transaction (see Bishop paragraph [0061] and [0072]).
As to claim 11, Bishop as modified teaches the method of claim 1, further comprising:
determining, by a transaction coordinator operating at the first computing node, the type of the second transaction comprises the simple-committed type (see Lee paragraphs [0047] and [0135]. Committed writes may be determined and sent to other replicas);
sending an indication of the type of the second transaction comprising the simple- committed type to each of the plurality of replicas of the partition (see Lee paragraphs [0047] and [0135]); and
storing, by each of the plurality of replicas of the partition, the indication (see Lee paragraphs [0047] and [0135]).
As to claim 12, Bishop as modified teaches the method of claim 1, further comprising:
determining the type of the second transaction by identifying an indication of the second transaction comprised in at least one of the plurality of replicas of the partition (see Bishop paragraphs [0061] and [0072]).
As to claim 13, Bishop as modified teaches the method of claim 1, further comprising:
resolving, based on the type of the second transaction, the intent, by identifying an update to a status of the second transaction (see Bishop paragraphs [0061] and [0072]).
As to claim 14, Bishop as modified teaches the method of claim 13, wherein the resolving the intent further comprises:
determining, based on the update, the respective value of the corresponding version of the key comprises a committed value, wherein the committed value was committed by the second transaction at the second timestamp (see Bishop paragraphs [0061]-[0070]); and
determining the committed value as the read value for the first transaction (see Bishop paragraphs [0061]-[0070]).
As to claim 15, Bishop as modified teaches the method of claim 13, wherein the resolving the intent further comprises:
identifying, based on the update, the respective value of one of the plurality of versions of the key, wherein the respective value was committed by a third transaction at a third timestamp (see Bishop paragraphs [0061]-[0070]); and
determining the respective value committed by the third transaction as the read value for the first transaction (see Bishop paragraphs [0061]-[0070]).
As to claim 17, Bishop teaches a computer-implemented method for executing a conflicting transaction, the method comprising:
receiving, from a client device at a first computing node of a plurality of computing nodes, a first transaction directed to writing, at a first [transactionID], to a key …, wherein the key comprises a plurality of versions each comprising a respective value and a respective [transactionID] for the value (see Bishop paragraphs [0043]-[0044]. Bishop shows that multiple transactions may be submitted for a key. These transactions are associated with transaction values to identify the order in which transactions are received. As noted in paragraph [0025], transactionIDs may be used to identify which transactions are trustworthy based on timing); and
executing, in response to receiving the first transaction, the first transaction, the execution of the first transaction comprising:
identifying a second [transactionID] as the respective [transactionID] of a most recent version of the plurality of versions of the key, wherein the most recent version of the key comprises the second [transactionID] (see Bishop paragraphs [0043]-[0044]. A series of transactions is submitted and stored);
determining, based on a comparison of the first [transactionID] to the second [transactionID], the respective value of the most recent version of the key comprises a second intent, wherein the second intent was written by a second transaction at the second timestamp (see Bishop paragraphs [0043]-[0044]. TransactionIDs are incremented. Transactions are also first stored in an uncommitted list); and
determining a type of the second transaction comprises a simple-committed type (see paragraphs [0043]-[0044] and [0061]-[0070]. While Bishop does not explicitly use the identifier “simple-committed type,” Bishop does show each of the claimed considerations to the extent claimed to commit a transaction), the type of the second transaction comprising the simple-committed type when
(i) each of one or more intents written by the second transaction were written at the second [transactionID], wherein the one or more intents comprise the second intent (see paragraphs [0043]-[0044], [0061]-[0070], and [0075]. Bishop tracks transaction identifiers and transaction intents for each transaction),
(ii) the second [transactionID] is equivalent to a commit timestamp for the second transaction (see paragraphs [0043]-[0044], [0061]-[0070], and [0075]. The transaction identifier is treated as equivalent to any commit identifier), and
(iii) zero of the one or more intents were removed during execution of the second transaction (see paragraphs [0043]-[0044], [0061]-[0070], and [0075]. Bishop addresses that some transactions may be removed);
writing, based on the determination the type of the second transaction comprises the simple-committed type, a new version of the key to the plurality of versions of the key at the first [transactionID], where in the new version comprises a first intent comprising a first provisional value and a first pointer to a first transaction record corresponding to the first transaction (see Bishop paragraphs [0043]-[0044] for writing transactions. In addition to this, paragraphs [0061]-[0070] and [0072] indicate that the most recent transactionID is read and that uncommitted transactions may be read in some circumstances. Bishop also shows in paragraph [0075] that transactions may supersede previous transactions).
Bishop does not explicitly teach:
… a key included in a plurality of replicas of a partition, the plurality of replicas of the partition being stored by a plurality of computer-readable storage media the plurality of computing nodes …
timestamps as transactionIDs;
Lee teaches:
… a key included in a plurality of replicas of a partition, the plurality of replicas of the partition being stored by a plurality of computer-readable storage media the plurality of computing nodes (see Lee paragraph [0121]. There are various nodes in Lee. Nodes contain replicas of tables stored in other nodes. See paragraphs [0236] and [0243]-[0244] for distributed computer readable media);
timestamps as transactionIDs (see Lee paragraphs [0113] and Table 1. Transactions are recorded with timestamps).
It would have been obvious to one of ordinary skill in the art before the earliest filing date of the invention to have modified the teachings of Bishop by the teachings of Lee because both references are directed to performing reads and writes of multiversioned key values. Lee merely provides to Bishop the ability of recording transactions in multiple replicas, which will increase data redundancy in Bishop and help the system of Bishop to endure adverse events.
As to claim 18, Bishop as modified teaches the method of claim 17, wherein the second intent comprises a second provisional value and a second pointer to a second transaction record corresponding to the second transaction, wherein the second transaction record indicates a status of the second transaction (see Bishop paragraphs [0043]-[0044] and [0061] and [0072]. Multiple transactions may be received in order and stored, along with the status of each transaction).
As to claim 20, Bishop as modified teaches the method of claim 17, wherein the determining the respective value of the most recent version of the key comprises the second intent further comprises:
comparing the first timestamp to the second timestamp (see Bishop paragraphs [0061]-[0072] and [0072]); and
determining, based on the second timestamp being less than the first timestamp, the respective value of the most recent version of the key comprises the second intent (see Bishop paragraphs [0061]-[0072] and [0072]).
As to claim 21, Bishop as modified teaches the method of claim 17, further comprising:
determining the respective value of the most recent version of the key comprises a committed value, wherein the committed value was written by the second transaction at the second timestamp (see Bishop paragraphs [0043]-[0045]); and
writing, based on the determination the respective value of the most recent version of the key comprises the committed value, the new version to the plurality of versions of the key at the first timestamp (see Bishop paragraphs [0043]-[0045]. Also see Lee paragraph [0111] and [0113] for writing a timestamp commit time when a transaction is updated).
As to claim 22, Bishop as modified teaches the method of claim 17, further comprising:
determining, based on the determination the respective value of the most recent version of the key comprises the second intent, the type of the second transaction comprises the simple-committed type (see Bishop paragraphs [0061]-[0072] and [0072]).
As to claim 24, Bishop as modified teaches the method of claim 17, wherein the writing the new version to the plurality of versions of the key further comprises:
writing, based on the type of the second transaction comprising the simple-committed type, the new version to the plurality of versions of the key (see Bishop paragraphs [0043]-[0045]. Also see Lee paragraph [0111] and [0113] for committing a transaction).
As to claim 25, Bishop as modified teaches the method of claim 17, further comprising:
determining, by a transaction coordinator operating at the first computing node, the type of the second transaction comprises the simple-committed type (see Lee paragraphs [0047], [0135], and [0205]. When writes are committed, they may be send to replicas);
sending an indication of the type of the second transaction comprising the simple- committed type to each of the plurality of replicas of the partition (see Lee paragraphs [0047], [0135], and [0205]); and
storing, by each of the plurality of replicas of the partition, the indication (see Lee paragraphs [0047], [0135], and [0205]).
As to claim 26, Bishop as modified teaches the method of claim 17, further comprising:
determining the type of the second transaction by identifying an indication of the second transaction comprised in at least one of the plurality of replicas of the partition (see Lee paragraph [0066]).
As to claim 27, Bishop as modified teaches the method of claim 17, wherein the plurality of replicas of the partition comprise a leader replica and two or more follower replicas, wherein the leader replica is configured to coordinate execution of a consensus protocol for write operations directed to the partition among a group comprising the leader replica and the two or more follower replicas (see Lee paragraphs [0047], [0135], and [0205]), and
wherein the writing the new version of the key to the plurality of versions of the key at the first timestamp further comprises:
sending, from the leader replica to the two or more follower replicas, an indication of the first intent (see Lee paragraphs [0047], [0135], and [0205]);
sending, from the two or more follower replicas to the leader replica, respective acknowledgements of the first intent (see Lee paragraph [0066]); and
committing, at the leader replica, the first intent based on a majority of the group acknowledging the first intent (see Lee paragraph [0066]).
As to claim 28, Bishop as modified teaches the method of claim 17, further comprising:
resolving, based on the type of the second transaction, the intent, the resolving comprising:
identifying an update to a status of the second transaction (see Lee paragraph [0111] and [0113] for committing a transaction); and
writing, based on the update, the new version of the key to the plurality of versions of the key at the first timestamp or at a third timestamp, wherein the third timestamp is greater than the first timestamp and the second timestamp (see Lee paragraph [0111] and [0113] for committing a transaction. The most recent timestamp is included at the time of committing the transaction).
As to claim 29, Bishop as modified teaches the method of claim 17, further comprising:
sending, from the first computing node to the client device, an indication of success for the first transaction (see Bishop paragraphs [0061]-[0070] and [0072]. Successful transactions may be read).
As to claim 30, see the rejection of claim 1.
As to claim 31, see the rejection of claim 17.
As to claim 32, Bishop as modified teaches the method of claim 2, further comprising:
before at least one of:
(i) the status of the transaction record corresponding to the second transaction is updated to committed, or
(ii) the one or more intents written by the second transaction are committed to one or more computer-readable storage media of the plurality of computer-readable storage media (see Bishop paragraph [0072]);
determining the provisional value included in the intent as the read value for the first transaction (see Bishop paragraph [0072]. In a situation where the transaction reader and writer are the same, a transaction on the uncommitted list may be determined to be trustworthy. Thus, the transaction value may be trustworthy, and thus be able to be returned, despite not yet being committed); and
sending, to the client device, the read value for the first transaction (see Bishop paragraphs [0071]-[0072]. A transaction reader returns values to queries).
As to claim 33, Bishop as modified teaches the method of claim 18, further comprising:
writing the new version of the key to the plurality of versions of the key at the first timestamp before at least one of:
(i) the status of the transaction record corresponding to the second transaction is updated to committed, or
(ii) the one or more intents written by the second transaction are committed to one or more computer-readable storage media of the plurality of computer-readable storage media (see paragraphs [0036]-[0039] and Figure 4. Bishop shows an example where a transaction numbered 19 is committed before a transaction numbered 18. Thus, transaction number 18 remains uncommitted).
Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Bishop et al. (US Pre-Grant Publication 2016/0378819) in view of Lee et al. (US Pre-Grant Publication 2018/0322157), and further in view of Jain et al. (US Patent 11,789,922).
As to claim 19, Bishop as modified by Lee teaches the method of claim 17.
Bishop does not explicitly teach further comprising:
comparing the first timestamp to the second timestamp; and
increasing, based on the second timestamp being greater than or equal to the first timestamp, the first timestamp to be greater than the second timestamp.
Jain teaches:
comparing the first timestamp to the second timestamp (see Jain 24:12-23. Jain may compare the timestamps of two transactions); and
increasing, based on the second timestamp being greater than or equal to the first timestamp, the first timestamp to be greater than the second timestamp (see Jain 24:12-23. Based on the comparison, and a second timestamp being equal to a first timestamp, Jain may choose a winner. It is noted that Lee teaches wherein a winning transaction, such as the first transaction, when written, will receive the latest timestamp, see paragraph [0104]).
It would have been obvious to one of ordinary skill in the art before the earliest filing date of the invention to have further modified the teachings of Bishop by the teachings of Jain, because Jain provides a benefit of ensuring that conflicting timestamps are resolved. This will provide a measure of conflict resolution to Bishop, which will help Bishop to better manage write transactions.
Response to Arguments
Applicant's arguments filed 26 September 2025 have been fully considered but they are not persuasive.
Applicant argues that “However, Applicant respectfully submits that Bishop fails to describe, teach, or suggest at least "determining a type of the second transaction comprises a simple-committed type, the type of the second transaction comprising the simple-committed type when (i) each of one or more intents written by the second transaction were written at the second timestamp, wherein the one or more intents comprise the intent, (ii) the second timestamp is equivalent to a commit timestamp for the second transaction, and (iii) zero of the one or more intents were removed during execution of the second transaction" as presently recited in amended claim 1. While Bishop does generally describe conditions for determining whether data in a versioned row is considered trustworthy and if multiple the highest rows are considered trustworthy, the row with transaction number value is used, Bishop is silent regarding "determining a type of the second transaction comprises a simple-committed type" with the conditions for the "simple-committed type" as recited in claim 1. Further, because Bishop is silent regarding "determining a type of the second transaction comprises a simple-committed type," Bishop necessarily also fails to describe, teach, or suggest "determining, based on the determination the type of the second transaction comprises the simple-committed type, a provisional value included in the intent as a read value for the first transaction" as presently recited in amended claim 1.”
In response to this argument, while Bishop does not specifically determine that a transaction is designated as a “simple-committed type” transaction, Bishop does show determining that a transaction is trustworthy relies upon the conditions as claimed. Because Bishop performs all of the claimed tests and because this results in a determination of a transaction’s status, the claimed steps would be obvious to one of ordinary skill in the art before the earliest filing date of the invention in view of Bishop.
Applicant continues, arguing that “Lee fails to remedy the deficiencies of Bishop with respect to at least the above-recited limitations of amended claim 1. Specifically, while Lee generally describes transaction commit timestamps and nodes, Lee is also silent regarding "determining a type of the second transaction comprises a simple-committed type" with the conditions for the "simple-committed type" as recited in claim 1.”
In response to this argument, Lee is not relied upon to teach this feature of the claim. Bishop, as explained above, teaches this limitation.
Applicant concludes by arguing that “Therefore, Bishop and Lee, individually or in combination, do not teach or suggest all of the limitations of independent claim 1, as amended. Independent claim 30 is amended herein to include at least some similar features to those of independent claim 1 and is also therefore patentable for at least the same reason. Claims 9 and 16 are cancelled herein, thereby rendering their rejections moot. Remaining claims 2-8 and 10-15 depend, directly or indirectly, from independent claim 1 and are therefore also patentable for at least the same reasons. Further, claims 2-8 and 10-15 are allowable for their respective recited features. Reconsideration of claims 1-8 and 10-15 is respectfully requested.”
In response to this argument, Bishop and Lee, as modified, teach claims 1 and 30 for the reasons provided in the rejection above.
Applicant argues that “Similar to independent claim 1, independent claim 17 has been amended to include limitations relating to dependent claim 23, which is cancelled herein.”
Applicant argues that “Accordingly, the Office Action appears to reference Bishop as teaching the limitations of dependent claim 23. However, Applicant respectfully submits that Bishop fails to describe, teach, or suggest at least "determining a type of the second transaction comprises a simple- committed type, the type of the second transaction comprising the simple-committed type when (i) each of one or more intents written by the second transaction were written at the second timestamp, wherein the one or more intents comprise the second intent, (ii) the second timestamp is equivalent to a commit timestamp for the second transaction, and (iii) zero of the one or more intents were removed during execution of the second transaction" as presently recited in amended claim 17.”
Applicant continues, arguing that “As described herein, while Bishop does generally describe conditions for determining whether data in a versioned row is considered trustworthy and if multiple the highest rows are considered trustworthy, the row with transaction number value is used, Bishop is silent regarding "determining a type of the second transaction comprises a simple-committed type" with the conditions for the "simple-committed type" as recited in claim 17. Further, because Bishop is silent regarding "determining a type of the second transaction comprises a simple- committed type," Bishop necessarily also fails to describe, teach, or suggest "writing, based on the determination the type of the second transaction comprises the simple-committed type, a new version of the key to the plurality of versions of the key at the first timestamp, wherein the new version comprises a first intent comprising a first provisional value and a first pointer to a first transaction record corresponding to the first transaction" as presently recited in amended claim 17.”
In response to this argument, while Bishop does not specifically determine that a transaction is designated as a “determining a type of the second transaction comprises a simple-committed type” transaction, Bishop does show determining the claimed conditions that are relied upon to make such a determination and commits a transaction when those conditions are fulfilled. Because Bishop performs all of the claimed tests and because this results in a determination of a transaction’s status, the claimed steps would be obvious to one of ordinary skill in the art before the earliest filing date of the invention in view of Bishop.
Applicant continues, arguing that “Lee fails to remedy the deficiencies of Bishop with respect to at least the above-recited limitations of amended claim 17. Specifically, while Lee generally describes transaction commit timestamps and nodes,36 Lee is also silent regarding "determining a type of the second transaction comprises a simple-committed type" with the conditions for the "simple-committed type" as recited in claim 17.”
In response to this argument, Lee is not relied upon to teach this feature of the claim. Bishop, as explained above, teaches this limitation.
Applicant concludes, by arguing that “Therefore, Bishop and Lee, individually or in combination, do not teach or suggest all of the limitations of independent claim 17, as amended. Independent claim 31 is amended herein to include at least some similar features to those of independent claim 17 and is also therefore patentable for at least the same reason. Claim 23 is cancelled herein, thereby rendering its rejection moot. Remaining claims 18-22 and 24-29 depend, directly or indirectly, from independent claim 1 and are therefore also patentable for at least the same reasons. Further, claims 18-22 and 24-29 are allowable for their respective recited features. Reconsideration of claims 17-22 and 24-29 is respectfully requested.”
In response to this argument, Bishop and Lee, as modified, teach claims 17 and 31 for the reasons provided in the rejection above.
Applicant argues that “Claim 19 depends from independent claim 17 and is allowable for at least the same reasons, as Jain as referenced in the rejections of claim 19 does not cure the deficiencies of the above-discussed references (i.e., Bishop and Lee) with respect to independent claims 17, and the Office Action does not allege otherwise. Reconsideration and withdrawal of the rejections to claims 19 under 35 U.S.C. §103 is respectfully requested.”
In response to this argument, it is noted that Jain is not relied upon to teach claim 17. Claim 17 is taught by a combination of Bishop and Lee as described above.
Conclusion
THIS ACTION IS MADE FINAL. 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 CHARLES D ADAMS whose telephone number is (571)272-3938. The examiner can normally be reached M-F, 9-5:30 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, Neveen Abel-Jalil can be reached at 571-270-0474. 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.
/CHARLES D ADAMS/Primary Examiner, Art Unit 2152