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 .
Response to Amendment
The amendments filed on February 20, 2026 have been entered.
Claims 1 and 14 have been amended.
Response to Arguments
Applicant's arguments filed on February 20, 2026 have been fully considered, but they are moot in view of the new grounds of rejection.
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.
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-12 and 14-19 are rejected under 35 U.S.C. 103 as being unpatentable over Avanes et al. (Patent No. US 10,867,063), hereinafter Avanes, in view of Hanckel et al. (Pub. No. US 2017/0242901), hereinafter Hanckel.
Claim 1. Avanes discloses a system of accessing external cloud storage tables (See Col. 2 lines 45-60; network-based data warehouse system 102 is a network-based system used for storing and accessing data (e.g., internally storing data, accessing external remotely located data) in an integrated manner), comprising:
one or more processors (See Fig. 13) configured to:
determine that the external cloud storage tables are authorized external tables (See Col. 16 lines 29-54; the network-based data warehouse system 102 uses the share mask engine 225 to enable the data provider network 805 (e.g., users in the data provider network such as provider user 808) to share access to the live data with the data consumer network 810 (e.g., users in the data consumer network 810 such as consumer_1 and consumer_2) in a secure mask-able approach, according to some example embodiments … the provider user 807 can upload the tables 809 to cloud storage 815 and then give access to the network-based data warehouse system 102 to access the cloud storage 815):
generate, based on the external cloud storage tables being authorized external tables, a table-defined-over-object-storage (TDOOS) based on metadata associated with the external cloud storage table (See Col. 16 lines 29-54; the provider user 807 can upload the tables 809 to cloud storage 815 and then give access to the network-based data warehouse system 102 to access the cloud storage 815 to reference the data (e.g., external tables) for masking and queries. See Col. 6 lines 58-65; the compute service manager 112 (within the network-based data warehouse system 102; See Fig. 1-2) includes a configuration and metadata manager 216, which manages the information related to the data stored in the remote data storage devices (external cloud storage tables). The configuration and metadata manager 216 uses the metadata to determine which data micro-partitions need to be accessed to retrieve data for processing a particular task or job);
receive a request for access to data in the external cloud storage tables and associated with the one or more data files (See Col. 16 lines 29-54; the data (e.g., external tables) is requested by consumers);
retrieve, via the TDOOS, the data requested from the external cloud object storage tables (See Col. 16 lines 29-54; the provider user 807 can upload the tables 809 to cloud storage 815 and then give access to the network-based data warehouse system 102 to access the cloud storage 815 to retrieve the data (e.g., external tables) for masking and queries … policy data 817 can map to data in the cloud storage 815 (e.g., external read only tables) to provide dynamic masking per the policy data 817 when the data is requested by consumers, such as consumer_1 811 and consumer_2 812 via the network-based data warehouse system 102. See Col. 3 line 31; retrieval requests. See also Col. 16 lines 55-67 and Col. 17 lines 1-30);
apply one or more access policies to filter at least a portion of the data based on a schema of the TDOOS (See Col. 16 lines 29-54; the provider user 807 can upload the tables 809 to cloud storage 815 and then give access to the network-based data warehouse system 102 to access the cloud storage 815 to reference the data (e.g., external tables) for masking and queries ... The provider user 807 specifies one or more policies as policy data 817 that dynamically masks the uploaded data per policy roles and functions as specified by masking rules of a given policy. See also Col. 16 lines 55-67 and Col. 17 lines 1-30), and
provide access to the requested data based on the filtered data without visibility to the filtered portion of the data (See Col. 16 lines 29-54; the policy data 817 can map to data in the cloud storage 815 (e.g., external read only tables) to provide dynamic masking per the policy data 817 when the data is requested by consumers, such as consumer_1 811 and consumer_2 812 via the network-based data warehouse system 102 … See Col. 16 lines 55-67; the policy data 817 can specify roles and how corresponding data referenced by the policy can be interacted with by users having different roles. See also Col. 16 lines 55-67 and Col. 17 lines 1-30).
Avanes discloses that the external storage is the external cloud storage, but, Hanckel doesn’t explicitly disclose wherein the TDOOS is a table abstraction for the external cloud storage tables that decouples access to one or more of the external cloud storage tables from one or more data files accessible using the one or more external cloud storage tables.
However, Hanckel discloses a table abstraction for the external storage tables that decouples access to one or more of the external storage tables from one or more data files accessible using the one or more external storage tables (See Parag. [0048]; one technique for defining the metadata for external tables is through the create table operation (see create table 112), possibly in conjunction with a specify metadata operation, and possibly using clauses such as CREATE TABLE, and ORGANIZATION EXTERNAL in declarative statements. Such an external table definition can be thought of as a view that allows running any SQL query against external data without requiring that the external data first be loaded into the database. An access driver is the actual mechanism used to read the external data in the table. When using external tables to access external data, the metadata is automatically created based on the data types in the SELECT statement. See also Parag. [0011] [0021-0024] [0030] [0034]).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the teaching, taught by Avanes, to include a table abstraction for the external storage tables that decouples access to one or more of the external storage tables from one or more data files accessible using the one or more external storage tables, as taught by Hanckel. This would be convenient to provide an improved approach for implementing query-level access to external petabyte-scale distributed file systems (Hanckel, Parag. [0004]).
Claim 2. Avanes in view of Hanckel discloses the system of claim 1,
Avanes further discloses wherein the request for access is received through a data analytics query engine (See Col. 3 lines 25-33; The compute service manager 112 also performs query optimization and compilation as well as managing clusters of computing services that provide compute resources (e.g., virtual warehouses, virtual machines, EC2 clusters). The compute service manager 112 can support any number of client accounts such as end users providing data storage and retrieval requests, system administrators managing the systems and methods, and other components/devices that interact with compute service manager 112. See Col. 4 lines 4-20).
Claim 3. Avanes in view of Hanckel discloses the system of claim 1,
Avanes further discloses wherein the requested data comprises tables defined over external object storage or internal data warehouse storage (See Col. 16 lines 44-54; the provider user 807 specifies one or more policies as policy data 817 that dynamically masks the uploaded data per policy roles and functions as specified by masking rules of a given policy. The policy data 817 can map to locally stored data (e.g., data in database 116) and/or map to data in the cloud storage 815 (e.g., external read only tables) to provide dynamic masking per the policy data 817 when the data is requested by consumers, such as consumer_1 811 and consumer_2 812 via the network-based data warehouse system 102. See also Col. 21 lines 20-40).
Claim 4. Avanes in view of Hanckel discloses the system of claim 3,
Avanes further discloses wherein row and column security policies are applied consistently regardless of whether the tables are defined over external object storage or internal data warehouse storage (See Col. 18 lines 16-24; examples of functions for masking include: hiding a column, masking the first three characters of each entry of a given column (e.g., hiding the area code), masking the first five characters for each row, transform or obfuscate the ZIP (e.g., replace ZIP code information with city or state information to blur where a given patient is located), join data from two tables (e.g., a local table and an external read only data) and return a view, and other types of additional custom user defined operations).
Claim 5. Avanes in view of Hanckel discloses the system of claim 1,
Avanes further discloses further comprising a storage application programming interface (API), wherein the data responsive to the request is retrieved using the storage API (See Col. 4 lines 21-39; the cloud computing storage platform 104 also comprises an access management system 118 and an API gateway 120... The API gateway 120 handles tasks involved in accepting and processing concurrent API calls, including traffic management, authorization and access control, monitoring, and API version management. The API gateway 120 provides HTTP proxy service for creating, publishing, maintaining, securing, and monitoring APIs (e.g., REST APIs)).
Claim 6. Avanes in view of Hanckel discloses the system of claim 1,
Avanes further discloses the system further comprising a vectorized runtime that applies the one or more access policies to filter out the raw data (See Col. 18 lines 35-43; example code can be implemented by the data provider account 505 to create, alter, or terminate policy data by inputting the example code into the execution area 755 (e.g., browser window of an active session). In some example embodiments, the policy code is SQL that is stored in one or more policy tables in policy data 817, which can then be referenced by the share mask engine 225 to dynamically mask data).
Claim 7. Avanes in view of Hanckel discloses the system of claim 6,
Avanes further discloses wherein the one or more access policies comprise column security and masking (See Col. 18 lines 16-24; examples of functions for masking include: hiding a column, masking the first three characters of each entry of a given column (e.g., hiding the area code), masking the first five characters for each row, transform or obfuscate the ZIP (e.g., replace ZIP code information with city or state information to blur where a given patient is located), join data from two tables (e.g., a local table and an external read only data) and return a view, and other types of additional custom user defined operations).
Claim 8. Avanes in view of Hanckel discloses the system of claim 6,
Avanes further discloses wherein the one or more access policies comprise row filtering (See Col. 18 lines 16-24; examples of functions for masking include: hiding a column, masking the first three characters of each entry of a given column (e.g., hiding the area code), masking the first five characters for each row, transform or obfuscate the ZIP (e.g., replace ZIP code information with city or state information to blur where a given patient is located), join data from two tables (e.g., a local table and an external read only data) and return a view, and other types of additional custom user defined operations).
Claim 9. Avanes in view of Hanckel discloses the system of claim 1,
Avanes further discloses wherein the retrieved data comprises files having one or more file formats (See Col. 3 lines 63-67 and Col. 4 lines 1-3; data storage devices 124-1 to 124-n may be part of a public cloud infrastructure or a private cloud infrastructure. Data storage devices 124-1 to 124-n may be hard disk drives (HDDs), solid state drives (SSDs), storage clusters, Amazon S3 storage systems or any other data storage technology. Additionally, cloud computing storage platform 104 may include distributed file, systems (such as Hadoop Distributed File Systems (HDFS)), object storage systems, and the like. See Col. 6 lines 1-6; the computing resources and cache resources are not restricted to specific data storage resources 124-1 to 124-n. Instead, all computing resources and all cache resources may retrieve data from, and store data to, any of the data storage resources in the cloud computing storage platform 104).
Claim 10. Avanes in view of Hanckel discloses the system of claim 9,
Avanes further discloses wherein the file formats comprise at least one of proprietary formats or open source formats (See Col. 3 lines 63-67 and Col. 4 lines 1-3; data storage devices 124-1 to 124-n may be part of a public cloud infrastructure or a private cloud infrastructure. Data storage devices 124-1 to 124-n may be hard disk drives (HDDs), solid state drives (SSDs), storage clusters, Amazon S3 storage systems or any other data storage technology. Additionally, cloud computing storage platform 104 may include distributed file, systems (such as Hadoop Distributed File Systems (HDFS)), object storage systems, and the like. See Col. 6 lines 1-6; the computing resources and cache resources are not restricted to specific data storage resources 124-1 to 124-n. Instead, all computing resources and all cache resources may retrieve data from, and store data to, any of the data storage resources in the cloud computing storage platform 104).
Claim 11. Avanes in view of Hanckel discloses the system of claim 1,
Avanes further discloses the system further comprising a delegated access layer having access to the external cloud storage tables on behalf of a user (See Col. 16 lines 29-41; the network-based data warehouse system 102 uses the share mask engine 225 to enable the data provider network 805 (e.g., users in the data provider network such as provider user 808) to share access to the live data with the data consumer network 810 (e.g., users in the data consumer network 810 such as consumer_1 and consumer_2) in a secure mask-able approach, according to some example embodiments. For instance, as illustrated, the provider user 807 can upload the tables 809 to cloud storage 815 and then give access to the network-based data warehouse system 102 to access the cloud storage 815 to retrieve or reference the data (e.g., external tables) for masking and queries. See Col. 3 lines 12-21).
Claim 12. Avanes in view of Hanckel discloses the system of claim 11,
Avanes further discloses wherein the delegated access layer uses an administrative identity that has access to all files (See Col. 3 lines 12-21; the access management system 110 enables administrative users to manage access to resources and services provided by the network-based data warehouse system 102. Administrative users can create and manage users, roles, and groups, and use permissions to allow or deny access to resources and services. The access management system 110 can store share data that securely manages shared access to the storage resources of the cloud computing storage platform 104 amongst different users of the network-based data warehouse system 102).
Claim 14. Avanes discloses a method of accessing external cloud storage tables (See Col. 2 lines 45-60; network-based data warehouse system 102 is a network-based system used for storing and accessing data (e.g., internally storing data, accessing external remotely located data) in an integrated manner), the method comprising:
determining, by one or more processors, that the external cloud storage tables are authorized external cloud storage tables (See Col. 16 lines 29-54; the network-based data warehouse system 102 uses the share mask engine 225 to enable the data provider network 805 (e.g., users in the data provider network such as provider user 808) to share access to the live data with the data consumer network 810 (e.g., users in the data consumer network 810 such as consumer_1 and consumer_2) in a secure mask-able approach, according to some example embodiments … the provider user 807 can upload the tables 809 to cloud storage 815 and then give access to the network-based data warehouse system 102 to access the cloud storage 815);
generating, by the one or more processors based on the external cloud storage tables being authorized external tables, a table-defined-over-object-storage (TDOOS) based on metadata associated with the external table (See Col. 16 lines 29-54; the provider user 807 can upload the tables 809 to cloud storage 815 and then give access to the network-based data warehouse system 102 to access the cloud storage 815 to reference the data (e.g., external tables) for masking and queries. See Col. 6 lines 58-65; the compute service manager 112 (within the network-based data warehouse system 102; See Fig. 1-2) includes a configuration and metadata manager 216, which manages the information related to the data stored in the remote data storage devices (external cloud storage tables). The configuration and metadata manager 216 uses the metadata to determine which data micro-partitions need to be accessed to retrieve data for processing a particular task or job);
receiving, with the one or more processors, a request for access in the external cloud storage tables and associated with the one or more data files (See Col. 16 lines 29-54; the data (e.g., external tables) is requested by consumers);
retrieving, by the one or more processors via TDOOS, the data requested from the external cloud storage tables (See Col. 16 lines 29-54; the provider user 807 can upload the tables 809 to cloud storage 815 and then give access to the network-based data warehouse system 102 to access the cloud storage 815 to retrieve the data (e.g., external tables) for masking and queries … policy data 817 can map to data in the cloud storage 815 (e.g., external read only tables) to provide dynamic masking per the policy data 817 when the data is requested by consumers, such as consumer_1 811 and consumer_2 812 via the network-based data warehouse system 102. See also Col. 16 lines 55-67 and Col. 17 lines 1-30);
applying, by the one or more processors, one or more access policies to filter at least a portion of the data based on a schema of the TDOOS (See Col. 16 lines 29-54; the provider user 807 can upload the tables 809 to cloud storage 815 and then give access to the network-based data warehouse system 102 to access the cloud storage 815 to reference the data (e.g., external tables) for masking and queries ... The provider user 807 specifies one or more policies as policy data 817 that dynamically masks the uploaded data per policy roles and functions as specified by masking rules of a given policy. See also Col. 16 lines 55-67 and Col. 17 lines 1-30); and
providing, by the one or more processors, access to the requested data based on the filtered data without visibility to the filtered portion of the data (See Col. 16 lines 29-54; the policy data 817 can map to data in the cloud storage 815 (e.g., external read only tables) to provide dynamic masking per the policy data 817 when the data is requested by consumers, such as consumer_1 811 and consumer_2 812 via the network-based data warehouse system 102 … See Col. 16 lines 55-67; the policy data 817 can specify roles and how corresponding data referenced by the policy can be interacted with by users having different roles. See also Col. 16 lines 55-67 and Col. 17 lines 1-30).
Avanes discloses that the external storage is the external cloud storage, but, Hanckel doesn’t explicitly disclose wherein the TDOOS is a table abstraction for the external cloud storage tables that decouples access to one or more of the external cloud storage tables from one or more data files accessible using the one or more external cloud storage tables.
However, Hanckel discloses a table abstraction for the external storage tables that decouples access to one or more of the external storage tables from one or more data files accessible using the one or more external storage tables (See Parag. [0048]; one technique for defining the metadata for external tables is through the create table operation (see create table 112), possibly in conjunction with a specify metadata operation, and possibly using clauses such as CREATE TABLE, and ORGANIZATION EXTERNAL in declarative statements. Such an external table definition can be thought of as a view that allows running any SQL query against external data without requiring that the external data first be loaded into the database. An access driver is the actual mechanism used to read the external data in the table. When using external tables to access external data, the metadata is automatically created based on the data types in the SELECT statement. See also Parag. [0011] [0021-0024] [0030] [0034]).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the teaching, taught by Avanes, to include a table abstraction for the external storage tables that decouples access to one or more of the external storage tables from one or more data files accessible using the one or more external storage tables, as taught by Hanckel. This would be convenient to provide an improved approach for implementing query-level access to external petabyte-scale distributed file systems (Hanckel, Parag. [0004]).
Claim 15. The applicant is directed to the rejections to claim 4 set forth above, as it is rejected based on the same rationale.
Claim 16. The applicant is directed to the rejections to claim 5 set forth above, as it is rejected based on the same rationale.
Claim 17. The applicant is directed to the rejections to claim 6 set forth above, as it is rejected based on the same rationale.
Claim 18. The applicant is directed to the rejections to claims 7-8 set forth above, as they are rejected based on the same rationale.
Claim 19. The applicant is directed to the rejections to claims 11-12 set forth above, as they are rejected based on the same rationale.
Claims 13 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Avanes et al. (Patent No. US 10,867,063), hereinafter Avanes, in view of Hanckel et al. (Pub. No. US 2017/0242901), hereinafter Hanckel; and further in view of Liu (Pub. No. US 2017/0168783).
Claim 13. Avanes in view of Hanckel discloses the system of claim 1,
Avanes further discloses row and column security policies (See Col. 18 lines 16-24; examples of functions for masking include: hiding a column, masking the first three characters of each entry of a given column (e.g., hiding the area code), masking the first five characters for each row, transform or obfuscate the ZIP (e.g., replace ZIP code information with city or state information to blur where a given patient is located), join data from two tables (e.g., a local table and an external read only data) and return a view, and other types of additional custom user defined operations)), Avanes in view of Hanckel doesn’t explicitly disclose policies are applied without placing trust in open-source engines that runs arbitrary procedural code.
However, Liu discloses policies are applied without placing trust in open-source engines that runs arbitrary procedural code (See Parag. [0080]; since open source scripting languages can be used, security can be maintained by implementing a sandbox environment, which restricts some features such as accessing local files, accessing network files, and multithread access rules).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the teaching, taught by Avanes in view of Hanckel, to include applying policies without placing trust in open-source engines that runs arbitrary procedural code, as taught by Liu. This would be convenient for restricting some features such as accessing local files, accessing network files, and multithread access rules (Liu, Parag. [0080]).
Claim 20. The applicant is directed to the rejections to claim 13 set forth above, as it is rejected based on the same rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure (see PTO-form 892).
Davis et al. (Pub. No. US 2018/0322128) – related to improving the query performance of a database in a manner that is transparent to a user. In one aspect, this approach creates separate partition tables that are not directly accessible to a user of the database. A client-facing aspect of the database is a logical model which may correspond to a single, main table with which the user interacts. Thus, queries or operations may be generated on the client side in the context of the logical model. A database or query layer can then, transparent to the user, translate the user generated requests into query language that addresses the proper partitions to generate a result set or otherwise perform a database operation. (See Abstract).
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GHIZLANE MAAZOUZ whose telephone number is (571)272-8118. The examiner can normally be reached Telework M-F 7:30-5 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, Philip J Chea can be reached on 571-272-3951. 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.
/GHIZLANE MAAZOUZ/Examiner, Art Unit 2499
/PHILIP J CHEA/Supervisory Patent Examiner, Art Unit 2499
Prosecution Insights