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 .
DETAILED ACTION
Claims 1-20 are presented for examination.
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.
Claim 7 is being rejected under 35 U.S.C. 112(b), as being indefinite for failing to particularly point out and distinctly claim the subject matter which applicant regards as the invention.
claim 7 recites “the name of the writable manifest file. There is insufficient antecedent basis for this limitation in the claim.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-3,7,10-12 and 16-18 are rejected under 35 U.S.C. 102(a)(1) as anticipated by Horii (US 2018/0329944 A1)
As per claim 1, Horri teaches A computer-implemented method comprising:
receiving, by a distributed query processor (DQP) implemented on a processor, a distributed execution statement, the distributed execution statement including a plurality of tasks for executing a distributed transaction; (Horri [0022] The leader node 2 generates a batch to be executed by each of the plurality of member nodes 3 for the databases 30, in order to synchronize data updates among the databases 30 for the plurality of member nodes 3. Here, the batch is a compilation of a plurality of processes to be processed en masse, and includes two or more transactions to be executed for a database 30. A transaction to be executed for a database 30 is an inseparable series of information processes that is executed for the database, and may include one or more read/write processes for the database 30, for example).
assigning, by the DQP, a quantity of backend nodes for executing the plurality of tasks; (Horri [0004] the plurality of transactions and is to be executed by each of the plurality of member nodes )
requesting, by the DQP, a first backend node to execute a first task of the plurality of tasks; requesting, by the DQP, a second backend node to execute a second task from the plurality of tasks; (Horii [0004] According to a first aspect of the present invention, a distributed system is provided. The distributed system includes a plurality of member nodes that each store a database of replica of common data and update the database by performing common ones of a plurality of transactions. [0033] The plurality of member nodes 3 each store a database of replica of common data 30 and each perform a common transaction to update the database 30. Each of the plurality of member nodes 3 includes the database 30, a member-side consensus processing section 34, a member-side transaction processing section 35, a checking section 36, a member-side commit processing section 38, and a leader switching section 39).
receiving, by the DQP from the first backend node, a first confirmation that the first task has been executed, the execution of the first task providing a first result, the first confirmation indicating that the first result is ready to be committed by the DQP; receiving, by the DQP, from the second backend node, a second confirmation that the second task has been executed, the execution of the second task providing a second result, the second confirmation indicating that the second result is ready to be committed by the DQP; (Horii [0027] The access set generating section 22 may supply the batch generating section 23 with the generated access set in association with the contents or identification information of the transaction set. The access set generating section 22 may further supply the batch generating section 23 with an execution result of the transaction in association with the access set [0035] The member-side transaction processing section 35 may execute a transaction corresponding to the identification information in the batch, from among the plurality of transaction supplied thereto. Transactions to be executed for the database 30 may be sequentially supplied to and cumulatively stored in the member-side transaction processing section 35, from each of the plurality of nodes. The transactions supplied to the member-side transaction processing section 35 may have the same content as the transactions supplied to the leader-side transaction processing section 21. The member-side transaction processing section 35 may supply the checking section 36 with the execution results of the transactions. [0036] The checking section 36 may supply the member-side commit processing section 38 with the check results along with the execution results of the transaction in the batch. Furthermore, the checking section 36 may supply the leader switching section 39 with the check results. ).
executing, by the DQP, a conflict check between the first result and the second result; (Horii [0008] The method also includes checking whether there is an access conflict among the two or more transactions included in the batch [0036] The checking section 36 checks whether there is an access conflict among the plurality of transactions in the batch. For example, the checking section 36 may check whether there is an access conflict among all of the transactions in the batch. The checking section 36 may supply the member-side commit processing section 38 with the check results along with the execution results of the transaction in the batch. Furthermore, the checking section 36 may supply the leader switching section 39 with the check results. [0058] Next, the checking section 36 checks whether there is an access conflict among the plurality of transactions in the batch (step S315), and may judge whether there is an access conflict (step S317).)
based on determining the first result does not conflict with the second result, committing, by the DQP, the distributed transaction. (Horri [0037] The member-side commit processing section 38 commits the plurality of transactions, on the condition that there are no access conflicts among these transactions in the batch. For example, the member-side commit processing section 38 may update the database 20 according to the execution result of each transaction by the member-side transaction processing section 35, on the condition that a check result indicating that there are no access conflicts has been supplied from the checking section 36).
As per claim 2, Horri teaches wherein the distributed transaction comprises the first result and the second result. (Horri [0028] Furthermore, the batch generating section 23 may supply the leader-side commit processing section 28 with execution results of the transactions included in the generated batch. The execution results of the transactions may be supplied directly to the leader-side commit processing section 28 from the leader-side transaction processing section 21 without passing through the batch generating section 23 [0030] The leader-side commit processing section 28 commits two or more transactions, e.g., each transaction, in the batch, in response to a consensus being formed for the batch among the leader node 2 and the plurality of member nodes 3. For example, the leader-side commit processing section 28 may update the database 20 according to the execution results of the transactions by the leader-side transaction processing section 21.).
As per claim 3, Horri teaches wherein each of the first result and the second result comprises one of the following: new data in a table in a database in cloud storage, an update to existing data in the table, a removal of data from the table, a removal of the table, or a new table in the database in the cloud storage. (Horii [0022] The leader node 2 generates a batch to be executed by each of the plurality of member nodes 3 for the databases 30, in order to synchronize data updates among the databases 30 for the plurality of member nodes 3. Here, the batch is a compilation of a plurality of processes to be processed en masse, and includes two or more transactions to be executed for a database 30. A transaction to be executed for a database 30 is an inseparable series of information processes that is executed for the database, and may include one or more read/write processes for the database 30, for example [0086] If a consensus has been reached for the batch, the leader-side commit processing section 28 may commit each transaction in the batch. In this way, the current state of the database 20 is updated to the state S.sub.j+1.).
As per claim 7, Horri teaches further comprising based on determining the first result does conflict with the second result, do not commit the distributed transaction, and wherein the name of the writable manifest file not written into the table of committed manifest files. (Horii Fig 2 Block S317 Follow yes to S318 and [0059] If there is an access conflict at step S317 (S317:Yes), the member node 3 may judge that the batch set sent from the leader 2 was fallacy, and either propose or agree to switch the leader by communicating with the leader switching section 39 (step S318). Instead, if there is an access conflict at step S317 (S317: Yes), the member node 3 may again perform the processes of steps S313 to S317, and move the process to step S318 if there is still an access conflict.)
As to claims 10 and 16, they are rejected based on the same reason as claim 1.
As to claims 11 and 17, they are rejected based on the same reason as claim 2.
As to claims 12 and 18, they are rejected based on the same reason as claim 3.
Claim Rejections - 35 USC § 103
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 of this title, 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 4, 13 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Horii (US 2018/0329944 A1) in view of Cruanes (US 2024/0070143 A1).
As per claim 4, Horii does not teach wherein each of the first task and the second task comprises: reading data from storage based on a level of isolation identified by the DQP, and based on the data, executing the first task and the second task.
However, Cruanes teaches wherein each of the first task and the second task comprises: reading data from storage based on a level of isolation identified by the DQP, and based on the data, executing the first task and the second task. (Cruanes [0068] In an embodiment, distributed transaction manager 474 implements a transactional layer providing a read committed (e.g., transaction isolation level) for distributed database store 480 (e.g., corresponding to a FoundationDB instance). In this example, the read committed isolation level can require aborting on write-write conflicts, which is handled by starting the query with a newer read timestamp while holding the previously taken write locks. and [0190] In an implementation, a transaction manager (e.g., distributed transaction manager 474 discussed before) is provided that runs within an execution node (e.g., execution node 302-1), and implements SQL transactions at a read committed isolation level (e.g., read committed isolation level) on a distributed database. In an embodiment, an instance of distributed transaction manager 474 can be provided on each execution node where transactions (e.g., various RSOs) are being executed. Further, in an implementation, distributed transaction manager 474 can perform the same or similar functionality described in connection with transaction manager 440 discussed above.)
It would have been obvious to a person in the ordinary skill in the art before the filing date of the claimed invention to combine Cruanes with the system of Horii to determine an isolation level. One having ordinary skill in the art would have been motivated to use Cruanes into the system of Horii for the purpose of processing concurrent transactions in a distributed manner. (Cruanes paragraph 02)
As to claims 13 and 19, they are rejected based on the same reason as claim 4.
Claims 5, 14 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Horii (US 2018/0329944 A1) in view of Kumar (US 11,360,802 B2).
As per claim 5, Horii does not teach wherein the method further comprises, prior to committing the distributed transaction, updating a writable manifest file in storage with references to the first result and the second result.
However, Kumar teaches wherein the method further comprises, prior to committing the distributed transaction, updating a writable manifest file in storage with references to the first result and the second result. (Kumar [claim 8] updating the metadata and prior to the one or more transactions committing, processing the one or more transactions).
The examiner believes this is consistent with what is disclosed in the specification ([0025] The distributed executed statement is a writable manifest file that contains the physical metadata changes required by the received query and instructions that include specific transaction tasks to perform the changes and a quantity of nodes needed to perform the specific transaction tasks. In some examples, the file is updated in real-time as the statements in the transaction are successfully completed.)
It would have been obvious to a person in the ordinary skill in the art before the filing date of the claimed invention to combine Kumar with the system of Horii to update a writable manifest file. One having ordinary skill in the art would have been motivated to use Kumar into the system of Horii for the purpose of processing database statement (Kumar col 2, lines 5-10).
As to claims 14 and 20, they are rejected based on the same reason as claim 5.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Horii (US 2018/0329944 A1) in view of Lang (US 2017/0083588 A1).
As per claim 8, Horii does not teach requesting, by the DQP, a third backend node to execute a third task from the plurality of tasks; determining, by the DQP, that the third backend node failed to execute the third task; and upon determining the third backend node failed to execute the third task, re-assigning, by the DQP, the third task to a fourth backed node.
However, Lang teaches requesting, by the DQP, a third backend node to execute a third task from the plurality of tasks; determining, by the DQP, that the third backend node failed to execute the third task; and upon determining the third backend node failed to execute the third task, re-assigning, by the DQP, the third task to a fourth backed node. (Lang [0002] Within the field of computing, many scenarios involve distributed query processing over a data set, wherein a set of nodes is configured to perform portions of a query. In such scenarios, the contents of a data set may be partitioned over a set of nodes, and each node may apply a query to the subset of the database to which it is assigned. The partial results generated by the nodes may be combined to form a complete query response over the data set [0070] As a seventh variation of this second aspect, node selection may be made in a dynamic and/or fluid manner. As a first such example, the partitioning of the query 104 and/or selection of nodes 108 therefor may occur as a precursor to distributing the query 104 to any of the nodes 108. As a second such example, partitioning and/or node selection may be performed in an iterative or ad-hoc manner; e.g., a first query portion 206 of the query 104 may be assigned to a first node 108, and a second query portion 206 of the query 104 may be assigned to a second node 108 only after the first node 108 has begun, and perhaps even completed, the processing of the first query portion 206. As a third such example, the assignment of query portions 206 to nodes 108 may represent other than a 1:1 assignment. For example, a particular node 108 may be assigned to evaluate more than query portion 206 of a query 104, and/or query portions 206 of multiple queries 104. Conversely, a single query portion 206 may be assigned to two or more nodes 108, e.g., to serve as a backup node (e.g., having a failover node 108 available to take over processing of a query portion 206 bay a filed node, and/or performance, e.g., a RAID-like processing technique wherein multiple nodes 108 redundantly perform a single query portion 206 in order to retain the results in case one node 108 fails. As a fourth such example, partitioning and/or node selection may be reevaluated, and adjustments to the partitioning and/or node selection may be initiated after commencement of the processing. For example, if a node 108 fails or becomes overloaded while processing a query portion 206, some or all of the query portions 206 assigned to the node 108 may be reassigned to other nodes 108 of the node set 106. Alternatively or additionally, if estimated capabilities and/or costs of a particular node 108 diverge from actual capabilities and/or costs, other nodes 108 may be selected to perform the query portion 206. [0090] As a fourth variation of this fourth aspect, many techniques may be utilized to handle a failure of one or more nodes 108 during the processing of a query 104. As a first example of this fourth variation of this fourth aspect, the server 302 may choose a substitute node 108 for the node 108 that has failed, which may involve notifying a previous node 108 in the query processing pipeline to redirect intermediate query results 214 to the substitute node)
It would have been obvious to a person in the ordinary skill in the art before the filing date of the claimed invention to combine Lang with the system of Horii to reassign tasks. One having ordinary skill in the art would have been motivated to use Lang into the system of Horii for the purpose of providing a suitable framework for fulfilling many types of distributed queries.(Lang paragraph 05)
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Horii (US 2018/0329944 A1) in view of Gao (US 2019/0384643 A1).
As per claim 9, Horii does not teach prior to committing the distributed transaction: based on receiving the first confirmation, deallocating the first backend node; and based on receiving the second confirmation, deallocating the second backend node.
However, Gao teaches prior to committing the distributed transaction: based on receiving the first confirmation, deallocating the first backend node; and based on receiving the second confirmation, deallocating the second backend node. (Gao [0032] According to an aspect of the present disclosure, a method for managing tasks in a multi-platform environment text is provided. The method is implemented by a processor on a computing device. The method includes: receiving, from a first client device, a first request for access to a specific auxiliary service in support of a set of tasks; using an auxiliary service map to determine at least one server device that is available for providing the access to the auxiliary service; allocating, to the first client device, at least one of the available at least one server device; updating the auxiliary service map based on a result of the allocating; receiving, from the tasks, a notification that the tasks are complete; deallocating each of the allocated at least one server device; and updating the auxiliary service map based on a result of the deallocating).
It would have been obvious to a person in the ordinary skill in the art before the filing date of the claimed invention to combine Gao with the system of Horii to deallocate nodes. One having ordinary skill in the art would have been motivated to use Gao into the system of Horii for the purpose of scheduling and managing auxiliary services for applications in a multi-tenancy grid computing environment. (Gao paragraph 02)
Allowable Subject Matter
Claims 6 and 15 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20250103587 A1 – discloses implementing transaction processing over database objects stored in a strongly consistent object storage system. When a transaction is initiated, the system makes a private copy of data objects that are used by the transaction. Reads and writes of the transaction will be performed on the private copy. When the transaction is to be committed, the system verifies that the committed state of the data objects has not changed outside the transaction, and updates metadata object(s) in the data storage system to point to the private copy as the currently committed state of the data objects. If the committed state of any data objects has changed during the transaction, the private copy is abandoned and the transaction is rolled back and/or retried.
US 20240378191 A1 – discloses conflicting read and write transactions based on a lock release protocol are provided. An intent present at a version of a key can be identified by a first transaction. The first transaction can verify whether the intent corresponds to a second transaction having a simple-committed type to observe the intent as a committed value and proceed with execution or to wait on the second transaction to complete execution. Based on the second transaction being a simple-committed type, the first transaction can determine a provisional value included in the intent as a read value or write a new intent to a new version of the key without waiting for the second transaction to explicitly commit.
US 12001420 B2 – discloses disconnected operation in a distributed database system. In an embodiment, the distributed database system implements a disconnected mode of operation allowing isolated regions of database nodes to provisionally commit transactions, with the global requirements of those transactions later satisfied by a transparent healing process after network connectivity is reestablished between the regions. The healing process, in turn, enables the distributed database system to construct a consistent global state of the database that accounts for the transactions provisionally-committed in each isolated region during the disconnected mode. Once the healing process completes, database clients “see” a healed version of the database that simulates or otherwise closely approximates a state of the database had the distributed database system performed the transactions during a normal, fully-connected, mode of operation.
US 11599520 B1 – discloses a query restriction descriptor indicating one or more attributes of a data object of a multi-data-store storage system is determined at a client-side component of the system. The query restrictions descriptor is used to prepare at least a read set descriptor of a proposed transaction. The read set of the proposed transaction includes a query with a predicate directed to the one or more attributes. A transformation function is applied to the predicate, and the result of the transformation is included in the read set descriptor. The proposed transaction is sent to a journal manager of the system, which performs read-write conflict detection using the read set descriptor and write set descriptors of one or more previously-committed transactions.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MEHRAN KAMRAN whose telephone number is (571)272-3401. The examiner can normally be reached on 9-5.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, April Blair can be reached on (571)270-1014. 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.
.
/MEHRAN KAMRAN/ Primary Examiner, Art Unit 2196