DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim 1-8, 12, 17 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Vishwanath, Nittor et al(PGPUB Document No. 20260080083 ), hereafter referred as to “Vishwanath”, in view of Diaconu, Christian et al (PGPUB Document No. 20250068605), hereafter, referred to as “Diaconu”, in view of Onstott, Carr et al (US Patent No. 11803577), hereafter, referred to as “Onstott”, in further view of Barber, Ronald et al (PGPUB Document No. 20200372004), hereafter, referred to as “Barber”.
Claim 1, Vishwanath teaches A cloud-based customer relationship management (CRM) data storage system with query support(Vishwanath, para 0042 and 0044 disclose a cloud-based CRM system “the software application 114 may include one or more web-based programs configured to provide customer relationship management (CRM)”), wherein the system comprises: a memory storing one or more processor-executable routines; and a processor communicatively coupled to the memory, the processor configured to execute the one or more processor-executable routines to(Vishwanath, Fig. 13 further teaches a computing system comprising of processor, memories and storages):
generate index files for the converted source data(Vishwanath, para 0106 further discloses an index being generated “database information may be transmitted to the indexer 1194. Indexer 1194 may provide an index of information available in the database 1190 and/or QFS 1192. The index information may be provided to Fileforce servers 1186 and/or the QFS 1192”);
store converted source data and corresponding index files for each customer using a blob storage(Vishwanath, para 0102 discloses converted source data and index are in blob storage “The content search servers 1168 may provide query and indexer functions. For example, the functions provided by the content search servers 1168 may allow users to search through content stored in the on-demand service environment. The Fileforce servers 1186 may manage requests for information stored in the Fileforce storage 1198. The Fileforce storage 1198 may store information such as documents, images, and basic large objects (BLOBs)”);
receive a data query from one or more customers, wherein the data query comprises one or more query parameters(Vishwanath, para 0076 discloses request/receiving a query from the user with desired parameters or fields “The query 810 corresponds to an access request from a ……….. the query 810 may be formatted as a SQL query that includes one or more SQL statements for performing an action with respect to a particular data resource. For instance, the query 810 may include a SQL SELECT statement indicating which fields of a table are to be retrieved for output to the user”);
But Vishwanath don’t explicitly teach initiate a data backup operation for one or more customers of the cloud-based data storage system, receive source data corresponding to the one or more customers, wherein the source data comprises at least one of data schema, records/CRM data, and blob data; transform the received source data into a columnar storage format to generate converted source data; store versioning data for the source data using a database; identify index files and/or data files to be scanned from the converted source data based on the one or more query parameters and the versioning data; scan the identified index files and/or data files to generate data query results.
However, in the same field of endeavor of data conversion to columnar format Diaconu teaches initiate a data backup operation for one or more customers of the cloud-based data storage system(Diaconu, para 0030 discloses backup or replication of full data and incremental delta “the blob workers are configured to replicate the chunks from key-value store to blob storage (e.g., S3). In some example embodiments, the blob workers replicate the chunks as two types of files, including (1) a snapshot file, and (2) a delta file. The snapshot file comprises all key-value pairs of a specific key-value storage device version”; where Vishwanath in para 0042 and 0044 disclose cloud based storage for customers), receive source data corresponding to the one or more customers, wherein the source data comprises at least one of data schema, records/CRM data, and blob data(Diaconu, para 0230 discloses conversion of BLOB into Parquet format “the execution node can transform the blob file transforms into a columnar file format (e.g., Parquet)”; para 0250~0251 further teach use of data schema during the parquet conversion “ParquetWriter::open( ) initializes the writer using the given path, an optionally provided encryption key, and the schema of the file. [0251] ParquetWriter::writeRowsets( ) then takes all rowsets (managed by the caller) as input, and writes them to the Parquet file. Additionally it will save the metadata (in the form of key-value pairs) in the Parquet file, too. These rowsets must have colsets specified as the schema”; where Vishwanath 0042 and 0044 disclose cloud based storage for customers); transform the received source data into a columnar storage format to generate converted source data(Diaconu, para 0230 discloses conversion of source data into columnar parquet format “the execution node can transform the blob file transforms into a columnar file format (e.g., Parquet)”);
Therefore, it would have been obvious to one of skill in the art before the effective filing date of the invention to incorporate the feature of converting BLOB data into columnar format of Diaconu into conversion of data into columnar format of Vishwanath to produce an expected result of converting BLOB data. The modification would be obvious as one of ordinary skill in the art would be motivated to convert BLOB data into parquet format to speed up query processing (Diaconu, para 0218).
But Vishwanath and Diaconu don’t explicitly teach store versioning data for the source data using a database; identify index files and/or data files to be scanned from the converted source data based on the one or more query parameters and the versioning data; scan the identified index files and/or data files to generate data query results.
However, in the same field of endeavor of index based searching Onstott teaches store versioning data for the source data using a database(Onstott, Fig. 2 col 5: 39-44 disclose storing of version data in a database/data storage “the indices 220 may be stored in other data storage locations, such as provided by other or external services, etc. In some aspects, data storage service 224 may maintain or store historical information, including past version information, of various data, including parent and child documents 106, 108, 212, and/or indices 220 to provide a complete history of customer data 226”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of storing versioning data of Onstott into conversion of data into columnar format of Vishwanath and Diaconu to produce an expected result of storing version data for later retrieval. The modification would be obvious because one of ordinary skill in the art would be motivated to implement an index having parent-child relationships of contents for a robust search functionality built within the index(Onstott, abstract).
But Vishwanath, Diaconu and Onstott don’t explicitly teach identify index files and/or data files to be scanned from the converted source data based on the one or more query parameters and the versioning data; scan the identified index files and/or data files to generate data query results.
However, in the same field of endeavor of columnar storage of data Barber teaches identify index files and/or data files to be scanned from the converted source data based on the one or more query parameters and the versioning data(Barber, para 0122 discloses querying on index with version information “The hybrid index 200 created and maintained in this manner facilitates processing queries in an efficient manner compared to existing technologies, and as described herein, facilitates a multi-zone queries. Because the hybrid index 200 is a multi-version index, the query has to specify a query timestamp (queryTS), and only the most recent version for each matching key is returned, i.e., the version with largest beginTS 230 such that beginTS≤queryTS”); scan the identified index files and/or data files to generate data query results(Barber, Fig. 14 and para 0122 discloses querying on index with version information and returning identified sought data set as result “Searching a single run returns the most recent version for each matching key in that index run 250 for a received query, at 1402. The first matching key in the single run is first located, at 1408”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of querying on index for result retrieval of Barber into conversion of data into columnar format of Vishwanath, Diaconu and Onstott to produce an expected result of obtaining sought contents using index. The modification would be obvious because one of ordinary skill in the art would be motivated to update and merge index for improved query performance(Barber, para 0103).
Regarding, claim 2, Vishwanath, Diaconu, Onstott and Barber teach all the limitations of claim 1 and Diaconu teaches wherein the processor is configured to perform a full data backup or an incremental data backup operation for the one or more customers of the cloud-based data storage system(Diaconu, para 0030 discloses backup or replication of full data and incremental delta “the blob workers are configured to replicate the chunks from key-value store to blob storage (e.g., S3). In some example embodiments, the blob workers replicate the chunks as two types of files, including (1) a snapshot file, and (2) a delta file. The snapshot file comprises all key-value pairs of a specific key-value storage device version”; where Vishwanath in para 0042 and 0044 disclose cloud based storage for customers).
Regarding, claim 3, Vishwanath, Diaconu, Onstott and Barber teach all the limitations of claim 1 and Diaconu further teaches wherein the processor is configured to: receive source data corresponding to a plurality of data snapshots for each customer(Diaconu, para 0031 discloses receiving source snapshots of data “request is received from a client (e.g., from execution nodes of a client database account), the hybrid system 230 activates the blob manager and blob workers to generate a list of pointers of what files need to be retrieved using the snapshot and delta files”);
initiate retrieval of data for each version and/or data snapshot once a previous version and/or data snapshot is completed(Diaconu, para 0031 further discloses retrieval of data snapshots “the hybrid system 230 activates the blob manager and blob workers to generate a list of pointers of what files need to be retrieved using the snapshot and delta files. That is, instead of reading the rows directly, the pointer data (e.g., snapshot file, deltas) is sent to the client (e.g., to the clients execution nodes) and the client-side performs the actual processing of the read request to reconstruct the requested rows using a plurality of nodes to greatly speed up response performance”).
Regarding, claim 4, Vishwanath, Diaconu, Onstott and Barber teach all the limitations of claim 1 and Diaconu further teaches wherein the processor is configured to transform the received source data into the columnar storage format using the data schema and blob data, and wherein the columnar storage format comprises a parquet format (Diaconu, para 0230 discloses conversion of BLOB into Parquet format “the execution node can transform the blob file transforms into a columnar file format (e.g., Parquet)”; para 0250~0251 further teach use of data schema during the parquet conversion “ParquetWriter::open( ) initializes the writer using the given path, an optionally provided encryption key, and the schema of the file. [0251] ParquetWriter::writeRowsets( ) then takes all rowsets (managed by the caller) as input, and writes them to the Parquet file. Additionally it will save the metadata (in the form of key-value pairs) in the Parquet file, too. These rowsets must have colsets specified as the schema”).
Regarding, claim 5, Vishwanath, Diaconu, Onstott and Barber teach all the limitations of claim 1 and Onstott further teaches wherein each of the index files comprises a primary key column, one or more foreign key columns, data file handles, or combinations thereof(Onstott, col 2:33-36 discloses identifier or foreign key to link between parent and child contents “the child document may be indexed in a child index. The child document is associated with an identifier of the parent document in the child index”);and wherein the processor is further configured to identify parent-child relationships of the data using the index files for data retrieval (Onstott, col 2:3-7 discloses identifier in the index to identify parent-child relationships “In order to provide more robust search functionality for data including parent/child documents, the described systems and techniques may link parent and child documents in a parent document index using identifiers in the corresponding documents”).
Regarding, claim 6, Vishwanath, Diaconu, Onstott and Barber teach all the limitations of claim 5 and Barber further teaches wherein the processor is configured to merge a plurality of index files for each version and corresponding data combination (Barber, para 0104 discloses merging of indexes “The index maintenance operations further include index merge. Index runs 250 are periodically merged to form a larger index run 250 to bound the number of runs 250 and improve the query performance”).
Regarding, claim 7, Vishwanath, Diaconu, Onstott and Barber teach all the limitations of claim 1 and Vishwanath further teaches wherein the processor is further configured to: determine if search is required to be performed on one or more columns of the converted source data(Vishwanath, para 0076 discloses request/receiving a query from the user with desired parameters or fields/column with query command (SELECT command) “The query 810 corresponds to an access request from a ……….. the query 810 may be formatted as a SQL query that includes one or more SQL statements for performing an action with respect to a particular data resource. For instance, the query 810 may include a SQL SELECT statement indicating which fields of a table are to be retrieved for output to the user”);
Regarding, claim 8, Vishwanath, Diaconu, Onstott and Barber teach all the limitations of claim 1 and Vishwanath further teaches wherein the processor is further configured to: determine if search is required to be performed on one or more columns of the converted source data(Vishwanath, para 0076 discloses request/receiving a query from the user with desired parameters or fields/column with query command (SELECT command) “The query 810 corresponds to an access request from a ……….. the query 810 may be formatted as a SQL query that includes one or more SQL statements for performing an action with respect to a particular data resource. For instance, the query 810 may include a SQL SELECT statement indicating which fields of a table are to be retrieved for output to the user”);
Barber further teaches identify one or more index files to be scanned if it is determined that the search is to be performed on the one or more columns (Barber, para 0122 discloses querying on index with version information “The hybrid index 200 created and maintained in this manner facilitates processing queries in an efficient manner compared to existing technologies, and as described herein, facilitates a multi-zone queries. Because the hybrid index 200 is a multi-version index, the query has to specify a query timestamp (queryTS), and only the most recent version for each matching key is returned, i.e., the version with largest beginTS 230 such that beginTS≤queryTS”); and identify data files to be scanned for other respective columns of the converted source data (Barber, Fig. 14 and para 0122 discloses querying on index with version information and returning identified sought data set as result “Searching a single run returns the most recent version for each matching key in that index run 250 for a received query, at 1402. The first matching key in the single run is first located, at 1408”).
Regarding, claim 12, Vishwanath, Diaconu and Barber teach all the limitations of claim 11 and Vishwanath further teaches a blob storage configured to store converted source data and corresponding index files for each customer(Vishwanath, para 0102 discloses converted source data and index are in blob storage “The content search servers 1168 may provide query and indexer functions. For example, the functions provided by the content search servers 1168 may allow users to search through content stored in the on-demand service environment. The Fileforce servers 1186 may manage requests for information stored in the Fileforce storage 1198. The Fileforce storage 1198 may store information such as documents, images, and basic large objects (BLOBs)”);
and an output module configured to present the data query results to a user of the system (Vishwanath, para 0077 discloses query result output to users “The modified query 820 may be input to the compute engine for execution with respect to the contents of the datastore 122. Execution results 830 may be returned to the software application 114 for communication to the user”).
But Vishwanath, Diaconu and Barber don’t explicitly teach wherein the system further comprises: a relational database configured to store versioning data for the source data;
However, in the same field of endeavor of index based searching Onstott teaches wherein the system further comprises: a relational database configured to store versioning data for the source data(Onstott, Fig. 2 col 5: 39-44 disclose storing of version data in a database/data storage “the indices 220 may be stored in other data storage locations, such as provided by other or external services, etc. In some aspects, data storage service 224 may maintain or store historical information, including past version information, of various data, including parent and child documents 106, 108, 212, and/or indices 220 to provide a complete history of customer data 226”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of storing versioning data to storage of Onstott into conversion of data into columnar format of Vishwanath, Diaconu and Barber to produce an expected result of storing data for later retrieval. The modification would be obvious because one of ordinary skill in the art would be motivated to implement an index having parent-child relationships of contents for a robust search functionality built within the index(Onstott, abstract).
Claim 17, Vishwanath teaches A method of providing query support in a cloud-based (CRM) data storage system, the method comprising (Vishwanath, para 0042 and 0044 disclose a cloud-based CRM system “the software application 114 may include one or more web-based programs configured to provide customer relationship management (CRM)”):
generating index files for the converted source data (Vishwanath, para 0106 further discloses an index being generated “database information may be transmitted to the indexer 1194. Indexer 1194 may provide an index of information available in the database 1190 and/or QFS 1192. The index information may be provided to Fileforce servers 1186 and/or the QFS 1192”);
receiving a data query from one or more customers, wherein the data query having one or more query parameters (Vishwanath, para 0076 discloses request/receiving a query from the user with desired parameters or fields “The query 810 corresponds to an access request from a ……….. the query 810 may be formatted as a SQL query that includes one or more SQL statements for performing an action with respect to a particular data resource. For instance, the query 810 may include a SQL SELECT statement indicating which fields of a table are to be retrieved for output to the user”);
But Vishwanath don’t explicitly teach initiating a data backup operation for one or more customers of the cloud-based data storage system, receiving source data corresponding to the one or more customers, wherein the source data comprises at least one of data schema, records/CRM data and blob data; transforming the received source data into a columnar storage format to generate converted source data; storing versioning data and corresponding index files for each customer; identifying index files and/or data files to be scanned from the converted source data based on the one or more query parameters and the versioning data; scanning the identified index files and/or data files to generate data query results.
However, in the same field of endeavor of data conversion to columnar format Diaconu teaches initiating a data backup operation for one or more customers of the cloud-based data storage system(Diaconu, para 0030 discloses backup or replication of full data and incremental delta “the blob workers are configured to replicate the chunks from key-value store to blob storage (e.g., S3). In some example embodiments, the blob workers replicate the chunks as two types of files, including (1) a snapshot file, and (2) a delta file. The snapshot file comprises all key-value pairs of a specific key-value storage device version”; where Vishwanath in para 0042 and 0044 disclose cloud based storage for customers), receiving source data corresponding to the one or more customers, wherein the source data comprises at least one of data schema, records/CRM data and blob data(Diaconu, para 0230 discloses conversion of BLOB into Parquet format “the execution node can transform the blob file transforms into a columnar file format (e.g., Parquet)”; para 0250~0251 further teach use of data schema during the parquet conversion “ParquetWriter::open( ) initializes the writer using the given path, an optionally provided encryption key, and the schema of the file. [0251] ParquetWriter::writeRowsets( ) then takes all rowsets (managed by the caller) as input, and writes them to the Parquet file. Additionally it will save the metadata (in the form of key-value pairs) in the Parquet file, too. These rowsets must have colsets specified as the schema”; where Vishwanath 0042 and 0044 disclose cloud based storage for customers); transforming the received source data into a columnar storage format to generate converted source data(Diaconu, para 0230 discloses conversion of source data into columnar parquet format “the execution node can transform the blob file transforms into a columnar file format (e.g., Parquet)”);
Therefore, it would have been obvious to one of skill in the art before the effective filing date of the invention to incorporate the feature of converting BLOB data into columnar format of Diaconu into conversion of data into columnar format of Vishwanath to produce an expected result of converting BLOB data. The modification would be obvious as one of ordinary skill in the art would be motivated to convert BLOB data into parquet format to speed up query processing (Diaconu, para 0218).
But Vishwanath and Diaconu don’t explicitly teach storing versioning data and corresponding index files for each customer; identifying index files and/or data files to be scanned from the converted source data based on the one or more query parameters and the versioning data; scanning the identified index files and/or data files to generate data query results.
However, in the same field of endeavor of index based searching Onstott teaches storing versioning data and corresponding index files for each customer (Onstott, Fig. 2 col 5: 39-44 disclose storing of version data in a database/data storage “the indices 220 may be stored in other data storage locations, such as provided by other or external services, etc. In some aspects, data storage service 224 may maintain or store historical information, including past version information, of various data, including parent and child documents 106, 108, 212, and/or indices 220 to provide a complete history of customer data 226”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of storing versioning data of Onstott into conversion of data into columnar format of Vishwanath and Diaconu to produce an expected result of storing version data for later retrieval. The modification would be obvious because one of ordinary skill in the art would be motivated to implement an index having parent-child relationships of contents for a robust search functionality built within the index(Onstott, abstract).
But Vishwanath, Diaconu and Onstott don’t explicitly teach identifying index files and/or data files to be scanned from the converted source data based on the one or more query parameters and the versioning data; scanning the identified index files and/or data files to generate data query results.
However, in the same field of endeavor of columnar storage of data Barber teaches identifying index files and/or data files to be scanned from the converted source data based on the one or more query parameters and the versioning data(Barber, para 0122 discloses querying on index with version information “The hybrid index 200 created and maintained in this manner facilitates processing queries in an efficient manner compared to existing technologies, and as described herein, facilitates a multi-zone queries. Because the hybrid index 200 is a multi-version index, the query has to specify a query timestamp (queryTS), and only the most recent version for each matching key is returned, i.e., the version with largest beginTS 230 such that beginTS≤queryTS”); scanning the identified index files and/or data files to generate data query results(Barber, Fig. 14 and para 0122 discloses querying on index with version information and returning identified sought data set as result “Searching a single run returns the most recent version for each matching key in that index run 250 for a received query, at 1402. The first matching key in the single run is first located, at 1408”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of querying on index for result retrieval of Barber into conversion of data into columnar format of Vishwanath, Diaconu and Onstott to produce an expected result of obtaining sought contents using index. The modification would be obvious because one of ordinary skill in the art would be motivated to update and merge index for improved query performance(Barber, para 0103).
Regarding, claim 19, Vishwanath, Diaconu, Onstott, Barber and Tu teach all the limitations of claim 17 and Barber further teaches further comprising merging data query results to handle multiple versions of results, wherein the processor is configured to select a latest version of data record from the multiple versions(Barber, Fig. 14 and para 0122 discloses querying on index with version information and returning identified sought data set as result “Searching a single run returns the most recent version for each matching key in that index run 250 for a received query, at 1402. The first matching key in the single run is first located, at 1408”).
Regarding, claim 20, Vishwanath, Diaconu, Onstott and Barber teach all the limitations of claim 17 and Diaconu teaches comprising performing a full data backup or an incremental backup operation for the one or more customers (Diaconu, para 0030 discloses backup or replication of full data and incremental delta “the blob workers are configured to replicate the chunks from key-value store to blob storage (e.g., S3). In some example embodiments, the blob workers replicate the chunks as two types of files, including (1) a snapshot file, and (2) a delta file. The snapshot file comprises all key-value pairs of a specific key-value storage device version”; where Vishwanath in para 0042 and 0044 disclose cloud based storage for customers).
Claim 9-10 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Vishwanath, Nittor et al(PGPUB Document No. 20260080083 ), hereafter referred as to “Vishwanath”, in view of Diaconu, Christian et al (PGPUB Document No. 20250068605), hereafter, referred to as “Diaconu”, in view of Onstott, Carr et al (US Patent No. 11803577), hereafter, referred to as “Onstott”, in view of Barber, Ronald et al (PGPUB Document No. 20200372004), hereafter, referred to as “Barber”, in further view of Tu, Yicheng et al (US Patent No. 11176631), hereafter, referred to as “Tu”.
Regarding claim 9, Vishwanath, Diaconu, Onstott and Barber teach all the limitations of claim 8, but don’t explicitly teach wherein the processor is further configured to initiate the search using a batch processing tool and concurrently retrieve data based on the identified index files and data files.
However, in the same field of endeavor of query execution on index Tu teaches wherein the processor is further configured to initiate the search using a batch processing tool and concurrently retrieve data based on the identified index files and data files (Tu, col 4:32-38 discloses running batch query concurrently on parallel indexing “Parallel Indexing for Concurrent Spatial data processing (G-PICS) framework for high high performance spatial data management and concurrent query processing. ….another strategy is to parallelize multiple queries running concurrently. Batched query processing, due to the effective sharing of computing resources, has been heavily studied in the database field and is often utilized for large-scale web search on GPUs”; where Vishwanath in para 0042 and 0044 disclose cloud based storage for customers).
Therefore, it would have been obvious to one of skill in the art before the effective filing date of the invention to incorporate the feature of concurrently running batch queries of Tu into running queries on converted columnar data of Vishwanath, Diaconu, Onstott and Barber to produce an expected result of processing batch queries. The modification would be obvious as one of ordinary skill in the art would be motivated use query parallelism to effectively sharing the computer resources (Tu, col 4:32-38).
Regarding, claim 10, Vishwanath, Diaconu, Onstott, Barber and Tu teach all the limitations of claim 9 and Barber further teaches wherein the processor is further configured to merge data query results to handle multiple versions of results, wherein the processor is configured to select a latest version of data record from the multiple versions (Barber, Fig. 14 and para 0122 discloses querying on index with version information and returning identified sought data set as result “Searching a single run returns the most recent version for each matching key in that index run 250 for a received query, at 1402. The first matching key in the single run is first located, at 1408”).
Regarding claim 18, Vishwanath, Diaconu, Onstott and Barber teach all the limitations of claim 17, but don’t explicitly teach further comprising initiating the scan using a batch processing tool to concurrently retrieve data based on the identified index files and data files.
However, in the same field of endeavor of query execution on index Tu teaches wherein the processor is further configured to initiate the search using a batch processing tool and concurrently retrieve data based on the identified index files and data files (Tu, col 4:32-38 discloses running batch query concurrently on parallel indexing “Parallel Indexing for Concurrent Spatial data processing (G-PICS) framework for high high performance spatial data management and concurrent query processing. ….another strategy is to parallelize multiple queries running concurrently. Batched query processing, due to the effective sharing of computing resources, has been heavily studied in the database field and is often utilized for large-scale web search on GPUs”; where Vishwanath in para 0042 and 0044 disclose cloud based storage for customers).
Therefore, it would have been obvious to one of skill in the art before the effective filing date of the invention to incorporate the feature of concurrently running batch queries of Tu into running queries on converted columnar data of Vishwanath, Diaconu, Onstott and Barber to produce an expected result of processing batch queries. The modification would be obvious as one of ordinary skill in the art would be motivated use query parallelism to effectively sharing the computer resources (Tu, col 4:32-38).
Claim 11 and 13-16 are rejected under 35 U.S.C. 103 as being unpatentable over Vishwanath, Nittor et al(PGPUB Document No. 20260080083 ), hereafter referred as to “Vishwanath”, in view of Diaconu, Christian et al (PGPUB Document No. 20250068605), hereafter, referred to as “Diaconu”, in further view of Barber, Ronald et al (PGPUB Document No. 20200372004), hereafter, referred to as “Barber”.
Claim 11, Vishwanath teaches A cloud-based (CRM) data storage system with query support, wherein the system comprises (Vishwanath, para 0042 and 0044 disclose a cloud-based CRM system “the software application 114 may include one or more web-based programs configured to provide customer relationship management (CRM)”): a memory storing one or more processor-executable routines; and a processor communicatively coupled to the memory, the processor configured to execute the one or more processor-executable routines to facilitate data backup and data retrieval operations for customer data, wherein the processor comprises(Vishwanath, Fig. 13 further teaches a computing system comprising of processor, memories and storages; para 0127 further discloses a system providing backup of tenants data “because many tenants may opt for access to an MTS rather than maintain their own system, redundancy, up-time, and backup are additional functions that may be implemented in the MTS” ): a client interface configured to receive source data corresponding to one or more customers(Vishwanath, para 0115 discloses an user interface to receive/access data “the user interface device can be used to access data and applications hosted by system 1216, and to perform searches on stored data, and otherwise allow a user to interact with various GUI pages that may be presented to a user”),
a data query engine configured to receive a data query from the one or more customers, wherein the data query comprises one or more query parameters and wherein the data query engine is configured to (Vishwanath, para 0076 discloses request/receiving a query from the user with desired parameters or fields “The query 810 corresponds to an access request from a ……….. the query 810 may be formatted as a SQL query that includes one or more SQL statements for performing an action with respect to a particular data resource. For instance, the query 810 may include a SQL SELECT statement indicating which fields of a table are to be retrieved for output to the user”):
But Vishwanath does not explicitly teach wherein the source data comprises at least one of data schema, records/CRM data and blob data; a data transformation module configured to transform the received source data into a columnar storage format to generate converted source data and generate index files for the converted source data; identify index files and/or data files to be scanned from the converted source data based on the one or more query parameters and versioning data; and scan the identified index files and/or data files to generate data query results.
However, in the same field of endeavor of data conversion to columnar format Diaconu teaches wherein the source data comprises at least one of data schema, records/CRM data and blob data (Diaconu, para 0230 discloses conversion of BLOB into Parquet format “the execution node can transform the blob file transforms into a columnar file format (e.g., Parquet)”; para 0250~0251 further teach use of data schema during the parquet conversion “ParquetWriter::open( ) initializes the writer using the given path, an optionally provided encryption key, and the schema of the file. [0251] ParquetWriter::writeRowsets( ) then takes all rowsets (managed by the caller) as input, and writes them to the Parquet file. Additionally it will save the metadata (in the form of key-value pairs) in the Parquet file, too. These rowsets must have colsets specified as the schema”; where Vishwanath 0042 and 0044 disclose cloud based storage for customers);
a data transformation module configured to transform the received source data into a columnar storage format to generate converted source data and generate index files for the converted source data (Diaconu, para 0230 discloses conversion of source data into columnar parquet format “the execution node can transform the blob file transforms into a columnar file format (e.g., Parquet)”; where para 0217 further discloses indexing on columnar or converted data “The columnar store is further associated with indexes to support efficient point lookups for operation workloads”);
Therefore, it would have been obvious to one of skill in the art before the effective filing date of the invention to incorporate the feature of converting BLOB data into columnar format of Diaconu into conversion of data into columnar format of Vishwanath to produce an expected result of converting BLOB data. The modification would be obvious as one of ordinary skill in the art would be motivated to convert BLOB data into parquet format to speed up query processing (Diaconu, para 0218).
But Vishwanath and Diaconu don’t explicitly teach identify index files and/or data files to be scanned from the converted source data based on the one or more query parameters and versioning data; and scan the identified index files and/or data files to generate data query results.
However, in the same field of endeavor of columnar storage of data Barber teaches identify index files and/or data files to be scanned from the converted source data based on the one or more query parameters and versioning data (Barber, para 0122 discloses querying on index with version information “The hybrid index 200 created and maintained in this manner facilitates processing queries in an efficient manner compared to existing technologies, and as described herein, facilitates a multi-zone queries. Because the hybrid index 200 is a multi-version index, the query has to specify a query timestamp (queryTS), and only the most recent version for each matching key is returned, i.e., the version with largest beginTS 230 such that beginTS≤queryTS”); and scan the identified index files and/or data files to generate data query results (Barber, Fig. 14 and para 0122 discloses querying on index with version information and returning identified sought data set as result “Searching a single run returns the most recent version for each matching key in that index run 250 for a received query, at 1402. The first matching key in the single run is first located, at 1408”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of querying on index for result retrieval of Barber into conversion of data into columnar format of Vishwanath and Diaconu to produce an expected result of obtaining sought contents using index. The modification would be obvious because one of ordinary skill in the art would be motivated to update and merge index for improved query performance(Barber, para 0103).
Regarding, claim 13, Vishwanath, Diaconu and Barber teach all the limitations of claim 11 and Diaconu further teaches wherein the processor further comprises a data backup module configured to perform a full data backup or an incremental data backup operation for the one or more customers of the cloud-based data storage system(Diaconu, para 0030 discloses backup or replication of full data and incremental delta “the blob workers are configured to replicate the chunks from key-value store to blob storage (e.g., S3). In some example embodiments, the blob workers replicate the chunks as two types of files, including (1) a snapshot file, and (2) a delta file. The snapshot file comprises all key-value pairs of a specific key-value storage device version”; where Vishwanath in para 0042 and 0044 disclose cloud based storage for customers).
Regarding, claim 14, Vishwanath, Diaconu and Barber teach all the limitations of claim 11 and Vishwanath further teaches wherein the client interface is configured to receive the source data from a customer database (Vishwanath, para 0115 discloses an user interface to receive/access data “the user interface device can be used to access data and applications hosted by system 1216, and to perform searches on stored data, and otherwise allow a user to interact with various GUI pages that may be presented to a user”).
Regarding, claim 15, Vishwanath, Diaconu, Onstott and Barber teach all the limitations of claim 11 and Diaconu further teaches wherein the data transformation module is configured to transform the received source data into one of a parquet format (Diaconu, para 0230 discloses conversion of BLOB into Parquet format “the execution node can transform the blob file transforms into a columnar file format (e.g., Parquet)”).
Regarding, claim 16, Vishwanath, Diaconu, Onstott and Barber teach all the limitations of claim 11 and Barber further teaches wherein the one or more query parameters comprise snapshot information, data object details, query commands, or combinations thereof (Barber, para 0104 discloses merging of indexes “The index maintenance operations further include index merge. Index runs 250 are periodically merged to form a larger index run 250 to bound the number of runs 250 and improve the query performance”).
Conclusion
Listed below are the prior arts made of record and not relied upon but are considered pertinent to applicant’s disclosure.
Xu et al (US 20110314027) – teaches querying on index for columnar data.
Oks et al(US 20110219020) – teaches index for columnar storage.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABDULLAH A DAUD whose telephone number is (469)295-9283. The examiner can normally be reached M~F: 9:30 am~6:30 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Amy Ng can be reached at 571-270-1698. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ABDULLAH A DAUD/Examiner, Art Unit 2164
/AMY NG/Supervisory Patent Examiner, Art Unit 2164
Prosecution Insights