DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 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.
Claim(s) 4 and 15 is/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.
Claim 4 (similarly claim 15) contains the trademark/trade name JavaScript. Where a trademark or trade name is used in a claim as a limitation to identify or describe a particular material or product, the claim does not comply with the requirements of 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph. See Ex parte Simpson, 218 USPQ 1020 (Bd. App. 1982). The claim scope is uncertain since the trademark or trade name cannot be used properly to identify any particular material or product. A trademark or trade name is used to identify a source of goods, and not the goods themselves. Thus, a trademark or trade name does not identify or describe the goods associated with the trademark or trade name. In the present case, the trademark/trade name is used to identify/describe computer program, language processors and intepreters and, accordingly, the identification/description is indefinite.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-8 and 12-23 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kandregula et al. (Pat 12657189) (hereafter Kandregula) in view of Rahman et al. (Pat 12333041) (hereafter Rahman).
As per claim 1, Kandregula teaches:
An apparatus comprising:
interface circuitry;
machine-readable instructions; and
programmable circuitry to at least one of instantiate or execute the machine-readable instructions to:
cause transmission of a discovery result to a client application, the discovery result including a list of federated data lakes; and ([Column 1 line 60-67 and column 2 line 1-15], Disclosed herein are systems, methods, and non-transitory computer-readable media (generally, “techniques”) for cross-regional resource links in a federated data lake management and integration system (“federated data lake system”), spread across multiple regions within a multi-tenant provider network. When a query language statement is received from a client at a data warehouse system server in one region, the federated data lake system's driver in the region identifies the referenced database or table. It then retrieves local metadata about this object. If the metadata includes a link to resources in another region, the driver accesses additional metadata from a remote data lake metastore in that second region. Utilizing this second set of metadata, the driver creates a query execution plan. This plan is used to instruct a distributed data processing system to execute data processing jobs against a data lake storage system. Finally, the data satisfying the query is returned to the client. This approach allows for efficient querying and data retrieval across different regions within the federated data lake system.)
after receipt of a token request specifying a first data lake of the federated data lakes, cause transmission of an access token and metadata to the client application, the access token and the metadata corresponding to the first data lake, the metadata to specify services available at the first data lake, the access token to grant the client application access to the first data lake of the federated data lakes. ([Column 6 line 42-67], Distributed data storage system 112 applies access controls to ensure that only authorized principals can access specific data sets. In some instances, such access control is accomplished and managed through any or all of: identity and access management (IAM) policies, role-based access control (RBAC), and attribute-based access control (ABAC)… When a principal (e.g., a user, a service, a role, or an application) attempts to access data lake data 116 within the data lake, the distributed data storage system 112 first authenticates the principal's identity, using credentials like usernames and passwords, tokens, digital certificates, or other suitable authentication mechanism. After authentication, the distributed data storage system 112 determines the principal's permissions using predefined access policies… These policies are configured by administrators and define what actions (like read, write, delete) a principal can perform on which data sets. In role-based access control, principals are assigned to roles, and each role has specific permissions. For example, a data analyst might have read-only access to certain data sets, while a data engineer might have broader access that includes the ability to modify or delete data. Attribute-based access control takes this a step further by considering additional attributes (like the time of access, the location of the user, or the classification of the data) in making access decisions. In distributed data storage system 112, these controls are enforced across regions 102, ensuring consistent policy application regardless of which region 102 the particular data lake data 116 being accessed is stored. [Column 15 line 17-41], In some instances, a cross-regional resource link 120 contains information necessary for establishing a connection to the remote data lake metastore 114, such as the network address (like a uniform resource locator (URL) or uniform resource indicator (URI)), credentials or access tokens for authentication, and any necessary routing information. When a client 106 issues a query that involves a database object in a different region 102, the data warehouse system 108 in the local region first consults its local data lake metastore 114. Upon encountering the cross-regional resource link 120, it uses the details in the cross-regional resource link 120 to establish a secure connection to the remote data lake metastore 114. Once connected, it retrieves the required data lake metadata 118, such as table schema, data format, or file location. This data lake metadata 118 is then used by the local data warehouse system 108 to understand how to access the actual data lake data 116 and how to execute the query properly. By utilizing these cross-regional resource links 120, the data warehouse system 108 can efficiently query and manage data lake metadata 118 distributed across the multi-region federated data lake system 100, ensuring seamless access to data lake data 116 and data lake metadata 118 irrespective of their physical location. [Column 24 line 4-15], The local driver 124 utilizes the information contained in the cross-regional resource link 120—such as the location (URI or address) of the remote data lake metastore 114, and possibly required authentication credentials—to establish a connection with the remote data lake metastore 114 in the remote region 102. Once this connection is successfully established, the local driver 124 requests the data lake metadata 118 for the specific database object referenced in the original query. This data lake metadata 118 could include detailed information about the database object's structure, schema, physical data location, and other pertinent characteristics that are useful for processing the query.)
Although Kandregula discloses utilizing access token to authenticate to access federated data lakes.
Kandregula does not explicitly disclose after receipt of a token request.
Rahman teaches after receipt of a token request. ([Column 13 line 64-67 and Column 14 line 1-24], In some embodiments, a producer processing cluster 310 may implement a leader node which may receive a request to create a datashare 402, which may allow data processing cluster 310 to respond to requests for metadata and access credentials for accessing the database data. [Column 15 line 34-55], The datashare metadata service 322 may access database permission data in order to determine whether the association between a user of with the query engine and the datashare may proceed (e.g., yes, no because not authorized, no because an unauthorized region, etc.), and based on the determination return credentials key to encrypt the request for metadata/access credentials 521.)
It would have been obvious to a person with ordinary skill in the art before the effective filing date of the invention, to combine the teachings of Kandregula wherein discovery result of list of federated data lakes is transmitted to a client application, an access token is utilized as a credential, metadata corresponding to a data lake is provided to grant access to the data lake, into teachings of Rahman wherein a token request (i.e. credential request) is received and provided to a user/client, because this would enhance the teachings of Kandregula wherein by providing the token based on request, it allows authentication and access to plurality of federated data lakes based on corresponding credential/token requested/received to ensure security and proper access. [Rahman column 14-15]
As per claim 2, rejection of claim 1 is incorporated:
Kandregula teaches wherein the discovery result identifies the services corresponding to the first data lake and second services corresponding to a second data lake, the second services including at least one of a storage service, a compute service, or a database service. ([Column 1 line 30-67], FIG. 7 is a block diagram of an example multi-tenant provider network that provides a storage service and a hardware virtualization service to customers and in which the techniques disclosed herein for cross-regional resource links in a federated data lake management and integration system are implemented. [Column 27 line 34-47], In an embodiment, cross-regional resource links serve as a useful mechanism for navigating and accessing metadata across disparate regions within the federated data lake system 100. When searching the metastore for metadata, these links enable the data warehouse system 108 to extend its reach beyond the local data store to encompass metadata stored in remote regions. Essentially, when a query or a metadata request is initiated and the local metastore is searched, the data warehouse system 108 may encounter a cross-regional resource link. This link is a reference that points to a specific location in a remote metastore, indicating that relevant or supplementary metadata about a database object is stored in a data lake outside the local region. [Column 28 line 1-24], FIG. 6 illustrates an example multi-tenant provider network environment in which the techniques disclosed herein for cross-regional resource links in a federated data lake management and integration system are implemented. A provider network 600 provides resource virtualization to customers via one or more virtualization services 610 that allow customers to purchase, rent, or otherwise obtain instances 612 of virtualized resources, including but not limited to computation and storage resources, implemented on devices within the provider network or networks in one or more data centers. Local Internet Protocol (IP) addresses 616 is associated with the resource instances 612; the local IP addresses are the internal network addresses of the resource instances 612 on the provider network 600. In some examples, the provider network 600 provides public IP addresses 614 and/or public IP address ranges (e.g., Internet Protocol version 4 (IPv4) or Internet Protocol version 6 (IPv6) addresses) that customers obtain from the provider network 600.)
Rahman also teaches ([Column 10 line 46-67 and column 11 line 1-14], In some embodiments a data lake management service 220 may include the federated permission management 280, data ingestion engine 212, and data analysis engine 214. The data lake management service 220 may use the data ingestion engine 212 and the data analysis to integrate various data lake service that allow ingesting, cleaning, cataloging, transforming, and securing data for various applications. In some embodiments, the data lake management service 220 may provide clients 250 a central console where the client can discover data sources, set up transformation jobs to move data to the data lake services 270, remove duplicates/match records, catalog data for access by analytic tools, configure data access and security policies, audit and control access from analytics and machine learning (“ML”) services, and perform other governance functions for the data lake services 270. Furthermore, in some embodiments, data lake management service 220 may be used to integrate data transformation jobs spanning various services of the provider network. Data lake management service 220 may be used to configure data flows, centralize orchestration of the data flows, and monitor the transformation jobs. In some embodiments, the federated permission management engine 280 may verify that the respective queries from the client 250 to the data processing service 210 to have permission to access the requested data objects of the data set. The data lake management service 220 may provide to the clients, via the data processing service 210, a custom view of one or more data objects of the data stored in the data lake service 270 based on the respective access permissions of the client without the need to copy the data objects from one location to another (as further discussed in FIG. 5). The data lake management service 220 may facilitate access requests by various clients 250 having differing permission, the customized authorization metadata to allow the data processing service 210 to retrieve the relevant data from the data lake services 270 as discussed in FIG. 5.)
As per claim 3, rejection of claim 2 is incorporated:
Rahman teaches wherein the first data lake is in a private cloud and the second data lake is in a public cloud. ([Column 5 line 54-67], FIG. 2 is a logical block diagram illustrating a provider network offering a data lake management service that manages authorization between data lake services and data processing services and provides access to custom data sets for respective clients, according to some embodiments. Provider network 200 may be a private or closed system or may be set up by an entity such as a company or a public sector organization to provide one or more services (such as various types of cloud-based storage) accessible via the Internet and/or other networks to clients 250.)
As per claim 4, rejection of claim 1 is incorporated:
Rahman teaches wherein the access token is a JavaScript Object Notation (JSON) Web Token. ([Column 9 line 57-67 and Column 10 line 1-17], Data lake service(s) 270 may also include various kinds of object or file data stores for putting, updating, and getting data objects or files. For example, one data lake service 270 may be an object-based data store that allows for different data objects of different formats or types of data, such as structured data (e.g., database data stored in different database schemas), unstructured data (e.g., different types of documents or media content), or semi-structured data (e.g., different log files, human-readable data in different formats like JavaScript Object Notation (JSON) or Extensible Markup Language (XML)) to be stored and managed according to a key value or other unique identifier that identifies the object. [Column 13 line 64-67 and Column 14 line 1-24], In some embodiments, a producer processing cluster 310 may implement a leader node which may receive a request to create a datashare 402, which may allow data processing cluster 310 to respond to requests for metadata and access credentials for accessing the database data. [Column 15 line 34-55], The datashare metadata service 322 may access database permission data in order to determine whether the association between a user of with the query engine and the datashare may proceed (e.g., yes, no because not authorized, no because an unauthorized region, etc.), and based on the determination return credentials key to encrypt the request for metadata/access credentials 521.)
As per claim 5, rejection of claim 1 is incorporated:
Kandregula teaches wherein the programmable circuitry is to specify in the metadata a type of data warehouse of one of the services and a connection type to access the one of the services. ([Column 10 line 37-45], When the data warehouse system 108 in a region 102 receives a database query language statement intended to query the data lake data 116, it relies on data lake metadata 118 from the data lake metastore 114 in the region 102 to process the query effectively. The data lake metastore 114 contains detailed data lake metadata 118 about the structure and properties of the data lake data 116, such as table schemas, column data types, file formats, data partitioning information, and file locations [Column 18 line 20-50], The server 122 facilitates the execution of queries by supporting various communication protocols. For example, the server 122 may support JDBC (Java Database Connectivity) and ODBC (Open Database Connectivity). These protocols are standards for interacting with databases, allowing a range of client 106 applications—from data analytics tools to business intelligence software—to connect to the server 122 and perform data querying operations. Through JDBC and ODBC, clients 106 can submit SQL-like queries to the server 122, which are then processed by the driver 124 of the data warehouse system 108, leveraging the distributed data processing systems 110's capability to manage and query the data lake data 166 stored in the distributed data storage system 112. In addition to JDBC (Java Database Connectivity) and ODBC (Open Database Connectivity) protocols, the sever 122 may support several other types of interfaces to cater to diverse client 106 needs and integration scenarios. One such interface is the “Thrift” interface or the like, which is based on or like APACHE THRIFT, a software framework for scalable cross-language services development. The Thrift interface allows clients written in languages other than Java, like Python or C++, to interact with the server 122, making the data warehouse system 108 accessible to a broader range of applications and development environments. Another interface could be a RESTful API (Representational State Transfer Application Programming Interface), which enables web-based interactions with the server 122. RESTful APIs are used for building web services that are lightweight, maintainable, and scalable, allowing easy integration with web applications and services.)
Rahman also teaches ([Column 6 line 41-54], In some embodiments, provider network 200 may implement various computing resources or services, such as data processing service(s) 210, (e.g., relational database services, non-relational database services, a map reduce service, a data warehouse service, and/or other large scale data processing services or various other types database services), data lake service(s) 270 (e.g., database services, object storage services, or block-based storage services that may implement a centralized data store for various types of data), data lake management service 220, and/or any other type of network based services (which may include a virtual compute service and various other types of storage, processing, analysis, communication, event handling, visualization, and security services not illustrated). [Column 7 line 25-40], Data processing service 210 may work effectively with database schemas of various types and/or organizations, in different embodiments. In some embodiments, clients/subscribers may submit queries in a number of ways, e.g., interactively via an SQL interface to the database system. In other embodiments, external applications and programs may submit queries using Open Database Connectivity (ODBC) and/or Java Database Connectivity (JDBC) driver interfaces to the database system. For instance, data processing service 210 may implement, in some embodiments, a data warehouse service, that utilizes another data processing service, to execute portions of queries or other access requests with respect to data that is stored in a remote data store, such as data lake service(s) 270 (or a data store external to provider network 200) to implement distributed data processing for distributed data sets.)
As per claim 6, rejection of claim 1 is incorporated:
Kandregula teaches wherein the programmable circuitry is to specify a storage service, a compute service, and a structured query language (SQL) service in the metadata, the storage service, the compute service, and the SQL service corresponding to the first data lake. ([Column 10 line 37-45], When the data warehouse system 108 in a region 102 receives a database query language statement intended to query the data lake data 116, it relies on data lake metadata 118 from the data lake metastore 114 in the region 102 to process the query effectively. The data lake metastore 114 contains detailed data lake metadata 118 about the structure and properties of the data lake data 116, such as table schemas, column data types, file formats, data partitioning information, and file locations [Column 18 line 20-50], The server 122 facilitates the execution of queries by supporting various communication protocols. For example, the server 122 may support JDBC (Java Database Connectivity) and ODBC (Open Database Connectivity). These protocols are standards for interacting with databases, allowing a range of client 106 applications—from data analytics tools to business intelligence software—to connect to the server 122 and perform data querying operations. Through JDBC and ODBC, clients 106 can submit SQL-like queries to the server 122, which are then processed by the driver 124 of the data warehouse system 108, leveraging the distributed data processing systems 110's capability to manage and query the data lake data 166 stored in the distributed data storage system 112. In addition to JDBC (Java Database Connectivity) and ODBC (Open Database Connectivity) protocols, the sever 122 may support several other types of interfaces to cater to diverse client 106 needs and integration scenarios. One such interface is the “Thrift” interface or the like, which is based on or like APACHE THRIFT, a software framework for scalable cross-language services development. The Thrift interface allows clients written in languages other than Java, like Python or C++, to interact with the server 122, making the data warehouse system 108 accessible to a broader range of applications and development environments. Another interface could be a RESTful API (Representational State Transfer Application Programming Interface), which enables web-based interactions with the server 122. RESTful APIs are used for building web services that are lightweight, maintainable, and scalable, allowing easy integration with web applications and services.)
Rahman also teaches ([Column 6 line 41-54], In some embodiments, provider network 200 may implement various computing resources or services, such as data processing service(s) 210, (e.g., relational database services, non-relational database services, a map reduce service, a data warehouse service, and/or other large scale data processing services or various other types database services), data lake service(s) 270 (e.g., database services, object storage services, or block-based storage services that may implement a centralized data store for various types of data), data lake management service 220, and/or any other type of network based services (which may include a virtual compute service and various other types of storage, processing, analysis, communication, event handling, visualization, and security services not illustrated). [Column 7 line 25-40], Data processing service 210 may work effectively with database schemas of various types and/or organizations, in different embodiments. In some embodiments, clients/subscribers may submit queries in a number of ways, e.g., interactively via an SQL interface to the database system. In other embodiments, external applications and programs may submit queries using Open Database Connectivity (ODBC) and/or Java Database Connectivity (JDBC) driver interfaces to the database system. For instance, data processing service 210 may implement, in some embodiments, a data warehouse service, that utilizes another data processing service, to execute portions of queries or other access requests with respect to data that is stored in a remote data store, such as data lake service(s) 270 (or a data store external to provider network 200) to implement distributed data processing for distributed data sets.)
As per claim 7, rejection of claim 6 is incorporated:
Kandregula teaches wherein the programmable circuitry is to format the metadata to specify: a target uniform resource locator corresponding to the first data lake; a storage resource type corresponding to the storage service; a compute resource type corresponding to the compute service; and a data warehouse resource type corresponding to the SQL service. ( [Column 15 line 17-41], In some instances, a cross-regional resource link 120 contains information necessary for establishing a connection to the remote data lake metastore 114, such as the network address (like a uniform resource locator (URL) or uniform resource indicator (URI)), credentials or access tokens for authentication, and any necessary routing information. When a client 106 issues a query that involves a database object in a different region 102, the data warehouse system 108 in the local region first consults its local data lake metastore 114. Upon encountering the cross-regional resource link 120, it uses the details in the cross-regional resource link 120 to establish a secure connection to the remote data lake metastore 114. Once connected, it retrieves the required data lake metadata 118, such as table schema, data format, or file location. This data lake metadata 118 is then used by the local data warehouse system 108 to understand how to access the actual data lake data 116 and how to execute the query properly. By utilizing these cross-regional resource links 120, the data warehouse system 108 can efficiently query and manage data lake metadata 118 distributed across the multi-region federated data lake system 100, ensuring seamless access to data lake data 116 and data lake metadata 118 irrespective of their physical location. [Column 10 line 37-45], When the data warehouse system 108 in a region 102 receives a database query language statement intended to query the data lake data 116, it relies on data lake metadata 118 from the data lake metastore 114 in the region 102 to process the query effectively. The data lake metastore 114 contains detailed data lake metadata 118 about the structure and properties of the data lake data 116, such as table schemas, column data types, file formats, data partitioning information, and file locations [Column 18 line 20-50], The server 122 facilitates the execution of queries by supporting various communication protocols. For example, the server 122 may support JDBC (Java Database Connectivity) and ODBC (Open Database Connectivity). These protocols are standards for interacting with databases, allowing a range of client 106 applications—from data analytics tools to business intelligence software—to connect to the server 122 and perform data querying operations. Through JDBC and ODBC, clients 106 can submit SQL-like queries to the server 122, which are then processed by the driver 124 of the data warehouse system 108, leveraging the distributed data processing systems 110's capability to manage and query the data lake data 166 stored in the distributed data storage system 112. In addition to JDBC (Java Database Connectivity) and ODBC (Open Database Connectivity) protocols, the sever 122 may support several other types of interfaces to cater to diverse client 106 needs and integration scenarios. One such interface is the “Thrift” interface or the like, which is based on or like APACHE THRIFT, a software framework for scalable cross-language services development. The Thrift interface allows clients written in languages other than Java, like Python or C++, to interact with the server 122, making the data warehouse system 108 accessible to a broader range of applications and development environments. Another interface could be a RESTful API (Representational State Transfer Application Programming Interface), which enables web-based interactions with the server 122. RESTful APIs are used for building web services that are lightweight, maintainable, and scalable, allowing easy integration with web applications and services.)
Rahman also teaches ([Column 6 line 41-54], In some embodiments, provider network 200 may implement various computing resources or services, such as data processing service(s) 210, (e.g., relational database services, non-relational database services, a map reduce service, a data warehouse service, and/or other large scale data processing services or various other types database services), data lake service(s) 270 (e.g., database services, object storage services, or block-based storage services that may implement a centralized data store for various types of data), data lake management service 220, and/or any other type of network based services (which may include a virtual compute service and various other types of storage, processing, analysis, communication, event handling, visualization, and security services not illustrated). [Column 7 line 25-40], Data processing service 210 may work effectively with database schemas of various types and/or organizations, in different embodiments. In some embodiments, clients/subscribers may submit queries in a number of ways, e.g., interactively via an SQL interface to the database system. In other embodiments, external applications and programs may submit queries using Open Database Connectivity (ODBC) and/or Java Database Connectivity (JDBC) driver interfaces to the database system. For instance, data processing service 210 may implement, in some embodiments, a data warehouse service, that utilizes another data processing service, to execute portions of queries or other access requests with respect to data that is stored in a remote data store, such as data lake service(s) 270 (or a data store external to provider network 200) to implement distributed data processing for distributed data sets. [Column 23 line 1-15], To perform a web services request, a network-based services client may assemble a message including the request and convey the message to an addressable endpoint (e.g., a Uniform Resource Locator (URL)) corresponding to the web service, using an Internet-based application layer transfer protocol such as Hypertext Transfer Protocol (HTTP).)
As per claim 8, rejection of claim 1 is incorporated:
Kandregula teaches wherein the programmable circuitry is to include a target uniform resource locator corresponding to the first data lake and a token type of the access token in the metadata. ([Column 6 line 42-67], Distributed data storage system 112 applies access controls to ensure that only authorized principals can access specific data sets. In some instances, such access control is accomplished and managed through any or all of: identity and access management (IAM) policies, role-based access control (RBAC), and attribute-based access control (ABAC)… When a principal (e.g., a user, a service, a role, or an application) attempts to access data lake data 116 within the data lake, the distributed data storage system 112 first authenticates the principal's identity, using credentials like usernames and passwords, tokens, digital certificates, or other suitable authentication mechanism. After authentication, the distributed data storage system 112 determines the principal's permissions using predefined access policies… These policies are configured by administrators and define what actions (like read, write, delete) a principal can perform on which data sets. In role-based access control, principals are assigned to roles, and each role has specific permissions. For example, a data analyst might have read-only access to certain data sets, while a data engineer might have broader access that includes the ability to modify or delete data. Attribute-based access control takes this a step further by considering additional attributes (like the time of access, the location of the user, or the classification of the data) in making access decisions. In distributed data storage system 112, these controls are enforced across regions 102, ensuring consistent policy application regardless of which region 102 the particular data lake data 116 being accessed is stored. [Column 15 line 17-41], In some instances, a cross-regional resource link 120 contains information necessary for establishing a connection to the remote data lake metastore 114, such as the network address (like a uniform resource locator (URL) or uniform resource indicator (URI)), credentials or access tokens for authentication, and any necessary routing information. When a client 106 issues a query that involves a database object in a different region 102, the data warehouse system 108 in the local region first consults its local data lake metastore 114. Upon encountering the cross-regional resource link 120, it uses the details in the cross-regional resource link 120 to establish a secure connection to the remote data lake metastore 114. Once connected, it retrieves the required data lake metadata 118, such as table schema, data format, or file location. This data lake metadata 118 is then used by the local data warehouse system 108 to understand how to access the actual data lake data 116 and how to execute the query properly. By utilizing these cross-regional resource links 120, the data warehouse system 108 can efficiently query and manage data lake metadata 118 distributed across the multi-region federated data lake system 100, ensuring seamless access to data lake data 116 and data lake metadata 118 irrespective of their physical location. [Column 24 line 4-15], The local driver 124 utilizes the information contained in the cross-regional resource link 120—such as the location (URI or address) of the remote data lake metastore 114, and possibly required authentication credentials—to establish a connection with the remote data lake metastore 114 in the remote region 102. Once this connection is successfully established, the local driver 124 requests the data lake metadata 118 for the specific database object referenced in the original query. This data lake metadata 118 could include detailed information about the database object's structure, schema, physical data location, and other pertinent characteristics that are useful for processing the query.)
Rahman also teaches ([Column 13 line 64-67 and Column 14 line 1-24], In some embodiments, a producer processing cluster 310 may implement a leader node which may receive a request to create a datashare 402, which may allow data processing cluster 310 to respond to requests for metadata and access credentials for accessing the database data. [Column 15 line 34-55], The datashare metadata service 322 may access database permission data in order to determine whether the association between a user of with the query engine and the datashare may proceed (e.g., yes, no because not authorized, no because an unauthorized region, etc.), and based on the determination return credentials key to encrypt the request for metadata/access credentials 521.)
As per claims 12-19, these are non-transitory machine-readable storage medium claims corresponding to the apparatus claims 1-8. Therefore, rejected based on similar rationale.
As per claim 20, rejection of claim 12 is incorporated:
Rahman teaches wherein the client application is in a first cloud and the first data lake is in a second cloud separate from the first cloud. ([Column 5 line 54-67], FIG. 2 is a logical block diagram illustrating a provider network offering a data lake management service that manages authorization between data lake services and data processing services and provides access to custom data sets for respective clients, according to some embodiments. Provider network 200 may be a private or closed system or may be set up by an entity such as a company or a public sector organization to provide one or more services (such as various types of cloud-based storage) accessible via the Internet and/or other networks to clients 250.)
As per claim 21, rejection of claim 12 is incorporated:
Rahman teaches wherein the instructions are to cause the programmable circuitry to cause the transmission of the discovery result to the client application after receipt of authentication credentials of a user. ([Column 13 line 64-67 and Column 14 line 1-24], In some embodiments, a producer processing cluster 310 may implement a leader node which may receive a request to create a datashare 402, which may allow data processing cluster 310 to respond to requests for metadata and access credentials for accessing the database data. [Column 15 line 34-55], The datashare metadata service 322 may access database permission data in order to determine whether the association between a user of with the query engine and the datashare may proceed (e.g., yes, no because not authorized, no because an unauthorized region, etc.), and based on the determination return credentials key to encrypt the request for metadata/access credentials 521.)
Kandregula teaches transmission of the discovery result to the client application ([Column 1 line 60-67 and column 2 line 1-15], Disclosed herein are systems, methods, and non-transitory computer-readable media (generally, “techniques”) for cross-regional resource links in a federated data lake management and integration system (“federated data lake system”), spread across multiple regions within a multi-tenant provider network. When a query language statement is received from a client at a data warehouse system server in one region, the federated data lake system's driver in the region identifies the referenced database or table. It then retrieves local metadata about this object. If the metadata includes a link to resources in another region, the driver accesses additional metadata from a remote data lake metastore in that second region. Utilizing this second set of metadata, the driver creates a query execution plan. This plan is used to instruct a distributed data processing system to execute data processing jobs against a data lake storage system. Finally, the data satisfying the query is returned to the client. This approach allows for efficient querying and data retrieval across different regions within the federated data lake system.)
As per claim 22, rejection of claim 12 is incorporated:
Rahman teaches wherein the instructions are to cause the programmable circuitry to obtain the access token from a trusted token authority. ([Column 13 line 64-67 and Column 14 line 1-24], In some embodiments, a producer processing cluster 310 may implement a leader node which may receive a request to create a datashare 402, which may allow data processing cluster 310 to respond to requests for metadata and access credentials for accessing the database data. [Column 15 line 34-55], The datashare metadata service 322 may access database permission data in order to determine whether the association between a user of with the query engine and the datashare may proceed (e.g., yes, no because not authorized, no because an unauthorized region, etc.), and based on the determination return credentials key to encrypt the request for metadata/access credentials 521. [Column 15 line 34-55], The datashare metadata service 322 may access database permission data in order to determine whether the association between a user of with the query engine and the datashare may proceed (e.g., yes, no because not authorized, no because an unauthorized region, etc.), and based on the determination return credentials key to encrypt the request for metadata/access credentials 521. The consumer processing cluster 340 may encrypt the metadata request 521 sent to the federated permission management service 280.)
As per claim 23, this is a method claim corresponding to the apparatus claim 1. Therefore, rejected based on similar rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Binkert et al. (Pat 10769148) discloses performing federated data processing of data stored in data lakes. Processing request may include access credentials (e.g. token).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DONG U KIM whose telephone number is (571)270-1313. The examiner can normally be reached 9:00am - 5:00pm.
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, Bradley Teets can be reached at 5712723338. 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.
/DONG U KIM/Primary Examiner, Art Unit 2197
Prosecution Insights