Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
The Action is responsive to the Application filed on 9/16/2025. Claims 1-20 are pending claims. Claims 1, 9, and 17 are written in independent form.
Priority
Applicant’s claim for benefit of prior-filed provisional applications 63/695,774 (filed 9/17/2024) and 63/727,154 (filed 12/2/2024) under 35. U.S.C. 119(e) or under 35 U.S.C. 120, 121, or 365(c) is acknowledged.
Claim Interpretation
Claims 3, 11, and 19 recite the phrase “for execution on” which is being understood as the intent to execute on, but is not actively performing any execution step/limitation. Examiner suggests to amend the claim limitations to recite all of the steps in a positive manner.
Claims 3, 11, and 19 recite the limitation “Pushing down filter, projection, and aggregation operators to a file adapter for execution on column chunks of first table format files.” which is being interpreted to have a scope of “Pushing down filter, projection, and aggregation operators to a file adapter”. However, for the purpose of compact prosecution, the limitation is being addressed herein as if all of the steps are recited in a positive manner.
Claims 6 and 14 recite the phrase “to perform” which is being understood as the intent to perform, but is not actively performing any step/limitation. Examiner suggests to amend the claim limitations to recite all of the steps in a positive manner.
Claims 6 and 14 recite the limitation “federating Structured Query Language (SQL) queries to an external analytics engine via a Spark adapter to perform large-scale data transformations on the data stored in the data lake” which is being interpreted to have a scope of “federating Structured Query Language (SQL) queries to an external analytics engine via a Spark adapter”. However, for the purpose of compact prosecution, the limitation is being addressed herein as if all of the steps are recited in a positive manner.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 4, 6, 12, 14, and 20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding Claims 4, 12, and 20, the limitation “wherein the unified interface performs direct, in-situ query processing over files in the data lake without intermediate data movement” renders the claims indefinite because when analyzed in light of their corresponding parent independent claims 1, 9, and 17, each reciting “processing, by a processing engine, the queries over the data stored in the data lake…”, it is unclear which of the “unified interface” or the “processing engine” that is performing the query processing.For the purpose of compact prosecution and based on Paragraphs [0375]-[0378] of the present Specification, the query processing is understood as being performed by the query processing engine.
Regarding Claims 6 and 14, the phrase “…perform large-scale data transformations…” renders the claim indefinite because it is unclear what threshold makes the data transformations large-scale or not large-scale.
For the purpose of compact prosecution, claims 6 and 14 are being interpreted as reciting “…perform
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-patentable subject matter. The claimed invention is directed to one or more abstract ideas without significantly more. The judicial exception is not integrated into a practical application. The claims do not include additional elements that are sufficient to amount to significantly more than judicial exception. The eligibility analysis in support of these findings is provided below.
As per Claims 1, 9, and 17,
STEP 1:In accordance with Step 1 of the eligibility inquiry (as explained in MPEP 2106), the claimed system (claims 1-8), method (claims 9-16), and non-transitory machine-readable medium (claims 17-20) are directed to one of the eligible categories of subject matter and therefore satisfies Step 1.
STEP 2A Prong One:The independent claims 1, 9, and 17 recite the following limitations directed to an abstract idea:
Mapping the data stored in the data lake to one or more virtual representations in a cloud-based database management system;
The limitation recites a mental process of observation, evaluation, judgement, and/or opinion capable of being performed by the human mind, or by a human using a pen and paper, by observing and evaluating the data stored in the data lake and one or more virtual representations, and based on the observation and evaluation, making a judgement and/or opinion of a mapping of the data stored in the data lake to the one or more virtual representations.
Enabling access to the data stored in the data lake via the one or more virtual representations using queries;
The limitation recites a mental process of observation, evaluation, judgement, and/or opinion capable of being performed by the human mind, or by a human using a pen and paper, by observing and evaluating the data stored in the data lake via the one or more virtual representation, and based on the observation and evaluation, making a judgement and/or opinion to enable/allow access to the data via the one or more virtual representations using queries.
Processing, by a processing engine, the queries over the data stored in the data lake, including generating a logical plan and a physical plan that support in-situ processing over files in the data lake;
The limitation recites a mental process of observation, evaluation, judgement, and/or opinion capable of being performed by the human mind, or by a human using a pen and paper, by observing and evaluating the queries and the data stored in the data lake, and based on the observation and evaluation, making a judgement and/or opinion of a logical plan and a physical plan that support in-situ processing over files in the data lake.
STEP 2A Prong Two:Claim 1 recites that the steps are performed using “at least one hardware processor”, “a computer-readable medium”, “a cloud-based data platform”, “a cloud-based database management system”, and “a processing engine”, which is a high-level recitation of generic computer components and represents mere instructions to apply on a computer as in MPEP 2106.05(f), which does not provide integration into a practical application.
Claim 9 recites that the steps are performed using “a cloud-based data platform”, “a cloud-based database management system”, and “a processing engine”, which is a high-level recitation of generic computer components and represents mere instructions to apply on a computer as in MPEP 2106.05(f), which does not provide integration into a practical application.
Claim 17 recites that the steps are performed using “a non-transitory machine-readable medium”, “one or more processors”, “a cloud-based data platform”, “a cloud-based database management system”, and “a processing engine”, which is a high-level recitation of generic computer components and represents mere instructions to apply on a computer as in MPEP 2106.05(f), which does not provide integration into a practical application.
The claim recites the following additional elements:
Receiving a request to access data stored in a data lake implemented as a hyperscaler object store,
The limitation recites an insignificant extra solution activity as sending/receiving of data (ie. Mere data gathering) such as ‘obtaining information’ as identified in MPEP 2106.05(g) and does not provide integration into a practical application.
the data being stored in a first table format;
The limitation recites an insignificant extra-solution activity as selecting a particular type of data structure/format being used to represent “the data” as identified in MPEP 2106.05(g) and does not provide integration into a practical application.
Providing a unified interface for data operations for the data stored in the data lake;
The limitation recites an insignificant extra solution activity as sending/receiving of data (ie. Mere data gathering) such as ‘obtaining information’ as identified in MPEP 2106.05(g) and does not provide integration into a practical application.
Returning results of the queries to a user or application.
The limitation recites an insignificant extra solution activity as sending/receiving of data (ie. Mere data gathering) such as ‘obtaining information’ as identified in MPEP 2106.05(g) and does not provide integration into a practical application.
Viewing the additional limitations together and the claim as a whole, nothing provides integration into a practical application.
STEP 2B:
The conclusions for the mere implementation using a computer are carried over and does not provide significantly more.
With respect to “Receiving a request to access data stored in a data lake implemented as a hyperscaler object store,” identified as insignificant extra-solution activity above this is also WURC as court-identified see MPEP 2106.05(d)(II)(i).
With respect to “the data being stored in a first table format;” identified as insignificant extra-solution activity above this is also considered to be WURC as court-identified see MPEP 2106.05(d)(II)(iv).
With respect to “Providing a unified interface for data operations for the data stored in the data lake;” identified as insignificant extra-solution activity above this is also WURC as court-identified see MPEP 2106.05(d)(II)(i).
With respect to “Returning results of the queries to a user or application.” identified as insignificant extra-solution activity above this is also WURC as court-identified see MPEP 2106.05(d)(II)(i).
Looking at the claim as a whole does not change this conclusion and the claim is ineligible.
As per Dependent Claims 2-8, 10-16, and 18-20,
STEP 1:In accordance with Step 1 of the eligibility inquiry (as explained in MPEP 2106), the claimed system (claims 1-8), method (claims 9-16), and non-transitory machine-readable medium (claims 17-20) are directed to one of the eligible categories of subject matter and therefore satisfies Step 1.
STEP 2A Prong One:The dependent claims 2-8, 10-16, and 18-20 recite the following limitations directed to an abstract idea:
The limitation(s) of Dependent Claims 3, 11, and 19 includes the step(s) of:
Pushing down filter, projection, and aggregation operators to a file adapter for execution on column chunks of first table format files.
The limitation recites a mental process of observation, evaluation, judgement, and/or opinion capable of being performed by the human mind, or by a human using a pen and paper, by observing and evaluating column chunks of first table format files and filter, projection, and aggregation operators, and based on the observation and evaluation, making a judgement and/or opinion that filters, projects, and aggregates the column chunks of first table format files consistent with the operators.
The limitation(s) of Dependent Claims 4, 12, and 20 includes the step(s) of:
perform direct, in-situ query processing over files in the data lake without intermediate data movement.
The limitation recites a mental process of observation, evaluation, judgement, and/or opinion capable of being performed by the human mind, or by a human using a pen and paper, by observing and evaluating the queries and files stored in the data lake, and based on the observation and evaluation, making a judgement and/or opinion of a comparison of a query (or queries) over the files in the data lake in an in-situ manner, which is understood to be without moving or loading the data into a database first (without intermediate data movement).
The limitation(s) of Dependent Claims 5 and 13 includes the step(s) of:
Wherein mapping the data stored in the data lake to the one or more virtual representations comprises:
Creating virtual tables that reference first table format files via a remote source connection.
The limitation recites a mental process of observation, evaluation, judgement, and/or opinion capable of being performed by the human mind, or by a human using a pen and paper, by observing and evaluating the data stored in the data lake and one or more virtual representations, and based on the observation and evaluation, making a judgement and/or opinion of a mapping of the data stored in the data lake to the one or more virtual representations by creating tables that reference first table format files via a remote source connection.
The limitation(s) of Dependent Claims 6 and 14 includes the step(s) of:
perform data transformations on the data stored in the data lake.
The limitation recites a mathematical concept of executing a mathematical formula/function that takes as input data stored in the data lake and executes data transformations on the data stored in the data lake.
The limitation(s) of Dependent Claims 7 and 15 includes the step(s) of:
Authenticating the received request using X.509 certificates or web tokens before providing access to the data stored in the data lake.
The limitation recites a mental process of observation, evaluation, judgement, and/or opinion capable of being performed by the human mind, or by a human using a pen and paper, by observing and evaluating the received request and X.509 certificates or web tokens, and based on the observation and evaluation, making a judgement and/or opinion that the received request is authentic before providing access to the data stored in the data lake.
The limitation(s) of Dependent Claims 8 and 16 includes the step(s) of:
Generating pre-signed URLs to enable direct access to the hyperscaler object store for data retrieval.
The limitation recites a mental process of observation, evaluation, judgement, and/or opinion capable of being performed by the human mind, or by a human using a pen and paper, by observing and evaluating the hyperscaler object store, and based on the observation and evaluation, making a judgement and/or opinion of pre-signed URLs that would enable direct access to the hyperscaler object store for data retrieval.
STEP 2A Prong Two:The claim(s) recite the following additional elements:
The limitation(s) of Dependent Claims 2, 10, and 18 includes the step(s) of:
Wherein the first table format comprises at least one of Apache Parquet, Delta Lake, or Apache Iceberg.
The limitation recites an insignificant extra-solution activity as selecting a particular type of data structure/format being used to represent “the first table format” as identified in MPEP 2106.05(g) and does not provide integration into a practical application.
The limitation(s) of Dependent Claims 3, 11, and 19 includes the step(s) of:
Pushing down filter, projection, and aggregation operators to a file adapter
The limitation recites an insignificant extra solution activity as sending/receiving of data (ie. Mere data gathering) such as ‘obtaining information’ as identified in MPEP 2106.05(g) and does not provide integration into a practical application.
The limitation(s) of Dependent Claims 5 and 13 includes the step(s) of:
Creating virtual tables in the cloud-based database management system
The limitation recites performing the step “in the cloud-based database management system” and the tables being “virtual tables”, which is a high-level recitation of generic computer components and represents mere instructions to apply on a computer as in MPEP 2106.05(f), which does not provide integration into a practical application.
The limitation(s) of Dependent Claims 6 and 14 includes the step(s) of:
Federating Structured Query Language (SQL) queries to an external analytics engine via a Spark adapter
The limitation recites an insignificant extra solution activity as sending/receiving of data (ie. Mere data gathering) such as ‘obtaining information’ as identified in MPEP 2106.05(g) and does not provide integration into a practical application.
Viewing the additional limitations together and the claim as a whole, nothing provides integration into a practical application.
STEP 2B:
The conclusions for the mere implementation using a computer are carried over and does not provide significantly more.
With respect to Claims 2, 10 and 18 reciting “Wherein the first table format comprises at least one of Apache Parquet, Delta Lake, or Apache Iceberg.” identified as insignificant extra-solution activity above this is also WURC as court-identified see MPEP 2106.05(d)(II)(iv).
With respect to Claims 3, 11, and 19 reciting “Pushing down filter, projection, and aggregation operators to a file adapter” identified as insignificant extra-solution activity above this is also WURC as court-identified see MPEP 2106.05(d)(II)(i).
With respect to Claims 6 and 14 reciting “Federating Structured Query Language (SQL) queries to an external analytics engine via a Spark adapter” identified as insignificant extra-solution activity above this is also WURC as court-identified see MPEP 2106.05(d)(II)(i).
Looking at the claim as a whole does not change this conclusion and the claim is ineligible.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 3-5, 7, 9, 11-13, 15, 17, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Karl et al. (U.S. Pre-Grant Publication No. 2021/0089540, hereinafter referred to as Karl) and further in view of Mehta et al. (U.S. Pre-Grant Publication No. 2026/0037658, hereinafter referred to as Mehta).
Regarding Claim 1:
Karl teaches a system comprising:
At least one hardware processor (Para. [0151]); and
A computer-readable medium storing instructions that, when executed by the at least one hardware processor, cause the at least one hardware processor to perform operations comprising (Paras. [0013] & [0151]-[0153]):
Receiving, at a cloud-based data platform, a request to access data stored in a data lake implemented as a hyperscaler object store,
Karl teaches “Requests to access data that is not replicated can be serviced in another manner, such as by federation (e.g., retrieving data from a remote data source, including using the Smart Data Access protocol of SAP SE, of Walldorf, Germany) or retrieving table data from a cache.” (Para. [0042]) and “When data associated with the virtual table schema 160 is requested, the cache 204 can be first checked for the requested data and, if the data is not present, the data can be requested from the remote table 144 using the value for the remote table in the table pointer 162.” (Para. [0066]).
Karl further teaches “The data dictionary 134 can include definitions (or schemas) for different types of database objects, such as schemas for tables or views. Although the following discussion references tables for ease of explanation, it should be appreciated that the discussion can apply to other types of database objects, particularly database objects that are associated with retrievable data, such as materialized views. A table schema can include information such as the name of the table, the number of attributes (or columns or fields) in the table, the names of the attributes, the data types of the attributes, an order in which the attributes should be displayed, primary key values, foreign keys, associations to other database objects, partition information, or replication information.” (Para. [0050] and “The data dictionary 134 can include replica table schemas 138, which can represent tables where at least a portion of the table data is stored in the central computing system 110 (or which is primarily managed by a database management system of the central computing system, even if stored other than on the central computing system, such as being stored in a data lake or in another cloud service).” (Para. [0051]).
Karl is understood as teaching a hyperscaler object store because a hyperscaler object store is merely understood to be object storage (Karl – Para. [0050]) that offers scalable cloud computing services (cloud computing services – Paras. [0160]-[0161]).
the data being stored in a first table format;
Karl teaches “The systems can be of different types—such as storing data in different formats (e.g., a relational database versus a database that stores JAVA documents) or storing data using different database management systems (e.g., using software and/or hardware provided by different vendors). Even where data is stored in the same format and using software of the same vendors, differences can exist in what data is stored at a particular location and the schema used to store it.” (Para. [0003]).
Karl further teaches “tables that are formatted for use in a row store, tables that are formatted for use in a column store, or tables that are associated with a virtual table schema (and thus can have variable types of target tables, such as remote tables, replica tables, or cached tables).” (Para. [0102])
Providing, by the cloud-based data platform, a unified interface for data operations for the data stored in the data lake;
Karl teaches “a federated database includes functionality to make data from multiple, distinct database management systems (or other data sources) available through a common platform or interface” (Par.a [0004])
Mapping the data stored in the data lake to one or more virtual representations in a cloud-based database management system;
Karl teaches “virtual tables, where a virtual table can be represented by a database schema object (e.g., an entry in a data dictionary) which includes a logical pointer to a table (e.g., containing the actual data associated with the table schema) that should be used with the table definition/schema object. The logical pointer can be dynamically updated between two or more locations. Locations can include a table on a remote computing system (which can be a federated database), a replica table that replicates data from a remote table on the remote computing system, a local table, or a cached table” (Para. [0037])
Processing, by a processing engine, the queries over the data stored in the data lake, including generating a logical plan and a physical plan that support processing over files in the data lake; and
Karl teaches “When a query is executed, the query is processed by the query processor 120, including executing the query using the query executor 124 to obtain data from one or both of the data store 142 of the remote database system 112 or the data store 168 of the central computing system 110. Query results can be returned to the application 108.” (Para. [0058]) and “The central computing system 110 can include a query processor 120. The query processor 120 can include multiple components, including a query optimizer 122 and a query executor 124. The query optimizer 122 can be responsible for determining a query execution plan 126 for a query to be executed using the central computing system 110. The query plan 126 generated by the query optimizer 122 can include both a logical plan indicating, for example, an order of operations to be executed in the query (e.g., joins, projections) and a physical plan for implementing such operations” (Para. [0048])Karl further teaches “the data lake 410 can store replica tables 414. The replica tables 414 can be analogous to the replica tables 166. As shown, the data lake 410 is separate from the central computing system 110. In other cases, the data lake 410 can be integrated into the central computing system 110. (Para. [0017]).
Returning results of the queries to a user or application.
Karl teaches “When a query is executed, the query is processed by the query processor 120, including executing the query using the query executor 124 to obtain data from one or both of the data store 142 of the remote database system 112 or the data store 168 of the central computing system 110. Query results can be returned to the application 108.” (Para. [0058])
Karl explicitly teaches all of the elements of the claimed invention as recited above except:
Enabling access to the data stored in the data lake via the one or more virtual representations using queries;
in-situ processing over files in the data lake;
However, in the related field of endeavor of data querying and processing, Mehta teaches:
Enabling access to the data stored in the data lake via the one or more virtual representations using queries;
Mehta teaches “The federated identity and token provider service 104f may be a service layer that is configured to facilitate authentication/authorization for accessing data quality metrics and/or leveraging an FQI 106f. In various embodiments, the federated identity and token provider service 104f may obtain identification token(s) that the processing platform 104 may provide to the execution platform 106, and that the DQ executor 106r can use for authorization to the FQI 106f.” (Para. [0053])
in-situ processing over files in the data lake;
Mehta teaches “In-situ processing: Refers to processing of data in or within its original location or environment, which reduces, minimizes, or avoids data movement and enhances data security.” (Para. [0018]) and “The in-situ execution module may manage execution requests and processing outcomes to ensure data integrity and compliance with data locality requirements.” (Para. [0037]) where “although not shown, in various embodiments, the source data 106s may be linked to or fed into the execution platform 106 (whether in the aggregate or in individual chunks) from one or more other systems—e.g., physical or virtual data repositories where the actual data is stored, which may be in a variety of forms, such as, for instance, databases, data lakes, or cloud storage services maintained within a secure, controlled environment to ensure data integrity and security.” (Para. [0054]).
Thus, it would have been obvious to one of ordinary skill in the art, having the teachings of Mehta and Karl at the time that the claimed invention was effectively filed, to have modified the systems and methods for managing data in a data store, as taught by Karl, with the in-situ data processing, as taught by Mehta.
One would have been motivated to make such combination because Mehta teaches “the execution platform is implemented with in-situ access to the source data such that the source data is withheld from being shared with system(s) outside of the execution platform during the evaluation, thereby ensuring data integrity/locality compliance.” (Abstract) and “In-situ processing: Refers to processing of data in or within its original location or environment, which reduces, minimizes, or avoids data movement and enhances data security.” (Para. [0023]) and it would have been obvious to a person having ordinary skill in the art that ensuring data integrity/locality compliance and enhancing data security would improve the system’s reliability and security.
Regarding Claim 3:
Mehta and Karl further teaches performing operations comprising:
Pushing down filter, projection, and aggregation operators to a file adapter for execution on column chunks of first table format files.
Karl teaches filter operators (Para. [0085]), projection, and aggregation operators (Para. [0048] – “joins, projections”) and a file adapter by teaching “an adapter that communicates with the remote database system, for fetching metadata for, or data from, a remote data object, such as a remote database table” (Para. [0116]).
Karl further teaches “tables that are formatted for use in a row store, tables that are formatted for use in a column store, or tables that are associated with a virtual table schema (and thus can have variable types of target tables, such as remote tables, replica tables, or cached tables).” (Para. [0102]) and Mehta teaches “The source data 106s may be formatted in any suitable manner, and may include data across various types of data or various data products. Although not shown, in various embodiments, the source data 106s may be linked to or fed into the execution platform 106 (whether in the aggregate or in individual chunks) from one or more other systems—e.g., physical or virtual data repositories where the actual data is stored, which may be in a variety of forms, such as, for instance, databases, data lakes, or cloud storage services maintained within a secure, controlled environment to ensure data integrity and security.” (Para. [0054]). Therefore, Karl and Mehta teaching execution on column chunks of first table format files.
Regarding Claim 4:
Mehta and Karl further teach:
performing direct, in-situ query processing over files in the data lake without intermediate data movement.
Karl teaches “a federated database includes functionality to make data from multiple, distinct database management systems (or other data sources) available through a common platform or interface” (Para. [0004]) and “When a query is executed, the query is processed by the query processor 120, including executing the query using the query executor 124 to obtain data from one or both of the data store 142 of the remote database system 112 or the data store 168 of the central computing system 110. Query results can be returned to the application 108.” (Para. [0058]) where “The central computing system 110 can include a query processor 120. The query processor 120 can include multiple components, including a query optimizer 122 and a query executor 124. The query optimizer 122 can be responsible for determining a query execution plan 126 for a query to be executed using the central computing system 110. The query plan 126 generated by the query optimizer 122 can include both a logical plan…and a physical plan” (Para. [0048])
Karl further teaches “the data lake 410 can store replica tables 414. The replica tables 414 can be analogous to the replica tables 166. As shown, the data lake 410 is separate from the central computing system 110. In other cases, the data lake 410 can be integrated into the central computing system 110. (Para. [0017]).
Mehta teaches “In-situ processing: Refers to processing of data in or within its original location or environment, which reduces, minimizes, or avoids data movement and enhances data security.” (Para. [0018]) and “The in-situ execution module may manage execution requests and processing outcomes to ensure data integrity and compliance with data locality requirements.” (Para. [0037]) where “although not shown, in various embodiments, the source data 106s may be linked to or fed into the execution platform 106 (whether in the aggregate or in individual chunks) from one or more other systems—e.g., physical or virtual data repositories where the actual data is stored, which may be in a variety of forms, such as, for instance, databases, data lakes, or cloud storage services maintained within a secure, controlled environment to ensure data integrity and security.” (Para. [0054])
Regarding Claim 5:
Mehta and Karl further teach:
Wherein mapping the data stored in the data lake to the one or more virtual representations comprises creating virtual tables in the cloud-based database management system that reference first table format files via a remote source connection.
Karl teaches “the present disclosure provides virtual tables, where a virtual table can be represented by a database schema object (e.g., an entry in a data dictionary) which includes a logical pointer to a table (e.g., containing the actual data associated with the table schema) that should be used with the table definition/schema object.” (Para. [0037]) and “typically, replica tables used by virtual table schemas are not directly accessible by users. In addition, in some cases, even after a replica table is created, it may be desired to allow users to directly access the remote table (serving as the source for the replica table) on the remote system” (Para. [0043]).Karl further teaches “The disclosed technologies can provide a number of advantages. By allowing a user to select whether a virtual table targets a remote table or a replica table (or a cached table), the user can choose whether longer query times associated with remote tables are acceptable. That is, for cost reasons, or based on other considerations (e.g., the desire to maintain the source tables for particular data locally, on the remote system, rather than on a central computing system that maintains the virtual tables), it may be undesirable to replicate all data to a central computing system or other system that integrates data from multiple sources.” (Para. [0045]).
Regarding Claim 7:
Mehta and Karl further teach:
Authenticating the received request using X.509 certificates or web tokens before providing access to the data stored in the data lake.
Mehta teaches “The federated identity and token provider service 104f may be a service layer that is configured to facilitate authentication/authorization for accessing data quality metrics and/or leveraging an FQI 106f. In various embodiments, the federated identity and token provider service 104f may obtain identification token(s) that the processing platform 104 may provide to the execution platform 106, and that the DQ executor 106r can use for authorization to the FQI 106f.” (Para. [0053])
Regarding Claim 9:
All of the limitations herein are similar to some or all of the limitations as recited in Claim 1.
Regarding Claim 11:
All of the limitations herein are similar to some or all of the limitations as recited in Claim 3.
Regarding Claim 12:
All of the limitations herein are similar to some or all of the limitations as recited in Claim 4.
Regarding Claim 13:
All of the limitations herein are similar to some or all of the limitations as recited in Claim 5.
Regarding Claim 15:
All of the limitations herein are similar to some or all of the limitations as recited in Claim 7.
Regarding Claim 17:
Some of the limitations herein are similar to some or all of the limitations as recited in Claim 1.
Mehta and Karl further teach:
A non-transitory machine-readable medium storing instructions which, when executed by one or more processors, cause the one or more processors to perform operations (Karl - Paras. [0013] & [0151]-[0153]).
Regarding Claim 19:
All of the limitations herein are similar to some or all of the limitations as recited in Claim 3.
Regarding Claim 20:
All of the limitations herein are similar to some or all of the limitations as recited in Claim 4.
Claim(s) 2, 10, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Mehta and Karl, and further in view of Bourbonnais et al. (U.S. Pre-Grant Publication No. 2025/0371029, hereinafter referred to as Bourbonnais).
Regarding Claim 2:
Mehta and Karl explicitly teach all of the elements of the claimed invention as recited above except:
Wherein the first table format comprises at least one of Apache Parquet, Delta Lake, or Apache Iceberg.
However, in the related field of endeavor of data stored in a data lakehouse, Bourbonnais teaches:
Wherein the first table format comprises at least one of Apache Parquet, Delta Lake, or Apache Iceberg.
Bourbonnais teaches “A data lakehouse is facilitated using open data formats (e.g., Apache Parquet, Orc or Avro) and open table formats (e.g., Apache Iceberg, Hudi or Delta Lake) that leverage them. These formats allow for storing and retrieving large amounts of data that is accessible via open-source APIs.” (Para. [0012])
Thus, it would have been obvious to one of ordinary skill in the art, having the teachings of Bourbonnais, Mehta, and Karl at the time that the claimed invention was effectively filed, to have modified the systems and methods for managing data in a data store, as taught by Karl, and the in-situ data processing, as taught by Mehta, with the open data formats and open table formats, as taught by Bourbonnais.
One would have been motivated to make such combination because Bourbonnais teaches “ data lakehouse is facilitated using open data formats (e.g., Apache Parquet, Orc or Avro) and open table formats (e.g., Apache Iceberg, Hudi or Delta Lake) that leverage them. These formats allow for storing and retrieving large amounts of data that is accessible via open-source APIs” (Para. [0012]) and it would have been obvious to a person having ordinary skill in the art that storing and retrieving large amounts of data would improve the system’s ability to handle growing volumes of information.
Regarding Claim 10:
All of the limitations herein are similar to some or all of the limitations as recited in Claim 2.
Regarding Claim 18:
All of the limitations herein are similar to some or all of the limitations as recited in Claim 2.
Claim(s) 6 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Mehta and Karl, and further in view of Chacko et al. (U.S. Patent No. 12,117,980, hereinafter referred to as Chacko).
Regarding Claim 6:
Mehta and Karl further teach:
Federating Structured Query Language (SQL) queries to an external analytics engine to perform data transformations on the data stored in the data lake.
Karl teaches “Requests to access data that is not replicated can be serviced in another manner, such as by federation (e.g., retrieving data from a remote data source, including using the Smart Data Access protocol of SAP SE, of Walldorf, Germany)” (Para. [0042]) and “the disclosed technology can be implemented by software written in C++, Java, Perl, JavaScript, Python, Ruby, ABAP, SQL, Adobe Flash, or any other suitable programming language, or, in some examples, markup languages such as html or XML, or combinations of suitable programming languages and markup languages. Likewise, the disclosed technology is not limited to any particular computer or type of hardware.” (Para. [0165]) where data transformations are taught by reciting “If a user attempts to write to the table, the schema of the virtual table used by that user can be updated to point to a different table than the other users, which different table can be a remote table or a replica table, depending on implementation or configuration” (Para. [0041]), “The applications 114 can access data in the remote database system 112, such as through a session manager 186. The applications 114 can modify the remote tables 144.” (Para. [0059]), and “Query language statements can be used to create, or modify, tables” (Para. [0122]).
Mehta and Karl explicitly teach all of the elements of the claimed invention as recited above except:
A Spark adapter
However, in the related field of endeavor of executing big data queries, Chacko teaches:
A Spark adapter
Chacko teaches “Big data queries may provide a user with valuable insights by accessing and aggregating large data sets from a variety of sources…. queries may prioritize some other attribute. In a big data ecosystem, such as Hadoop, several big data query engines (e.g., Spark, Hive, Trino, Impala, etc.) may be used to query and process the data. The big data query engines may accept a variety of inputs (e.g., a structured query language (SQL) input, then execute the query in a distributed manner.” (Col. 4 Line 55 – Col. 5 Line 8).
Thus, it would have been obvious to one of ordinary skill in the art, having the teachings of Chacko, Mehta, and Karl at the time that the claimed invention was effectively filed, to have modified the systems and methods for managing data in a data store, as taught by Karl, and the in-situ data processing, as taught by Mehta, with the use of different big data query engines, as taught by Chacko.
One would have been motivated to make such combination because Chacko teaches “Each of the big data query engines may have various characteristics and capabilities that may enable a particular engine to execute a particular query better than some other query engine. In other words, the priorities associated with a particular query (e.g., latency, response time, etc.) may be better met with a certain big data query engine.” (Col. 4 Line 55 – Col. 5 Line 8) and it would be obvious to a person having ordinary skill in the art that being able to select the big data query engine that best meets the priorities associated with a particular query would create a more dynamic and versatile system for accessing stored data.
Regarding Claim 14:
All of the limitations herein are similar to some or all of the limitations as recited in Claim 6.
Claim(s) 8 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Mehta and Karl, and further in view of Patrick, II et al. (U.S. Pre-Grant Publication No. 2024/0422192, hereinafter referred to as Patrick).
Regarding Claim 8:
Mehta and Karl further teach:
Enable direct access to the hyperscaler object store for data retrieval.
Karl teaches “it may be desired to allow users to directly access the remote table (serving as the source for the replica table) on the remote system. Accordingly, commands in a query language can be provided to force access to a remote table instead of using the replica table. For example, the following command can be added to a SQL statement (e.g., a query, such as using a SELECT statement): NO_VIRTUAL_TABLE_REPLICA. Similarly, a session-level command or variable may be provided to specify that any query language operations during the session should use remote tables instead of replica tables, for virtual table schemas that point to replica tables. For example, a VIRTUAL_TABLE_REPLICA session variable can store a Boolean value indicating whether the replica table should be used. The Boolean value can have a default value, such as TRUE (i.e., the replica table should be used).” (Para. [0043]).
Mehta and Karl explicitly teach all of the elements of the claimed invention as recited above except:
Generating pre-signed URLs to enable direct access.
However, in the related field of endeavor of cloud object storage, Patrick teaches:
Generating pre-signed URLs to enable direct access.
Patrick teaches “generates the presigned URL. In example embodiments, the presigned URL may be generated for the object file without any written code by using the S3 console or AWS Explorer for Visual Studio. In particular embodiments, the presigned URL may be generated by using any suitable computer program such as AWS SDKs for Java, .NET, Ruby, PHP, Node.js, Python, and Go.” (Para. [0070]) where “When a presigned URL is created for an object, an authorized user must provide security credentials and specify an S3 bucket name, an object key, an HTTP method, and an expiration date and time. Thus, the presigned URL is only valid for the specified duration. In some embodiments, where the presigned URL is created using a temporary token, then the presigned URL will expire when the token expires. Any user with the access to the presigned URL can access the object or file in the designated S3 bucket. Thus, the presigned URL grants access to the contents of the S3 bucket.” (Para. [0066]).
Thus, it would have been obvious to one of ordinary skill in the art, having the teachings of Patrick, Mehta, and Karl at the time that the claimed invention was effectively filed, to have modified the systems and methods for managing data in a data store, as taught by Karl, and the in-situ data processing, as taught by Mehta, with the presigned URL for direct access, as taught by Patrick.
One would have been motivated to make such combination because Karl teaches “it may be desired to allow users to directly access the remote table (serving as the source for the replica table) on the remote system” (Para. [0070]) and Patrick teaches making direct access temporary by teaching “When a presigned URL is created for an object, an authorized user must provide security credentials and specify an S3 bucket name, an object key, an HTTP method, and an expiration date and time. Thus, the presigned URL is only valid for the specified duration. In some embodiments, where the presigned URL is created using a temporary token, then the presigned URL will expire when the token expires. Any user with the access to the presigned URL can access the object or file in the designated S3 bucket. Thus, the presigned URL grants access to the contents of the S3 bucket.” (Para. [0066]). It would have been obvious to a person having ordinary skill in the art that making direct access to stored data to be temporary would improve the security of the system by limiting the access with a designated “expiration date and time”.
Regarding Claim 16:
All of the limitations herein are similar to some or all of the limitations as recited in Claim 8.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Yarlagadda (U.S. Pre-Grant Publication No. 2021/0406282) teaches providing metadata access to distributed data lake users. In some embodiments, a computing platform may load metadata from an external metadata database into a staging database. Then, the computing platform may transform the metadata in the staging database and move the transformed metadata to a master database. The master database may comprise information indicating a relationship between the transformed metadata and one or more distributed data lakes. The computing platform may receive a request to access one or more metadata items. Then, the computing platform may authorize a distributed computing cluster user to access at least one metadata item based on the information. Based on the authorization, the computing platform may provide, to the distributed computing cluster user, access to the at least one metadata item of the one or more metadata items.
Sedrak (U.S. Pre-Grant Publication No. 2025/0013610) teaches a data storage management method includes detecting a data change to data in a data repository, identifying metadata of the data change, and storing the metadata in a virtual file, the virtual file being in a data storage format that is compatible with one or more data analysis tools. In response to a subsequent user request to access metadata of the data in the data repository, the method may transmit one or more virtual files containing metadata identified in the user request.
Agababov et al. (U.S. Pre-Grant Publication No. 2025/0077478) teaches merging data lake openness with scalable metadata for managed tables in a cloud database platform, allowing for atomicity, consistency, isolation, and durability (ACID) transactions, performant data manipulation language (DML), higher throughput stream ingestion, data consistency, schema evolution, time travel, clustering, fine-grained security, and/or automatic storage optimization. Table data is stored in various open-source file formats in cloud storage while physical metadata of the table data is stored in a scalable metadata storage system.
Fang et al. (U.S. Pre-Grant Publication No. 2024/0394273) teaches a runtime catalog for a cloud storage engine that unifies data lakes and data warehouses. The runtime catalog can expose a single universe of cloud storage tables through an endpoint for query engines for data lakes and another endpoint for query engines for data warehouses. The runtime catalog can allow the query engines for data lakes and the query engines for data warehouses to query any cloud storage table by representing data warehouse native tables in a format compatible with data lakes and representing data lake native tables in a format compatible with data warehouses.
Sun et al. (U.S. Pre-Grant Publication No. 2025/0131070) teaches a data processing service receives indication that a recipient will request access to data assets of a provider and provides a request for credentials from a recipient governance module. The recipient governance module stores a recipient metastore including an object for a provider metastore. In response to determining that the assets are associated with the provider metastore, the service provides a request for credentials to a provider governance module. The provider governance module stores the provider metastore describing data assets of the provider and permissions for accessing data assets. The provider metastore includes a recipient object attached to the data assets with an identifier for the recipient metastore. In response to verifying that the recipient was provided access to the data assets, the service provides a token to the recipient governance module. The service then provides the token to a computing resource to provide access to the data assets.The reference further teaches “sharing data assets can be achieved via a pre-signed URL. A pre-signed URL uses security credentials to grant time-limited permission to download one or more data assets. The URL can be entered in a browser or used by a program to download the data assets. The credentials used by the pre-signed URL are those of the cloud user who generated the URL and, thus, provide access to the generator's shared data assets.” (Para. [0002]).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ROBERT F MAY whose telephone number is (571)272-3195. The examiner can normally be reached Monday-Friday 9:30am to 6pm.
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, Boris Gorney can be reached on 571-270-5626. 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.
/ROBERT F MAY/Examiner, Art Unit 2154 8/29/2026
Prosecution Insights