DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Abstract
2. Applicant is reminded of the proper language and format for an abstract of the disclosure.
The abstract should be in narrative form and generally limited to a single paragraph on a separate sheet within the range of 50 to 150 words in length. The abstract should describe the disclosure sufficiently to assist readers in deciding whether there is a need for consulting the full patent text for details.
The language should be clear and concise and should not repeat information given in the title. It should avoid using phrases which can be implied, such as, “The disclosure concerns,” “The disclosure defined by this invention,” “The disclosure describes,” etc. In addition, the form and legal phraseology often used in patent claims, such as “means” and “said,” should be avoided.
The abstract contains the legal terms “comprise” and “comprising” and should be removed. The word "comprise" could use "has" and the word "comprising" could be substituted with "involves".
Double Patenting
3. The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
4. Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 3-4, 6-11, 13-14, 16 and 18-20 of U.S. Patent No. 12443618. The subject matter claimed in the instant application is fully disclosed in the U.S. Patent No. 12443618 and is covered by the U.S. Patent No. 12443618 and the application are claiming common subject matter, as follows:
Instant Application - 19/284,080
U.S. Patent No. 12443618
1. A system comprising: at least one hardware processor; and a memory storing instructions that cause the at least one hardware processor to perform operations comprising: receiving blob metadata from a key-value store; retrieving a blob file from a blob store based on the blob metadata, wherein the blob file comprises at least one of a snapshot file or a delta file; transforming the blob file from a first format to a column file format, the transforming comprising converting data from the blob file to rowsets and writing the rowsets into a file in the column file format; and storing the file in a local cache.
1. A system comprising: at least one hardware processor; and a memory storing instructions that cause the at least one hardware processor to perform operations comprising: receiving, by an execution node, blob metadata from a key-value store, the blob metadata including information related to a set of blob files; determining, by the execution node using the blob metadata, whether a copy of each of the set of blob files is stored in a local cache of the execution node; transforming at least one blob file, retrieved from a blob store, to a second file in a column file format, the at least one blob file being in a first format that is different than the column file format, the transforming comprising at least converting a particular snapshot file from the at least one blob file to a particular set of rowsets and writing the set of rowsets into the second file in the column file format; and storing the second file in the local cache.
2. The system of claim 1, wherein the blob metadata comprises a snapshot file path, a set of delta file paths, and a set of in-memory mutations.
6. The system of claim 1, wherein the blob metadata comprises a snapshot file path, a set of delta file paths, and a set of in-memory mutations.
3. The system of claim 1, wherein transforming the blob file from a first format to a column file format comprises reading a snapshot file, converting the snapshot file into rowsets, reading a set of delta files, converting the set of delta files into particular rowsets, and merging the particular rowsets by merge-sorting the rowsets from the snapshot file and delta files to produce a sorted stream of keys for applying a set of visibility rules.
10. The system of claim 1, wherein the operations further comprise: reading a snapshot file; converting the snapshot file into rowsets; reading a set of delta files; converting the set of delta files into particular rowsets; merging the particular rowsets to apply a set of visibility rules; selecting an as-of version of each key; and for non-cached files, writing associated rowsets back to a set of Parquet files.
4. The system of claim 3, wherein the set of visibility rules determines an as-of version of each key of a query, and wherein determining the as-of version of each key comprises applying visibility rules that include determining whether a version was written by a current execution of the query, by a finalized statement of a transaction associated with the query, or by a different transaction with a commit timestamp less than or equal to a read timestamp of the query.
3. The system of claim 2, wherein determining the as-of version of each key comprises: determining that a version of a particular key was written by a current execution of the query.
4. The system of claim 2, wherein determining the as-of version of each key comprises: determining that a version of a particular key was written by a finalized statement of a transaction associated with the query; and determining that no other version of the particular key was written by a finalized statement of the transaction associated with the query with a larger statement number.
5. The system of claim 1, wherein the column file format comprises a Parquet file format, wherein transforming the blob file further comprises writing rowsets and schema metadata into a Parquet file, and wherein the operations further comprise performing type derivation based on the rowsets and performing encoding for each column of data of the Parquet file.
9. The system of claim 1, wherein the operations further comprise: writing rowsets and schema metadata into a Parquet file; performing type derivation based on the rowsets; and performing encoding for each column of data of the Parquet file.
6. The system of claim 1, wherein each rowset derived from a snapshot file comprises a set of columns, the set of columns comprises a delete vector column storing delete pointers to previous versions, a stamp column storing OLTP stamps for keys, and a column comprising a pointer to a separate storage space for storing values greater than a particular size threshold.
7. The system of claim 1, wherein each rowset comprises a set of columns, the set of columns comprises a delete vector column, a stamp column, and a column comprising a pointer to a separate storage space, the separate store space storing a set of values greater than a particular size threshold.
7. The system of claim 1, wherein the key-value store comprises a distributed database that provides linearizable storage, and wherein the distributed database ensures operations execute atomically between invocation and response.
8. The system of claim 1, wherein the key-value store comprises a distributed database that provides linearizable storage.
10. The system of claim 1, wherein the operations further comprise: reading a snapshot file; converting the snapshot file into rowsets; reading a set of delta files; converting the set of delta files into particular rowsets; merging the particular rowsets to apply a set of visibility rules; selecting an as-of version of each key; and for non-cached files, writing associated rowsets back to a set of Parquet files.
10. The system of claim 1, wherein the operations further comprise: reading a snapshot file; converting the snapshot file into rowsets; reading a set of delta files; converting the set of delta files into particular rowsets; merging the particular rowsets to apply a set of visibility rules; selecting an as-of version of each key; and for non-cached files, writing associated rowsets back to a set of Parquet files.
11. A method comprising: receiving blob metadata from a key-value store; retrieving a blob file from a blob store based on the blob metadata, wherein the blob file comprises at least one of a snapshot file or a delta file; transforming the blob file from a first format to a column file format, the transforming comprising converting data from the blob file to rowsets and writing the rowsets into a file in the column file format; and storing the file in a local cache.
11. A method comprising: receiving, by an execution node, blob metadata from a key-value store, the blob metadata including information related to a set of blob files; determining, by the execution node using the blob metadata, whether a copy of each of the set of blob files is stored in a local cache of the execution node; transforming at least one blob file, retrieved from a blob store, to a second file in a column file format, the at least one blob file being in a first format that is different than the column file format, the transforming comprising at least converting a particular snapshot file from the at least one blob file to a particular set of rowsets and writing the set of rowsets into the second file in the column file format; and storing the second file in the local cache.
12. The method of claim 11, wherein the blob metadata comprises a snapshot file path, a set of delta file paths, and a set of in-memory mutations.
16. The method of claim 11, wherein the blob metadata comprises a snapshot file path, a set of delta file paths, and a set of in-memory mutations.
13. The method of claim 11, wherein transforming the blob file from a first format to a column file format comprises reading a snapshot file, converting the snapshot file into rowsets, reading a set of delta files, converting the set of delta files into particular rowsets, and merging the particular rowsets by merge-sorting the rowsets from the snapshot file and delta files to produce a sorted stream of keys for applying a set of visibility rules.
10. The system of claim 1, wherein the operations further comprise: reading a snapshot file; converting the snapshot file into rowsets; reading a set of delta files; converting the set of delta files into particular rowsets; merging the particular rowsets to apply a set of visibility rules; selecting an as-of version of each key; and for non-cached files, writing associated rowsets back to a set of Parquet files.
14. The method of claim 13, wherein the set of visibility rules determines an as-of version of each key of a query, and wherein determining the as-of version of each key comprises applying visibility rules that include determining whether a version was written by a current execution of the query, by a finalized statement of a transaction associated with the query, or by a different transaction with a commit timestamp less than or equal to a read timestamp of the query.
13. The method of claim 12, wherein determining the as-of version of each key comprises: determining that a version of a particular key was written by a current execution of the query.
14. The method of claim 12, wherein determining the as-of version of each key comprises: determining that a version of a particular key was written by a finalized statement of a transaction associated with the query; and determining that no other version of the particular key was written by a finalized statement of the transaction associated with the query with a larger statement number.
15. The method of claim 11, wherein the column file format comprises a Parquet file format, wherein transforming the blob file further comprises writing rowsets and schema metadata into a Parquet file, and further comprising performing type derivation based on the rowsets and performing encoding for each column of data of the Parquet file.
19. The method of claim 11, further comprising: writing rowsets and schema metadata into a Parquet file; performing type derivation based on the rowsets; and performing encoding for each column of data of the Parquet file.
16. The method of claim 11, wherein each rowset derived from a snapshot file comprises a set of columns, the set of columns comprises a delete vector column storing delete pointers to previous versions, a stamp column storing OLTP stamps for keys, and a column comprising a pointer to a separate storage space for storing values greater than a particular size threshold.
7. The system of claim 1, wherein each rowset comprises a set of columns, the set of columns comprises a delete vector column, a stamp column, and a column comprising a pointer to a separate storage space, the separate store space storing a set of values greater than a particular size threshold.
17. The method of claim 11, wherein the key-value store comprises a distributed database that provides linearizable storage, and wherein the distributed database ensures operations execute atomically between invocation and response.
18. The method of claim 11, wherein the key-value store comprises a distributed database that provides linearizable storage.
20. A non-transitory computer-storage medium comprising instructions that, when executed by one or more processors of a machine, configure the machine to perform operations comprising: receiving blob metadata from a key-value store; retrieving a blob file from a blob store based on the blob metadata, wherein the blob file comprises at least one of a snapshot file or a delta file; transforming the blob file from a first format to a column file format, the transforming comprising converting data from the blob file to rowsets and writing the rowsets into a file in the column file format; and storing the file in a local cache.
20. A non-transitory computer-storage medium comprising instructions that, when executed by one or more processors of a machine, configure the machine to perform operations comprising: receiving, by an execution node, blob metadata from a key-value store, the blob metadata including information related to a set of blob files; determining, by the execution node using the blob metadata, whether a copy of each of the set of blob files is stored in a local cache of the execution node; transforming at least one blob file, retrieved from a blob store, to a second file in a column file format, the at least one blob file being in a first format that is different than the column file format, the transforming comprising at least converting a particular snapshot file from the at least one blob file to a particular set of rowsets and writing the set of rowsets into the second file in the column file format; and storing the second file in the local cache.
Noted, it would have been obvious to a person of ordinary skill in the art at the time the invention was made to modify or to omit the additional elements of claims 1, 3-4, 6-11, 13-14, 16 and 18-20 of U.S. Patent No. 12443618 to arrive at the claims 1-7, 10-17 and 20 of the instant application because the person would have realized that the remaining element would perform the same functions as before. "Omission of element and its function in combination is obvious expedient if the remaining elements perform same functions as before." See In re Karlson (CCPA) 136 USPQ 184, decide Jan 16, 1963, Appl. No. 6857, U.S. Court of Customs and Patent Appeals.
The remaining claims are rejected for fully incorporating the deficiencies of the base claim(s) from which they depend.
5. Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 3-4, 6-11, 13-14, 16 and 18-20 of U.S. Patent No. 12086154. The subject matter claimed in the instant application is fully disclosed in the U.S. Patent No. 12086154 and is covered by the U.S. Patent No. 12086154 and the application are claiming common subject matter, as follows:
Instant Application - 19/284,080
U.S. Patent No. 12086154
1. A system comprising: at least one hardware processor; and a memory storing instructions that cause the at least one hardware processor to perform operations comprising: receiving blob metadata from a key-value store; retrieving a blob file from a blob store based on the blob metadata, wherein the blob file comprises at least one of a snapshot file or a delta file; transforming the blob file from a first format to a column file format, the transforming comprising converting data from the blob file to rowsets and writing the rowsets into a file in the column file format; and storing the file in a local cache.
1. (Currently Amended) A system comprising: at least one hardware processor; and a memory storing instructions that cause the at least one hardware processor to perform operations comprising: receiving a query, the query including a query range for processing the query; sending, by an execution node that received the query, a request to a key-value store for blob metadata and a set of recent writes for the query range, the key-value store storing the blob metadata in a different location than a local cache, the local cache being included in memory of the execution node; receiving the blob metadata, the blob metadata including information related to a set of blob files; determining, by the execution node using the blob metadata, whether a copy of each of the set of blob files is stored in the local cache included in memory of the execution node; in response to at least one blob file being missing from the set of blob files, sending a request to a blob store to retrieve, from the blob store, the at least one blob file of the set of blob files; transforming the retrieved at least one blob file to a second file in a column file format, the at least one blob file being in a first format that is different than the column file format, the transforming comprising at least converting a particular snapshot file from the at least one blob file to a particular set of rowsets and writing the set of rowsets into the second file in the column file format; and storing the second file in the local cache.
2. The system of claim 1, wherein the blob metadata comprises a snapshot file path, a set of delta file paths, and a set of in-memory mutations.
6. (Original) The system of claim 1, wherein the blob metadata comprises a snapshot file path, a set of delta file paths, and a set of in-memory mutations.
3. The system of claim 1, wherein transforming the blob file from a first format to a column file format comprises reading a snapshot file, converting the snapshot file into rowsets, reading a set of delta files, converting the set of delta files into particular rowsets, and merging the particular rowsets by merge-sorting the rowsets from the snapshot file and delta files to produce a sorted stream of keys for applying a set of visibility rules.
10. (Original) The system of claim 1, wherein the operations further comprise: reading a snapshot file; converting the snapshot file into rowsets; reading a set of delta files; converting the set of delta files into particular rowsets; merging the particular rowsets to apply a set of visibility rules; selecting an as-of version of each key; and for non-cached files, writing associated rowsets back to a set of Parquet files.
4. The system of claim 3, wherein the set of visibility rules determines an as-of version of each key of a query, and wherein determining the as-of version of each key comprises applying visibility rules that include determining whether a version was written by a current execution of the query, by a finalized statement of a transaction associated with the query, or by a different transaction with a commit timestamp less than or equal to a read timestamp of the query.
3. (Original) The system of claim 2, wherein determining the as-of version of each key comprises: determining that a version of a particular key was written by a current execution of the query.
4. (Original) The system of claim 2, wherein determining the as-of version of each key comprises: determining that a version of a particular key was written by a finalized statement of a transaction associated with the query; and determining that no other version of the particular key was written by a finalized statement of the transaction associated with the query with a larger statement number.
5. The system of claim 1, wherein the column file format comprises a Parquet file format, wherein transforming the blob file further comprises writing rowsets and schema metadata into a Parquet file, and wherein the operations further comprise performing type derivation based on the rowsets and performing encoding for each column of data of the Parquet file.
9. (Original) The system of claim 1, wherein the operations further comprise: writing rowsets and schema metadata into a Parquet file; performing type derivation based on the rowsets; and performing encoding for each column of data of the Parquet file.
6. The system of claim 1, wherein each rowset derived from a snapshot file comprises a set of columns, the set of columns comprises a delete vector column storing delete pointers to previous versions, a stamp column storing OLTP stamps for keys, and a column comprising a pointer to a separate storage space for storing values greater than a particular size threshold.
7. (Currently Amended) The system of claim 1, wherein each rowset comprises a set of columns, the set of columns comprises a delete vector column, a stamp column, and a column comprising a pointer to a separate storage space, the separate store space storing a set of values greater than a particular size threshold.
7. The system of claim 1, wherein the key-value store comprises a distributed database that provides linearizable storage, and wherein the distributed database ensures operations execute atomically between invocation and response.
8. (Original) The system of claim 1, wherein the key-value store comprises a distributed database that provides linearizable storage.
8. The system of claim 1, wherein the operations further comprise sending a request to the key-value store for the blob metadata and a set of recent writes for a query range in response to receiving a query that includes the query range for processing, and receiving the blob metadata from the key-value store.
1. (Currently Amended) A system comprising: at least one hardware processor; and a memory storing instructions that cause the at least one hardware processor to perform operations comprising: receiving a query, the query including a query range for processing the query; sending, by an execution node that received the query, a request to a key-value store for blob metadata and a set of recent writes for the query range, the key-value store storing the blob metadata in a different location than a local cache, the local cache being included in memory of the execution node; receiving the blob metadata, the blob metadata including information related to a set of blob files; determining, by the execution node using the blob metadata, whether a copy of each of the set of blob files is stored in the local cache included in memory of the execution node; in response to at least one blob file being missing from the set of blob files, sending a request to a blob store to retrieve, from the blob store, the at least one blob file of the set of blob files; transforming the retrieved at least one blob file to a second file in a column file format, the at least one blob file being in a first format that is different than the column file format, the transforming comprising at least converting a particular snapshot file from the at least one blob file to a particular set of rowsets and writing the set of rowsets into the second file in the column file format; and storing the second file in the local cache.
10. The system of claim 1, wherein the operations further comprise: reading a snapshot file; converting the snapshot file into rowsets; reading a set of delta files; converting the set of delta files into particular rowsets; merging the particular rowsets to apply a set of visibility rules; selecting an as-of version of each key; and for non-cached files, writing associated rowsets back to a set of Parquet files.
10. (Original) The system of claim 1, wherein the operations further comprise: reading a snapshot file; converting the snapshot file into rowsets; reading a set of delta files; converting the set of delta files into particular rowsets; merging the particular rowsets to apply a set of visibility rules; selecting an as-of version of each key; and for non-cached files, writing associated rowsets back to a set of Parquet files.
11. A method comprising: receiving blob metadata from a key-value store; retrieving a blob file from a blob store based on the blob metadata, wherein the blob file comprises at least one of a snapshot file or a delta file; transforming the blob file from a first format to a column file format, the transforming comprising converting data from the blob file to rowsets and writing the rowsets into a file in the column file format; and storing the file in a local cache.
11. (Currently Amended) A method comprising: receiving a query, the query including a query range for processing the query; sending, by an execution node that received the query, a request to a key-value store for blob metadata and a set of recent writes for the query range, the key-value store storing the blob metadata in a different location than a local cache, the local cache being included in memory of the execution node; receiving the blob metadata, the blob metadata including information related to a set of blob files; determining, by the execution node using the blob metadata, whether a copy of each of the set of blob files is stored in the local cache included in memory of the execution node; in response to at least one blob file being missing from the set of blob files, sending a request to a blob store to retrieve, from the blob store, the at least one blob file of the set of blob files; transforming the retrieved at least one blob file to a second file in a column file format, the at least one blob file being in a first format that is different than the column file format, the transforming comprising at least converting a particular snapshot file from the at least one blob file to a particular set of rowsets and writing the set of rowsets into the second file in the column file format; and storing the second file in the local cache.
12. The method of claim 11, wherein the blob metadata comprises a snapshot file path, a set of delta file paths, and a set of in-memory mutations.
16. (Original) The method of claim 11, wherein the blob metadata comprises a snapshot file path, a set of delta file paths, and a set of in-memory mutations.
13. The method of claim 11, wherein transforming the blob file from a first format to a column file format comprises reading a snapshot file, converting the snapshot file into rowsets, reading a set of delta files, converting the set of delta files into particular rowsets, and merging the particular rowsets by merge-sorting the rowsets from the snapshot file and delta files to produce a sorted stream of keys for applying a set of visibility rules.
10. (Original) The system of claim 1, wherein the operations further comprise: reading a snapshot file; converting the snapshot file into rowsets; reading a set of delta files; converting the set of delta files into particular rowsets; merging the particular rowsets to apply a set of visibility rules; selecting an as-of version of each key; and for non-cached files, writing associated rowsets back to a set of Parquet files.
14. The method of claim 13, wherein the set of visibility rules determines an as-of version of each key of a query, and wherein determining the as-of version of each key comprises applying visibility rules that include determining whether a version was written by a current execution of the query, by a finalized statement of a transaction associated with the query, or by a different transaction with a commit timestamp less than or equal to a read timestamp of the query.
13. (Original) The method of claim 12, wherein determining the as-of version of each key comprises: determining that a version of a particular key was written by a current execution of the query.
14. (Original) The method of claim 12, wherein determining the as-of version of each key comprises: determining that a version of a particular key was written by a finalized statement of a transaction associated with the query; and determining that no other version of the particular key was written by a finalized statement of the transaction associated with the query with a larger statement number.
15. The method of claim 11, wherein the column file format comprises a Parquet file format, wherein transforming the blob file further comprises writing rowsets and schema metadata into a Parquet file, and further comprising performing type derivation based on the rowsets and performing encoding for each column of data of the Parquet file.
19. (Original) The method of claim 11, further comprising: writing rowsets and schema metadata into a Parquet file; performing type derivation based on the rowsets; and performing encoding for each column of data of the Parquet file.
16. The method of claim 11, wherein each rowset derived from a snapshot file comprises a set of columns, the set of columns comprises a delete vector column storing delete pointers to previous versions, a stamp column storing OLTP stamps for keys, and a column comprising a pointer to a separate storage space for storing values greater than a particular size threshold.
7. (Currently Amended) The system of claim 1, wherein each rowset comprises a set of columns, the set of columns comprises a delete vector column, a stamp column, and a column comprising a pointer to a separate storage space, the separate store space storing a set of values greater than a particular size threshold.
17. The method of claim 11, wherein the key-value store comprises a distributed database that provides linearizable storage, and wherein the distributed database ensures operations execute atomically between invocation and response.
18. (Original) The method of claim 11, wherein the key-value store comprises a distributed database that provides linearizable storage.
18. The method of claim 11, further comprising sending a request to the key- value store for the blob metadata and a set of recent writes for a query range in response to receiving a query that includes the query range for processing, and receiving the blob metadata from the key-value store.
11. (Currently Amended) A method comprising: receiving a query, the query including a query range for processing the query; sending, by an execution node that received the query, a request to a key-value store for blob metadata and a set of recent writes for the query range, the key-value store storing the blob metadata in a different location than a local cache, the local cache being included in memory of the execution node; receiving the blob metadata, the blob metadata including information related to a set of blob files; determining, by the execution node using the blob metadata, whether a copy of each of the set of blob files is stored in the local cache included in memory of the execution node; in response to at least one blob file being missing from the set of blob files, sending a request to a blob store to retrieve, from the blob store, the at least one blob file of the set of blob files; transforming the retrieved at least one blob file to a second file in a column file format, the at least one blob file being in a first format that is different than the column file format, the transforming comprising at least converting a particular snapshot file from the at least one blob file to a particular set of rowsets and writing the set of rowsets into the second file in the column file format; and storing the second file in the local cache.
20. A non-transitory computer-storage medium comprising instructions that, when executed by one or more processors of a machine, configure the machine to perform operations comprising: receiving blob metadata from a key-value store; retrieving a blob file from a blob store based on the blob metadata, wherein the blob file comprises at least one of a snapshot file or a delta file; transforming the blob file from a first format to a column file format, the transforming comprising converting data from the blob file to rowsets and writing the rowsets into a file in the column file format; and storing the file in a local cache.
20. (Currently Amended) A non-transitory computer-storage medium comprising instructions that, when executed by one or more processors of a machine, configure the machine to perform operations comprising: receiving a query, the query including a query range for processing the query; sending, by an execution node that received the query, a request to a key-value store for blob metadata and a set of recent writes for the query range, the key-value store storing the blob metadata in a different location than a local cache, the local cache being included in memory of the execution node; receiving the blob metadata, the blob metadata including information related to a set of blob files; determining, by the execution node using the blob metadata, whether a copy of each of the set of blob files is stored in the local cache included in memory of the execution node; in response to at least one blob file being missing from the set of blob files, sending a request to a blob store to retrieve, from the blob store, the at least one blob file of the set of blob files; transforming the retrieved at least one blob file to a second file in a column file format, the at least one blob file being in a first format that is different than the column file format, the transforming comprising at least converting a particular snapshot file from the at least one blob file to a particular set of rowsets and writing the set of rowsets into the second file in the column file format; and storing the second file in the local cache.
Noted, it would have been obvious to a person of ordinary skill in the art at the time the invention was made to modify or to omit the additional elements of claims 1, 3-4, 6-11, 13-14, 16 and 18-20 of U.S. Patent No. 12086154 to arrive at the claims 1-8, 10-18 and 20 of the instant application because the person would have realized that the remaining element would perform the same functions as before. "Omission of element and its function in combination is obvious expedient if the remaining elements perform same functions as before." See In re Karlson (CCPA) 136 USPQ 184, decide Jan 16, 1963, Appl. No. 6857, U.S. Court of Customs and Patent Appeals.
The remaining claims are rejected for fully incorporating the deficiencies of the base claim(s) from which they depend.
Claim Rejections - 35 USC § 103
6. 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 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.
7. Claims 1, 3, 8, 11, 13, 18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Lalsangi et al. (US 2022/0413765 A1) hereinafter Lalsangi, in view of Taranov (US 2013/0018903 A1) hereinafter Taranov and further in view of Phelan et al. (US 9,524,183 B1) hereinafter Phelan.
As to claim 1, Lalsangi discloses a system comprising: at least one hardware processor; and a memory storing instructions that cause the at least one hardware processor to perform operations (Para. 19) comprising:
receiving blob metadata from a key-value store (Fig. 6, Para. 12, “The semantics may also be used to expose the centralized key value store to the plurality of clients for direct non-hierarchical access to variable sized metadata and the variable sized data blobs identifiable using the keys.”. Para. 13, “The key value store interface can receive variable sized data blobs and hashes of the variable sized data blobs according to the key value store semantics from the plurality of clients. The variable sized data blobs can then be stored as values and the hashes as keys into the centralized key value store”. Para. 81, “the system 600 comprises one or more network storage appliances configured to provide clients with access to fabric attached non-volatile memory devices 616 for offloading metadata of applications hosted by the clients in order to reduce memory consumption and provide efficient metadata lookups.”. Thus, the system receives blob metadata from a key-value store.);
retrieving a blob file from a blob store based on the blob metadata (Para. 19, In response to receiving a request from a client for a variable sized data blob associated with a key, the key is utilized to identify the variable sized data blob within the centralized key value store, i.e., a blob store. The variable sized data blob is reconstructed utilizing data of the variable sized data blob stored within one or more fixed size blocks of the shared network attached storage of the centralized key value store.”. Para. 13, The key value store interface can receive variable sized data blobs, i.e., retrieving a blob file from a blob store, and hashes of the variable sized data blobs according to the key value store semantics from the plurality of clients. The variable sized data blobs can then be stored as values and the hashes as keys into the centralized key value store. Para. 40, “A translation layer binding is used to translate/transform a key value command (e.g., a command from a client to store or retrieve a variable sized data blob as a value data item) into a key value operation that is formatted according to semantics and an API set of a key value store targeted by the key value command.”. Thus, retrieving a blob file from a blob store based on the blob metadata.).
Lalsangi does not explicitly disclose wherein the blob file comprises at least one of a snapshot file or a delta file; transforming the blob file from a first format to a column file format, the transforming comprising converting data from the blob file to rowsets and writing the rowsets into a file in the column file format; and storing the file in a local cache.
However, in the same field of endeavor, Taranov discloses wherein the blob file comprises at least one of a snapshot file or a delta file (Para. 14, “The feed data includes data fields of fixed and varying lengths. The computer system converts the received feed data into portions of binary blob data. The binary blob data is allocated in fixed-size data portions representing feed rows. Varying length fields are represented by both a fixed-size field, with a length of the feed field, and a reference into the blob data that includes the actual varying size feed data.”. Para. 28, “The system also allows detection of the data change between subsequent feed reading sessions by hashing each feed row blob value. The database server uses the data change detection mechanism to avoid storing of duplicate data.”. Thus, the blob file comprises at least one of a snapshot file or a delta file.);
transforming the blob file from a first format to a column file format, the transforming comprising converting data from the blob file to rowsets and writing the rowsets into a file in the column file format (Fig, 2, Para. 34, “Method 200 includes an act of sending the binary blob data to a database server, the database server being configured to access metadata associated with a dynamic server statement to determine how to convert the binary blob data to a server table with a BLOB column configured to store the rows of feed data (act 230). For example, application server system 105 may send binary blob data 116 to database server 125. The database server accesses metadata 120 which includes a dynamic server statement. The metadata indicates to the server how the binary blob data is to be converted to a server table with a blob column 141 configured to store the rows of feed data 101. Execution of the dynamic server statement 121 (e.g. by module 135) then converts the data and stores it in data store 140.”. Thus, the method transforms the blob file from a first format to a column file format.).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system of Lalsangi by sending the blob data of Lalsangi to the database server of Taranov to convert the binary blob data to a server table with a BLOB column as disclosed by Taranov (Para. 34). The database server is configured to access metadata associated with a feed. Metadata contains dynamic server statement to determine how to convert the binary blob data to a server table with a BLOB column configured to store the rows of feed data (Taranov, Para. 14). One of the ordinary skills in the art would have motivated to make this modification in order to represent varying length fields by both a fixed-size field, with a length of the feed field, and a reference into the blob data that includes the actual varying size feed data as suggested by Taranov (Para. 14).
Combination of Lalsangi and Taranov do not explicitly disclose storing the file in a local cache.
However, in the same field of endeavor, Phelan discloses storing the file in a local cache (Col. 8 lines 65-67; col. 9 lines 1-3, the cache service may be used to identify the request in a first format from the container, translate the request into the necessary format for the BLOB object format, retrieve the data from the storage repository, and cache the data in a location accessible by the application container, i.e., storing the file in a local cache.).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Phelan into the combined method of Lalsangi and Taranov by storing the converted blob data in the cache of Phelan such that the data can be accessible by the application container and the cache executing outside of the application container as disclosed by Phelan (Col. 8 lines 65-67; col. 9 lines 1-14). In response to the request, the cache service may translate the request, if necessary, into an alternative data retrieval format, such as a format necessary for GlusterFS, or some other data retrieval format. Once retrieved, the cache service may place the data in a cache location associated with the requesting application container (Phelan, Col. 6 lines 19-25). One of the ordinary skills in the art would have motivated to make this modification in order to ensure the time to retrieve data for processing is improved by placing the data in a cache location as suggested by Phelan (Col. 6 lines 19-28).
As to claim 11, Lalsangi discloses a method comprising: receiving blob metadata from a key-value store (Fig. 6, Para. 12, “The semantics may also be used to expose the centralized key value store to the plurality of clients for direct non-hierarchical access to variable sized metadata and the variable sized data blobs identifiable using the keys.”. Para. 13, “The key value store interface can receive variable sized data blobs and hashes of the variable sized data blobs according to the key value store semantics from the plurality of clients. The variable sized data blobs can then be stored as values and the hashes as keys into the centralized key value store”. Para. 81, “the system 600 comprises one or more network storage appliances configured to provide clients with access to fabric attached non-volatile memory devices 616 for offloading metadata of applications hosted by the clients in order to reduce memory consumption and provide efficient metadata lookups.”. Thus, the system receives blob metadata from a key-value store.);
retrieving a blob file from a blob store based on the blob metadata (Para. 19, In response to receiving a request from a client for a variable sized data blob associated with a key, the key is utilized to identify the variable sized data blob within the centralized key value store, i.e., a blob store. The variable sized data blob is reconstructed utilizing data of the variable sized data blob stored within one or more fixed size blocks of the shared network attached storage of the centralized key value store.”. Para. 13, The key value store interface can receive variable sized data blobs, i.e., retrieving a blob file from a blob store, and hashes of the variable sized data blobs according to the key value store semantics from the plurality of clients. The variable sized data blobs can then be stored as values and the hashes as keys into the centralized key value store. Para. 40, “A translation layer binding is used to translate/transform a key value command (e.g., a command from a client to store or retrieve a variable sized data blob as a value data item) into a key value operation that is formatted according to semantics and an API set of a key value store targeted by the key value command.”. Thus, retrieving a blob file from a blob store based on the blob metadata.).
Lalsangi does not explicitly disclose wherein the blob file comprises at least one of a snapshot file or a delta file; transforming the blob file from a first format to a column file format, the transforming comprising converting data from the blob file to rowsets and writing the rowsets into a file in the column file format; and storing the file in a local cache.
However, in the same field of endeavor, Taranov discloses wherein the blob file comprises at least one of a snapshot file or a delta file (Para. 14, “The feed data includes data fields of fixed and varying lengths. The computer system converts the received feed data into portions of binary blob data. The binary blob data is allocated in fixed-size data portions representing feed rows. Varying length fields are represented by both a fixed-size field, with a length of the feed field, and a reference into the blob data that includes the actual varying size feed data.”. Para. 28, “The system also allows detection of the data change between subsequent feed reading sessions by hashing each feed row blob value. The database server uses the data change detection mechanism to avoid storing of duplicate data.”. Thus, the blob file comprises at least one of a snapshot file or a delta file.);
transforming the blob file from a first format to a column file format, the transforming comprising converting data from the blob file to rowsets and writing the rowsets into a file in the column file format (Fig, 2, Para. 34, “Method 200 includes an act of sending the binary blob data to a database server, the database server being configured to access metadata associated with a dynamic server statement to determine how to convert the binary blob data to a server table with a BLOB column configured to store the rows of feed data (act 230). For example, application server system 105 may send binary blob data 116 to database server 125. The database server accesses metadata 120 which includes a dynamic server statement. The metadata indicates to the server how the binary blob data is to be converted to a server table with a blob column 141 configured to store the rows of feed data 101. Execution of the dynamic server statement 121 (e.g. by module 135) then converts the data and stores it in data store 140.”. Thus, the method transforms the blob file from a first format to a column file format.).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system of Lalsangi by sending the blob data of Lalsangi to the database server of Taranov to convert the binary blob data to a server table with a BLOB column as disclosed by Taranov (Para. 34). The database server is configured to access metadata associated with a feed. Metadata contains dynamic server statement to determine how to convert the binary blob data to a server table with a BLOB column configured to store the rows of feed data (Taranov, Para. 14). One of the ordinary skills in the art would have motivated to make this modification in order to represent varying length fields by both a fixed-size field, with a length of the feed field, and a reference into the blob data that includes the actual varying size feed data as suggested by Taranov (Para. 14).
Combination of Lalsangi and Taranov do not explicitly disclose storing the file in a local cache.
However, in the same field of endeavor, Phelan discloses storing the file in a local cache (Col. 8 lines 65-67; col. 9 lines 1-3, the cache service may be used to identify the request in a first format from the container, translate the request into the necessary format for the BLOB object format, retrieve the data from the storage repository, and cache the data in a location accessible by the application container, i.e., storing the file in a local cache.).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Phelan into the combined method of Lalsangi and Taranov by storing the converted blob data in the cache of Phelan such that the data can be accessible by the application container and the cache executing outside of the application container as disclosed by Phelan (Col. 8 lines 65-67; col. 9 lines 1-14). In response to the request, the cache service may translate the request, if necessary, into an alternative data retrieval format, such as a format necessary for GlusterFS, or some other data retrieval format. Once retrieved, the cache service may place the data in a cache location associated with the requesting application container (Phelan, Col. 6 lines 19-25). One of the ordinary skills in the art would have motivated to make this modification in order to ensure the time to retrieve data for processing is improved by placing the data in a cache location as suggested by Phelan (Col. 6 lines 19-28).
As to claim 20, Lalsangi discloses a non-transitory computer-storage medium comprising instructions that, when executed by one or more processors of a machine (Para. 19), configure the machine to perform operations comprising:
receiving blob metadata from a key-value store (Fig. 6, Para. 12, “The semantics may also be used to expose the centralized key value store to the plurality of clients for direct non-hierarchical access to variable sized metadata and the variable sized data blobs identifiable using the keys.”. Para. 13, “The key value store interface can receive variable sized data blobs and hashes of the variable sized data blobs according to the key value store semantics from the plurality of clients. The variable sized data blobs can then be stored as values and the hashes as keys into the centralized key value store”. Para. 81, “the system 600 comprises one or more network storage appliances configured to provide clients with access to fabric attached non-volatile memory devices 616 for offloading metadata of applications hosted by the clients in order to reduce memory consumption and provide efficient metadata lookups.”. Thus, the system receives blob metadata from a key-value store.);
retrieving a blob file from a blob store based on the blob metadata (Para. 19, In response to receiving a request from a client for a variable sized data blob associated with a key, the key is utilized to identify the variable sized data blob within the centralized key value store, i.e., a blob store. The variable sized data blob is reconstructed utilizing data of the variable sized data blob stored within one or more fixed size blocks of the shared network attached storage of the centralized key value store.”. Para. 13, The key value store interface can receive variable sized data blobs, i.e., retrieving a blob file from a blob store, and hashes of the variable sized data blobs according to the key value store semantics from the plurality of clients. The variable sized data blobs can then be stored as values and the hashes as keys into the centralized key value store. Para. 40, “A translation layer binding is used to translate/transform a key value command (e.g., a command from a client to store or retrieve a variable sized data blob as a value data item) into a key value operation that is formatted according to semantics and an API set of a key value store targeted by the key value command.”. Thus, retrieving a blob file from a blob store based on the blob metadata.).
Lalsangi does not explicitly disclose wherein the blob file comprises at least one of a snapshot file or a delta file; transforming the blob file from a first format to a column file format, the transforming comprising converting data from the blob file to rowsets and writing the rowsets into a file in the column file format; and storing the file in a local cache.
However, in the same field of endeavor, Taranov discloses wherein the blob file comprises at least one of a snapshot file or a delta file (Para. 14, “The feed data includes data fields of fixed and varying lengths. The computer system converts the received feed data into portions of binary blob data. The binary blob data is allocated in fixed-size data portions representing feed rows. Varying length fields are represented by both a fixed-size field, with a length of the feed field, and a reference into the blob data that includes the actual varying size feed data.”. Para. 28, “The system also allows detection of the data change between subsequent feed reading sessions by hashing each feed row blob value. The database server uses the data change detection mechanism to avoid storing of duplicate data.”. Thus, the blob file comprises at least one of a snapshot file or a delta file.);
transforming the blob file from a first format to a column file format, the transforming comprising converting data from the blob file to rowsets and writing the rowsets into a file in the column file format (Fig, 2, Para. 34, “Method 200 includes an act of sending the binary blob data to a database server, the database server being configured to access metadata associated with a dynamic server statement to determine how to convert the binary blob data to a server table with a BLOB column configured to store the rows of feed data (act 230). For example, application server system 105 may send binary blob data 116 to database server 125. The database server accesses metadata 120 which includes a dynamic server statement. The metadata indicates to the server how the binary blob data is to be converted to a server table with a blob column 141 configured to store the rows of feed data 101. Execution of the dynamic server statement 121 (e.g. by module 135) then converts the data and stores it in data store 140.”. Thus, the method transforms the blob file from a first format to a column file format.).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system of Lalsangi by sending the blob data of Lalsangi to the database server of Taranov to convert the binary blob data to a server table with a BLOB column as disclosed by Taranov (Para. 34). The database server is configured to access metadata associated with a feed. Metadata contains dynamic server statement to determine how to convert the binary blob data to a server table with a BLOB column configured to store the rows of feed data (Taranov, Para. 14). One of the ordinary skills in the art would have motivated to make this modification in order to represent varying length fields by both a fixed-size field, with a length of the feed field, and a reference into the blob data that includes the actual varying size feed data as suggested by Taranov (Para. 14).
Combination of Lalsangi and Taranov do not explicitly disclose storing the file in a local cache.
However, in the same field of endeavor, Phelan discloses storing the file in a local cache (Col. 8 lines 65-67; col. 9 lines 1-3, the cache service may be used to identify the request in a first format from the container, translate the request into the necessary format for the BLOB object format, retrieve the data from the storage repository, and cache the data in a location accessible by the application container, i.e., storing the file in a local cache.).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Phelan into the combined method of Lalsangi and Taranov by storing the converted blob data in the cache of Phelan such that the data can be accessible by the application container and the cache executing outside of the application container as disclosed by Phelan (Col. 8 lines 65-67; col. 9 lines 1-14). In response to the request, the cache service may translate the request, if necessary, into an alternative data retrieval format, such as a format necessary for GlusterFS, or some other data retrieval format. Once retrieved, the cache service may place the data in a cache location associated with the requesting application container (Phelan, Col. 6 lines 19-25). One of the ordinary skills in the art would have motivated to make this modification in order to ensure the time to retrieve data for processing is improved by placing the data in a cache location as suggested by Phelan (Col. 6 lines 19-28).
As to claims 3 and 13, the claims are rejected for the same reasons as claims 1 and 11 above. In addition, Taranov discloses wherein transforming the blob file from a first format to a column file format comprises reading a snapshot file, converting the snapshot file into rowsets, reading a set of delta files, converting the set of delta files into particular rowsets (Para. 14, “The computer system converts the received feed data into portions of binary blob data. The binary blob data is allocated in fixed-size data portions representing feed rows. Varying length fields are represented by both a fixed-size field, with a length of the feed field, and a reference into the blob data that includes the actual varying size feed data. The computer system also sends the binary blob data to a database server. The database server is configured to access metadata associated with a feed. Metadata contains dynamic server statement to determine how to convert the binary blob data to a server table with a BLOB colunm configured to store the rows of feed data..”. Thus, transforming the blob file from a first format to a column file format comprises reading a snapshot file, converting the snapshot file into rowsets, reading a set of delta files, converting the set of delta files into particular rowsets.), and
merging the particular rowsets by merge-sorting the rowsets from the snapshot file and delta files to produce a sorted stream of keys for applying a set of visibility rules (Para. 28, “Regarding compact storage of data with dynamic schemas, the database server 125 may provide compact efficient data storage close in size as if the feed data was stored in a static table. This result may be achieved as the feed data is stored only in the binary format. The metadata is stored per feed registration and so its size is of the same order (i.e. like it would be for a static database table). The system also allows detection of the data change between subsequent feed reading sessions by hashing each feed row blob value. The database server uses the data change detection mechanism to avoid storing of duplicate data.”. Therefore, merging the particular rowsets by merge-sorting the rowsets from the snapshot file and delta files to produce a sorted stream of keys for applying a set of visibility rules.).
As to claims 8 and 18, the claims are rejected for the same reasons as claims 1 and 11 above. In addition, Lalsangi discloses wherein the operations further comprise sending a request to the key-value store for the blob metadata and a set of recent writes for a query range in response to receiving a query that includes the query range for processing (Para. 38, “The key value operation is formatted according to semantics and an API set of a key value store targeted by the key value command. The semantics may relate to the format of operations natively supported by a particular type of key value store/persistent storage media. The semantics may relate to variables, functions, syntax, and parameter of operations recognized by that particular type of key value store/persistent storage media. Such operations may relate to a put key value operation to store a key value pair, a get key operation to retrieve a key value pair, a delete operation to delete a key value pair, a range query operation to read a range of key value pairs, a post operation, and/or other operations.”. Thus, a request sending to a key-value store for blob metadata and a set of recent writes for the query range.), and
receiving the blob metadata from the key-value store (Fig. 6, Para. 12, “The semantics may also be used to expose the centralized key value store to the plurality of clients for direct non-hierarchical access to variable sized metadata and the variable sized data blobs identifiable using the keys.”. Para. 13, “The key value store interface can receive variable sized data blobs and hashes of the variable sized data blobs according to the key value store semantics from the plurality of clients. The variable sized data blobs can then be stored as values and the hashes as keys into the centralized key value store”. Para. 81, “the system 600 comprises one or more network storage appliances configured to provide clients with access to fabric attached non-volatile memory devices 616 for offloading metadata of applications hosted by the clients in order to reduce memory consumption and provide efficient metadata lookups.”.).
8. Claims 2, 7, 9-10, 12, 17 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Lalsangi, Taranov and Phelan as applied above, in view of CALDER et al. (US 2015/0350316 A1) hereinafter CALDER.
As to claims 2 and 12, the claims are rejected for the same reasons as claims 1 and 11 above. Combinaiton of Lalsangi, Taranov and Phelan do not explicitly disclose wherein the blob metadata comprises a snapshot file path, a set of delta file paths, and a set of in-memory mutations.
However, in the same field of endeavor, CALDER discloses wherein the blob metadata comprises a snapshot file path, a set of delta file paths, and a set of in-memory mutations (Para. 35, By way of examples, in an import job, the location object (e.g., blob path and file path), i.e. the blob metadata, may help identify the location, for example in a storage account, where the customer data should be stored, and in an export job, the location object (e.g., blob path and file path) may identify the location, for example in a storage account, from which the customer data should be retrieved. A data object associated with an import job or an export job can identify data (e.g., blob or file) that can be transferred between the storage medium and the storage service infrastructure. Para. 39, “The portion of the storage medium may include the master boot record with a boot sector and/or metadata that define files, back up critical system data, buffer file system changes, and free space allocation. The portion of the storage medium may also include a master file table that describes the files on the volume, including file names, time stamps, compression, encryption etc.”. Thus, the blob metadata comprises a snapshot file path, a set of delta file paths, and a set of in-memory mutations.).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of CALDER into the combined method of Lalsangi, Taranov and Phelan by including the location object such as blob metadata in order to identify the location where the customer data should be stored and retrieved as disclosed by CALDER (Para. 35). Data transfer objects can include a location object, a data object, a security object, and a validation object that facilitate performing data transfer operations associated with each corresponding object or combination of objects (CALDER, Para. 34). One of the ordinary skills in the art would have motivated to make this modification in order to identify data (e.g., blob or file) that can be transferred between the storage medium and the storage service infrastructure as suggested by CALDER (Para. 35).
As to claims 7 and 17, the claims are rejected for the same reasons as claims 1 and 11 above. In addition, CALDER discloses wherein the key-value store comprises a distributed database that provides linearizable storage (Fig. 2, Para. 65, “The storage service infrastructure 208 generally refers to a distributed storage system having computing devices and storage service infrastructure storage media for supporting a storage service. The storage service may provide a data transfer service, such that, data from the customer infrastructure may be copied via the storage media 216B to the storage service infrastructure. The storage service infrastructure 208 may further comprise a data transfer storage service component 210 and data transfer management component 212 to support storage-service-side data transfer operations associated with data transfer jobs.”. Thus, the key-value store comprises a distributed database that provides linearizable storage.), and wherein the distributed database ensures operations execute atomically between invocation and response (Para. 34, “The manifest can be created with a plurality of different data transfer objects that facilitate performing data transfer operations. Data transfer objects refer to constant or variable parameters of the data transfer service that provide for a specific function in data transfer operations. Data transfer objects can include a location object, a data object, a security object, and a validation object that facilitate performing data transfer operations associated with each corresponding object or combination of objects.”. Thus, the distributed database ensures operations execute atomically between invocation and response.).
As to claims 9 and 19, the claims are rejected for the same reasons as claims 1 and 11 above. In addition, CALDER discloses wherein the blob file is retrieved from a blob store that maintains consistency with transactional data in the key-value store through replication of change streams to produce row-based deltas and snapshots in the blob store (Para. 85, “The storage service infrastructure stores the data (e.g., blobs and/or files), such that, data is transferred from storage service infrastructure into the storage medium. In one embodiment, blobs stored in the storage service infrastructure may be converted into individual files that are transferred to the storage medium. The storage service infrastructure may further store snapshot data to be transferred. A snapshot data may refer to a version of the data (e.g., blobs and/or file) captured at a particular time. Snapshot data may be associated with a snapshot object in the data transfer manifest. Snapshot data may have been identified by a user as important when the data was in that version or may have been automatically created by the storage service infrastructure based on one or more policies.”. Para. 86, “Identifying the data may comprise selecting the data in the storage service infrastructure to be copied to the storage medium. In particular, one or more of a relative blob path to select a single blob or snapshot, a blob prefix to select all blobs or snapshots of the given prefix, and all blobs or snapshots in the storage account can be selected to be transferred to the storage medium. Similarly the relative paths to files or snapshots thereof may be identified for transfer.”. Thus, the blob file is retrieved from a blob store that maintains consistency with transactional data in the key-value store through replication of change streams to produce row-based deltas and snapshots in the blob store.).
As to claim 10, the claim is rejected for the same reasons as claim 1 above. In addition, Taranov discloses wherein the operations further comprise: reading a snapshot file; converting the snapshot file into rowsets; reading a set of delta files; converting the set of delta files into particular rowsets (Para. 14, “The computer system converts the received feed data into portions of binary blob data. The binary blob data is allocated in fixed-size data portions representing feed rows. Varying length fields are represented by both a fixed-size field, with a length of the feed field, and a reference into the blob data that includes the actual varying size feed data. The computer system also sends the binary blob data to a database server. The database server is configured to access metadata associated with a feed. Metadata contains dynamic server statement to determine how to convert the binary blob data to a server table with a BLOB colunm configured to store the rows of feed data..”. Thus, transforming the blob file from a first format to a column file format comprises reading a snapshot file, converting the snapshot file into rowsets, reading a set of delta files, converting the set of delta files into particular rowsets.); merging the particular rowsets to apply a set of visibility rules; selecting an as-of version of each key; and for non-cached files, writing associated rowsets back to a set of Parquet files (Para. 28, “Regarding compact storage of data with dynamic schemas, the database server 125 may provide compact efficient data storage close in size as if the feed data was stored in a static table. This result may be achieved as the feed data is stored only in the binary format. The metadata is stored per feed registration and so its size is of the same order (i.e. like it would be for a static database table). The system also allows detection of the data change between subsequent feed reading sessions by hashing each feed row blob value. The database server uses the data change detection mechanism to avoid storing of duplicate data.”. Therefore, merging the particular rowsets to apply a set of visibility rules; selecting an as-of version of each key; and for non-cached files, writing associated rowsets back to a set of Parquet files.).
9. Claims 4-5 and 14-15 are rejected under 35 U.S.C. 103 as being unpatentable over Lalsangi, Taranov and Phelan as applied above, in view of Schreter (US 2022/0382758 A1), hereinafter Schreter.
As to claims 4 and 14, the claims are rejected for the same reasons as claims 3 and 13 above. Combinaiton of Lalsangi, Taranov and Phelan do not explicitly disclose wherein the set of visibility rules determines an as-of version of each key of a query, and wherein determining the as-of version of each key comprises applying visibility rules that include determining whether a version was written by a current execution of the query, by a finalized statement of a transaction associated with the query, or by a different transaction with a commit timestamp less than or equal to a read timestamp of the query.
However, in the same field of endeavor, Schreter discloses wherein the set of visibility rules determines an as-of version of each key of a query (Para. 56, “the load factor of the data page 312 may be determined based on the visibility information (e.g., the quantity of rows in the data page 312 visible for transactional processing) and the modifications associated with the execution of one or more data definition language (DDL) statements. Moreover, the data page 312 may be merged, based on the load factor of the data page 312, with one or more neighboring data pages. For example, when the load factor of the data page 312 drops below a threshold value, the data page 312 may be merged with a data page 318 adjacent to the data page 312 in the disk 150.”. Thus, the operations further comprise: merging the transformed at least one blob file based at least in part on a set of visibility rules, the set of visibility rules determining an as-of version of each key of the query.), and
wherein determining the as-of version of each key comprises applying visibility rules that include determining whether a version was written by a current execution of the query (Para. 58, “The second type may be current table metadata, which is modified (in a versioned way) by executing one or more data definition language (DDL) statements on the table and of which there is always one current version.”. Thus, a version of a particular key was written by a current execution of the query.), by a finalized statement of a transaction associated with the query (Para. 58, “The second type may be current table metadata, which is modified (in a versioned way) by executing one or more data definition language (DDL) statements on the table and of which there is always one current version.”. Para. 59, “With on-the-fly conversion, subsequent to executing the data definition language (DDL) statements, a column may be associated with new metadata (e.g., the type was changed from int to varchar). Thus, loading a "new" data page may encounter the new metadata (type varchar) and interpret the data as-is. However, if an "old" data page was written before the data definition language statement is read, the reader may determine that there is no such int column in the table and will follow links between metadata versions to find out that the type needs to be converted from int to varchar. At this time, on-demand and on-the-fly, the data being loaded (integer values) may be converted into the data actually requested by the query processor (varchar values).”. Para. 60, “For transactional processing that requires inserting and/or updating data, the hybrid transactional analytical processing database 110 may create a new row and write the new row into the one or more columnar buffers 340. Transactional processing that requires deleting data may be handled through data visibility (e.g., multi version concurrency control (MVCC) operations and/or the like) and garbage collection.”. Thus, a version of a particular key was written by a finalized statement of a transaction associated with the query.), or by a different transaction with a commit timestamp less than or equal to a read timestamp of the query (Para. 55, “One or more data definition language statements may also be executed to modify an existing column in the database table in which case the quantity of used space on the data page 312 may change in accordance to a difference in size between a previous data format and a new data format of the column.”. Para. 59, “With on-the-fly conversion, subsequent to executing the data definition language (DDL) statements, a column may be associated with new metadata (e.g., the type was changed from int to varchar). Thus, loading a "new" data page may encounter the new metadata (type varchar) and interpret the data as-is. However, if an "old" data page was written before the data definition language statement is read, the reader may determine that there is no such int column in the table and will follow links between metadata versions to find out that the type needs to be converted from int to varchar. At this time, on-demand and on-the-fly, the data being loaded (integer values) may be converted into the data actually requested by the query processor (varchar values).”. Para. 61, “Analytical processing (e.g., on-line analytical processing (OLAP)) may include, for example, the query engine 115, executing queries that require evaluating (e.g., drill up, drill down, slice and dice, aggregate, sort, calculate key figures, hierarchies, and/or the like) the data stored in the hybrid transactional analytical processing database 110.”. Para. 69, “upon loading all of the columns required by all of the column sets associated with the first query Q1 and the second query Q2, the query engine 115 may evaluate the predicates stored in the shared buffer and send the respective results of the first query Q1 and the second query Q2 to the corresponding result sets in the shared buffer. In the event the scan reaches the end of the database table with queries remaining in the query set associated with the scan, the scanning of the database table may resume from the beginning. When the scan reaches a point at which a particular query was added to the query set associated with the scan, that query may be removed from query set and considered complete (e.g., entire database table was scanned).”.).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Schreter into the combined method of Lalsangi, Taranov and Phelan by including the visibility information such that the data page can be merged based on the load factor of the data page as disclosed by Schreter (Para. 56). One of the ordinary skills in the art would have motivated to make this modification in order to process query operating on the one or more predicate columns and the one or more aggregate columns by using the merge data based on the load factor of the data page as suggested by Schreter (Para. 20).
As to claims 5 and 15, the claims are rejected for the same reasons as claims 1 and 11 above. In addition, Schreter discloses wherein the column file format comprises a Parquet file format, wherein transforming the blob file further comprises writing rowsets and schema metadata into a Parquet file, and wherein the operations further comprise performing type derivation based on the rowsets and performing encoding for each column of data of the Parquet file (Para. 48, “Additional in-memory structures to provide optimal transactional processing and analytical processing performance may include a buffer cache for loaded data pages, columnar buffers for storing newly received data (e.g., inserts, updates, and/or the like), and a copy of the page directory identifying the contents of the data pages.”. Para. 51, “As shown in FIG. 3A, the memory 140 may also include one or more columnar buffers 340 storing newly received data (e.g., inserts, updates, and/or the like) for one or more columns in a database table. For example, the memory 140 may include one column buffer for each column of the database table.”. Thus, the column file format comprises a Parquet file format, wherein transforming the blob file further comprises writing rowsets and schema metadata into a Parquet file, and wherein the operations further comprise performing type derivation based on the rowsets and performing encoding for each column of data of the Parquet file.).
Allowable Subject Matter
10. As to claims 6 and 16, claims 6 and 16 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
11. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Newman et al. (US 2017/0139914 A1) teaches electronic mail data modeling for efficient indexing.
Kaplan et al. (US 2006/0248038 A1) teaches system and method of handling file metadata.
Charlet et al. (US 2020/0104386 A1) teaches editing and correcting structural metadata associated a binary large object (BLOB).
12. Any inquiry concerning this communication or earlier communications from the examiner should be directed to MOHAMMAD SOLAIMAN BHUYAN whose telephone number is (571)272-7843. The examiner can normally be reached on Monday - Friday 9:00am-5:00pm 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, Charles Rones can be reached on 571-272-4085. The fax phone number for the organization where this application or proceeding is assigned is 571 -273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Mohammad S Bhuyan/Examiner, Art Unit 2168
/CHARLES RONES/Supervisory Patent Examiner, Art Unit 2168
Prosecution Insights