DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is sent in response to Applicant's Communication received on October 29, 2025 for application number 19/305,272. This Office hereby acknowledges receipt of the following and placed of record in file: Specification, Drawings, Abstract, Oath/Declaration, and Claims.
Priority
This application discloses and claims only subject matter disclosed in prior application no 18/218,307, filed July 5, 2023, and names the inventor or at least one joint inventor named in the prior application. Accordingly, this application may constitute a continuation or division. Should applicant desire to claim the benefit of the filing date of the prior application, attention is directed to 35 U.S.C. 120, 37 CFR 1.78, and MPEP § 211 et seq.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 07/16/2013 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
The information disclosure statements filed 08/20/2025 fails to comply with the provisions of 37 CFR 1.97, 1.98 and MPEP § 609 because MPEP 609.04(a) requires, “Each publication must be identified by publisher, author (if any), title, relevant pages of the publication, and date and place of publication. The date of publication supplied must include at least the month and year of publication, except that the year of publication (without the month) will be accepted if the applicant points out in the information disclosure statement that the year of publication is sufficiently earlier than the effective U.S. filing date and any foreign priority date so that the particular month of publication is not in issue.”
For example, NPL Cite No 1-4 fail to identify the date of publication including at least the month and year.
It has been placed in the application file, but the information referred to therein has not been considered as to the merits. Applicant is advised that the date of any re-submission of any item of information contained in this information disclosure statement or the submission of any missing element(s) will be the date of submission for purposes of determining compliance with the requirements based on the time of filing the statement, including all certification requirements for statements under 37 CFR 1.97(e). See MPEP § 609.05(a).
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.
Claim 17-20 are rejected under 35 U.S.C. 101 because the claimed invention is not statutory for the following reasons:
The claims lack the necessary physical articles or objects to constitute a machine or manufacture within the meaning of 35 U.S.C. 101.
For example, Claim 17 discloses “A lakehouse architecture…. a data lake layer… a data warehouse layer….”, does not inherently mean that the claim is directed to a machine. Only if at least one of the claimed elements of the system is a physical part of a device can the system as claimed constitute part of a device or combination of devices to be a machine within the meaning of 101. In this case the “a data lake layer” and “a data warehouse layer” can be interpreted as software.
Claims 17-20 lack the necessary physical articles or objects to constitute a machine or manufacture within the meaning of 35 U.S.C. 101.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-3, 5-11, and 13-18 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta et al. (US 2024/0126744) (hereinafter Gupta) in view of Waller et al. (US 2024/0296082) (hereinafter Waller).
Regarding claim 1, Gupta teaches a method for managing metadata in a data lakehouse, the data lakehouse including each of a data lake layer and a data warehouse layer, the method comprising: receiving, by one or more processors, a transaction to modify one or more data units in a data repository of the data lake layer, wherein the data repository is configured to store a combination of structured, semi-structured and unstructured data in a repository layer, and store metadata of the transaction in the data repository in a metadata layer of the data repository (see Fig. 1, para [0036-0037], discloses receiving modifications to data objects in a data lake (data repository) that stores structured, semi-structured and unstructured data and versions in version control interface).
Gupta does not explicitly teach updating, by the one or more processors, a centralized catalog included in the data warehouse layer based on the stored metadata; receiving, by the one or more processors, a user query to access requested data stored in the repository layer of the data repository of the data lake layer, wherein the requested data is associated with the data units modified by the transaction; and transmitting, by the one or more processors, a request to the centralized catalog for information related to the metadata of the transaction; receiving, by the one or more processors, the information related to the metadata of the transaction from the centralized catalog; and accessing, by the one or more processors, the requested data based on the received information.
Waller teaches updating, by the one or more processors, a centralized catalog included in the data warehouse layer based on the stored metadata (see Figs. 4-5, Fig. 15, para [0056], para [0066-0067], discloses updating an Amazon Web Services, AWS Glue data catalog (centralized catalog) with file accurately representing a schema, when a CSV file is transformed to generate a Parquet file based on defined schema for CSV file); receiving, by the one or more processors, a user query to access requested data stored in the repository layer of the data repository of the data lake layer (see Fig. 13, Fig. 15, para [0060-0061], discloses receiving ETL jobs to extract data from cloud services offered by AWS and user selection of table from AWS Glue data catalog to create a job that uses table definition to access data source and interpret format), wherein the requested data is associated with the data units modified by the transaction (see Figs. 15-16, para [0061], para [0063], discloses ETL job is associated with user selection of table from AWS Glue data catalog to create an ETL job (transaction) that uses table definition to access data source and interpret format and extracting metadata from a file in a row-based file format); and transmitting, by the one or more processors, a request to the centralized catalog for information related to the metadata of the transaction (see Fig. 11, Figs. 15-16, para [0060-0061], discloses writing metadata from ETL jobs to AWS Glue data catalog, in which the metadata of the ETL job (transaction) is used to query and transform data in a consistent manner across a wide variety of applications); receiving, by the one or more processors, the information related to the metadata of the transaction from the centralized catalog (see Fig. 15, para [0060-0061], discloses receiving metadata regarding crawled data and progresses through a prioritized list of classifiers from tables of AWS Glue data catalog); and accessing, by the one or more processors, the requested data based on the received information (Figs. 15-17, para [0061-0062], para [0066], discloses accessing table created in AWS Glue data catalog based on the generated Parquet file in order to accurately analyze the Parquet file).
Gupta/Waller are analogous arts as they are each from the same field of endeavor of database systems.
Before the effective filing date of the invention it would have been obvious to a person of ordinary skill in the art to modify the system of Gupta to utilize a centralized catalog from disclosure of Waller. The motivation to combine these arts is disclosed by Waller as “data catalog 1510 therefore provides a uniform repository where disparate systems can store and find metadata to keep track of data in data stores” (para [0060]) and utilizing a centralized catalog is well known to persons of ordinary skill in the art, and therefore one of ordinary skill would have good reason to pursue the known options within his or her technical grasp that would lead to anticipated success.
Regarding claim 9, Gupta teaches a system for managing metadata in a data lakehouse, the data lakehouse including each of a data lake layer and a data warehouse layer, the system comprising: one or more processors (see para [0101], discloses a processor); and memory having stored thereon instructions for causing the one or more processors to (see Fig. 9, discloses memory): receive a transaction to modify one or more data units in a data repository of the data lake layer, wherein the data repository is configured to store a combination of structured, semi-structured and unstructured data in a repository layer, and store metadata of the transaction in the data repository in a metadata layer of the data repository (see Fig. 1, para [0036-0037], discloses receiving modifications to data objects in a data lake (data repository) that stores structured, semi-structured and unstructured data and versions in version control interface).
Gupta does not explicitly teach update a centralized catalog included in the data warehouse layer based on the stored metadata; receive a user query to access requested data stored in the repository layer of the data repository of the data lake layer, wherein the requested data is associated with the data units modified by the transaction; and transmit a request to the centralized catalog for information related to the metadata of the transaction; receive the information related to the metadata of the transaction from the centralized catalog; and access the requested data based on the received information.
Waller teaches update a centralized catalog included in the data warehouse layer based on the stored metadata (see Figs. 4-5, Fig. 15, para [0056], para [0066-0067], discloses updating an Amazon Web Services, AWS Glue data catalog (centralized catalog) with file accurately representing a schema, when a CSV file is transformed to generate a Parquet file based on defined schema for CSV file); receive a user query to access requested data stored in the repository layer of the data repository of the data lake layer (see Fig. 13, Fig. 15, para [0060-0061], discloses receiving ETL jobs to extract data from cloud services offered by AWS and user selection of table from AWS Glue data catalog to create a job that uses table definition to access data source and interpret format), wherein the requested data is associated with the data units modified by the transaction (see Figs. 15-16, para [0061], para [0063], discloses ETL job is associated with user selection of table from AWS Glue data catalog to create an ETL job (transaction) that uses table definition to access data source and interpret format and extracting metadata from a file in a row-based file format); and transmit a request to the centralized catalog for information related to the metadata of the transaction (see Fig. 11, Figs. 15-16, para [0060-0061], discloses writing metadata from ETL jobs to AWS Glue data catalog, in which the metadata of the ETL job (transaction) is used to query and transform data in a consistent manner across a wide variety of applications); receive the information related to the metadata of the transaction from the centralized catalog (see Fig. 15, para [0060-0061], discloses receiving metadata regarding crawled data and progresses through a prioritized list of classifiers from tables of AWS Glue data catalog); and access the requested data based on the received information (Figs. 15-17, para [0061-0062], para [0066], discloses accessing table created in AWS Glue data catalog based on the generated Parquet file in order to accurately analyze the Parquet file).
Gupta/Waller are analogous arts as they are each from the same field of endeavor of database systems.
Before the effective filing date of the invention it would have been obvious to a person of ordinary skill in the art to modify the system of Gupta to utilize a centralized catalog from disclosure of Waller. The motivation to combine these arts is disclosed by Waller as “data catalog 1510 therefore provides a uniform repository where disparate systems can store and find metadata to keep track of data in data stores” (para [0060]) and utilizing a centralized catalog is well known to persons of ordinary skill in the art, and therefore one of ordinary skill would have good reason to pursue the known options within his or her technical grasp that would lead to anticipated success.
Regarding claim 17, Gupta teaches lakehouse architecture comprising: a data lake layer including a data repository, wherein the data repository is configured to store a combination of structured, semi-structured and unstructured data in a repository layer of the data repository, and store metadata of the transaction in the data repository in a metadata layer of the data repository (see Fig. 1, para [0036-0037], discloses receiving modifications to data objects in a data lake (data repository) that stores structured, semi-structured and unstructured data and versions in version control interface).
Gupta does not explicitly teach a data warehouse layer including a centralized catalog, wherein the data warehouse layer is configured to: receive a user query to access requested data stored in the repository layer of the data repository of the data lake layer, wherein the requested data is associated with data units modified by a transaction; and transmit the information related to the metadata of the transaction from the centralized catalog, wherein the requested data is accessible from the data lake layer based on the received information.
Waller teaches a data warehouse layer including a centralized catalog, wherein the data warehouse layer is configured to: receive a user query to access requested data stored in the repository layer of the data repository of the data lake layer (see Fig. 13, Fig. 15, para [0060-0061], discloses receiving ETL jobs to extract data from cloud services offered by AWS and user selection of table from AWS Glue data catalog (centralized catalog) to create a job that uses table definition to access data source and interpret format), wherein the requested data is associated with data units modified by a transaction (see Figs. 15-16, para [0061], para [0063], discloses ETL job is associated with user selection of table from AWS Glue data catalog to create an ETL job (transaction) that uses table definition to access data source and interpret format and extracting metadata from a file in a row-based file format); and transmit the information related to the metadata of the transaction from the centralized catalog (see Fig. 11, Figs. 15-16, para [0060-0061], discloses writing metadata from ETL jobs to AWS Glue data catalog, in which the metadata of the ETL job (transaction) is used to query and transform data in a consistent manner across a wide variety of applications); wherein the requested data is accessible from the data lake layer based on the received information (Figs. 15-17, para [0061-0062], para [0066], discloses accessing table created in AWS Glue data catalog based on the generated Parquet file in order to accurately analyze the Parquet file).
Gupta/Waller are analogous arts as they are each from the same field of endeavor of database systems.
Before the effective filing date of the invention it would have been obvious to a person of ordinary skill in the art to modify the system of Gupta to utilize a centralized catalog from disclosure of Waller. The motivation to combine these arts is disclosed by Waller as “data catalog 1510 therefore provides a uniform repository where disparate systems can store and find metadata to keep track of data in data stores” (para [0060]) and utilizing a centralized catalog is well known to persons of ordinary skill in the art, and therefore one of ordinary skill would have good reason to pursue the known options within his or her technical grasp that would lead to anticipated success.
Regarding claims 2 and 10, Gupta/Waller teach a method of claim 1 and a system of claim 9.
Gupta further teaches generating, by the one or more processors, a snapshot of the metadata of the transaction (see Fig. 2B, para [0026-0027], para [0052], discloses generating snapshots at various point in time); and storing the snapshot in a network-connected storage medium separate from the data repository, wherein storing the snapshot occurs either in response to a user storage request or at regularly scheduled intervals (see Fig. 2B, para [0052-0053], discloses storing snapshots for data at a particular point in time).
Regarding claims 3 and 11, Gupta/Waller teach a method of claim 1 and a system of claim 9.
Gupta further teaches applying one or more data analysis tools to the accessed requested data, wherein the one or more data analysis tools includes at least one of a governance compliance tool, a data versioning tool, or a file listing caching tool (see para [0036], discloses governance functions).
Regarding claims 5 and 13, Gupta/Waller teach a method of claim 1 and a system of claim 9.
Gupta does not explicitly teach applying at least one of an indexing operation or a caching operation to the accessed requested data.
Waller teaches applying at least one of an indexing operation or a caching operation to the accessed requested data (see Fig. 15, para [0061], discloses AWS Glue data catalog is populated with table definitions and prioritizes a list of classifiers (index operation) to extract metadata and create metadata tables, it is known to one of ordinary skill in the art that AWS Glue Data Catalog acts a centralized metadata index).
Regarding claims 6 and 14, Gupta/Waller teach a method of claim 1 and a system of claim 9.
Gupta further teaches wherein the metadata of the transaction includes a previous state of the one or more data units, and wherein the method further comprises performing a data recovery operation using the accessed requested data based on the information related to the metadata of the transaction (see Fig. 1, Fig. 4,, para [0039], para [0073], discloses crash recovery functionality to re-apply state changes in order to recover the state prior to the crash).
Regarding claims 7 and 15, Gupta/Waller teach a method of claim 1 and a system of claim 9.
Gupta further teaches wherein the transaction is an ACID transaction (see para [0021], discloses ACID transactions).
Regarding claims 8 and 16, Gupta/Waller teach a method of claim 1 and a system of claim 9.
Gupta does not explicitly teach wherein accessing the requested data is performed by a query engine configured to directly read the metadata of the transaction from the metadata layer of the data repository using the received information from the centralized catalog.
Waller teaches wherein accessing the requested data is performed by a query engine configured to directly read the metadata of the transaction from the metadata layer of the data repository using the received information from the centralized catalog (see Fig. 15, para [0060-0061], discloses AWS Glue data catalog is a metadata repository for data assets and metadata can be used to query and transform data in a consistent manner across a wide variety of applications).
Regarding claim 18, Gupta/Waller teach an architecture of claim 17.
Gupta does not explicitly teach wherein the centralized catalog is contained in a query engine configured to access the metadata collected from the data lake layer and process user queries based on the accessed metadata.
Waller teaches wherein the centralized catalog is contained in a query engine configured to access the metadata collected from the data lake layer and process user queries based on the accessed metadata (see Fig. 15, para [0060-0061], discloses AWS Glue data catalog accessing collected metadata and process queries).
Regarding claim 19, Gupta/Waller teach an architecture of claim 17.
Gupta does not explicitly teach wherein the centralized catalog is contained in a data warehouse engine configured to manage data from the data lake layer based on the accessed metadata.
Waller teaches wherein the centralized catalog is contained in a data warehouse engine configured to manage data from the data lake layer based on the accessed metadata (see Fig. 13, Fig. 15, para [0060], discloses manage accessed metadata in AWS Glue data catalog from Amazon S3).
Claims 4 and 12 are rejected under 35 U.S.C. 103 as being unpatentable Gupta et al. (US 2024/0126744) (hereinafter Gupta) in view of Waller as applied to claims 1 and 11, and in further view of Piparsaniya et al. (US 2020/0394625) (hereinafter Piparsaniya).
Regarding claims 4 and 12, Gupta/Waller teach a method of claim 1 and a system of claim 9.
Gupta/Waller do not explicitly teach applying one or more security operations to the accessed requested data, wherein the one or more security operations may be performed using at least one of a row-level security tool, or a column-level security tool.
Piparsaniya teaches applying one or more security operations to the accessed requested data, wherein the one or more security operations may be performed using at least one of a row-level security tool, or a column-level security tool (see Fig. 5B, para [0063], discloses security analysis tool in encrypted format of row and column level data).
Gupta/Waller/Piparsaniya are analogous arts as they are each from the same field of endeavor of database systems.
Before the effective filing date of the invention it would have been obvious to a person of ordinary skill in the art to modify the system of Gupta/Waller to utilize security analysis tool from disclosure of Piparsaniya. The motivation to combine these arts is disclosed by Piparsaniya as “ensure data security to all group members” (para [0063]) and utilizing security analysis tool is well known to persons of ordinary skill in the art, and therefore one of ordinary skill would have good reason to pursue the known options within his or her technical grasp that would lead to anticipated success.
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable Gupta et al. (US 2024/0126744) (hereinafter Gupta) in view of Waller as applied to claims 1 and 11, and in further view of Moosa et al. (US 2025/0005043) (hereinafter Moosa).
Regarding claim 20, Gupta/Waller teach an architecture of claim 17.
Gupta/Waller does not explicitly teach wherein the data warehouse layer is communicatively positioned between a user device from which the user query is received and the data lake layer such that the data lake layer is indirectly queried through the data warehouse layer.
Moosa teaches wherein the data warehouse layer is communicatively positioned between a user device from which the user query is received and the data lake layer such that the data lake layer is indirectly queried through the data warehouse layer (see para [0039], discloses bridging data across data warehouse, data lakes, and third-party data sources).
Gupta/Waller/Moosa are analogous arts as they are each from the same field of endeavor of database systems.
Before the effective filing date of the invention it would have been obvious to a person of ordinary skill in the art to modify the system of Gupta/Waller to position data warehouse layer between user device and data lake layer from disclosure of Moosa. The motivation to combine these arts is disclosed by Moosa as “efficiently bridge data across data warehouses, data marts, data lakes and third-party data sources without having to create a whole new integrated physical data platform” (para [00039]) and positioning data warehouse layer between user device and data lake layer is well known to persons of ordinary skill in the art, and therefore one of ordinary skill would have good reason to pursue the known options within his or her technical grasp that would lead to anticipated success.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See Li et al. US Patent No. 11,886,442.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to COURTNEY HARMON whose telephone number is (571)270-5861. The examiner can normally be reached M-F 9am - 5pm.
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, Ann Lo can be reached at 571-272-9767. 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.
/Courtney Harmon/Primary Examiner, Art Unit 2159