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 .
This office action is in response to Applicant’s amendment filed on 02/04/2026. Claims 2, 11, and 17 have been cancelled. Claims 1, 3-8, 10, 12-16, 18, and 19 have been amended. New claims 21-23 have been added. Therefore, Claims 1, 3-10, 12-16 and 18-23 are pending. Any examiner’s note, objection, or rejection not repeated is withdrawn due to Applicant’s amendment.
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.
Claims 1, 3-10, 12-16 and 18-23 are rejected under 35 U.S.C. 103 as being unpatentable over Brossard et al. (US 20220100758 A1) in view of Rudraraju et al. (US 20220012045 A1), hereinafter referred to as Brossard and Rudraraju, respectively.
Regarding Claim 1, Brossard discloses A method for executing data access requests in a distributed storage system ( [0015] The description that follows includes systems, methods, techniques, instruction sequences, and computing machine program products that embody illustrative embodiments of the disclosure.; [0024] Execution platform 114 is coupled to multiple data storage devices 124-1 to 124-n that are part of a cloud computing storage platform 104 […] cloud computing storage platform 104 may include distributed file systems. Please note that the method of the disclosure with an execution platform 114 coupled to multiple data storage devices 124-1 to 124-n that are part of a cloud computing storage platform 104, where 104 includes distributed file systems, corresponds to Applicant’s method for executing data access requests in a distributed storage system.):
initiating, by a service application executing on a first computing node, the first computing node corresponding to a single service node, a data access request to manage service data using a plurality of distributed data storage nodes that store service data for the service application ([0025] The execution platform 114 comprises a plurality of compute nodes (e.g., virtual warehouses). A set of processes on a compute node executes a query plan compiled by the compute service manager 112.; [0032] a request processing service 202 manages received data storage requests and data retrieval requests (e.g., jobs to be performed on database data). For example, the request processing service 202 may determine the data necessary to process a received query (e.g., a data storage request or data retrieval request). The data may be stored in a cache within the execution platform 114 or in a data storage device in cloud computing storage platform 104. Please note that a compute node of the execution platform 114 coupled with the request processing service 202 of the compute service manager 112 to initiate data retrieval requests to be performed on data stored in the distributed storage of the cloud computing storage platform corresponds to Applicant’s initiating a data access request to manage service data using a plurality of distributed data storage nodes that store service data for the service, as the request processing service 202 corresponds to the service application executing on a first computing node corresponding to a single service node, i.e., one of the plurality, and the distributed storage of the cloud computing platform 104 corresponds to Applicant’s plurality of distributed data storage nodes that store service data for the service application. );
communicating, by the service application to a router application executing on the first computing node, the data access request ([0051] The foreground GS 400 may receive query requests and develop query plans to execute the query requests. The foreground GS 400 may broker requests to nodes 410.1-410.N that execute a query plan, as explained in further detail herein. Please note that the foreground GS 400 brokering query requests to nodes 410.1-410.N to execute the query plan corresponds to Applicant’s router application executing on the first computing node that has the data access communicated to it by the service application, as the previously disclosed request processing service 202 manages the received data retrieval requests, which are then brokered by the foreground GS 400.);
determining, by the router application, at least one data storage node from the plurality of distributed data storage nodes that can satisfy the data access request ([0025] A set of processes on a compute node executes a query plan compiled by the compute service manager 112.; [0030] compute service manager 112 may determine what data is needed to process a task and further determine which nodes within the execution platform 114 are best suited to process the task. Please note that the determining what data is needed to process a task corresponds to determining at least one data storage node from the plurality of distributed data storage nodes that can satisfy the data access request, as it would select a data storage node from the previously disclosed distributed storage of cloud computing platform 104 that contains the data needed to satisfy the request. Furthermore, since the foreground GS 400 develops query plans to execute the query requests, which can also be compiled by the compute service manager 112, this corresponds to doing so by the router application, as it would accomplish the same outcome.);
Brossard does not explicitly disclose wherein the service application is executed within a service pod at the first computing node, the router application is executed within a router pod at the first computing node, and the data access request is communicated locally between the service pod and the router pod at the first computing node;
and transmitting, by the router application to the at least one data storage node, the data access request for fulfillment of the data access request on behalf of the service application.
However, Rudraraju discloses wherein the service application is executed within a service pod at the first computing node, the router application is executed within a router pod at the first computing node, and the data access request is communicated locally between the service pod and the router pod at the first computing node ([0049] one or more APIs 32 (also referred to as a “web service”) to system 16 resident processes, which allow users or developers at user systems 12 to access the resident processes. The API(s) 32 is/are interface(s) for software components to communicate with each other.; [0052] Private APIs are APIs 32 that are private or internal to the system 16, which allows system applications (e.g., tenant management process 110, system process 102, query engine(s) 103, crypto processor(s) 105, and validation processor(s) 105 to access other system applications. […] use of the private APIs 32 may be restricted to machines inside a private network (or an enterprise network); [0065] A pod is the basic execution unit of a Kubernetes application, and is the smallest and simplest unit in the Kubernetes object model that can be created and deployed. A pod represents a unit of deployment, which is a single instance of an application in Kubernetes. A pod may include a single container or a small number of containers that are tightly coupled and that share resources. Additionally or alternatively, a pod represents one or more processes running on a cluster. A “cluster” refers to a set of worker machines or nodes (e.g., one or more physical and/or virtual machines) that run containerized applications. Each cluster has at least one worker node. Please note that each pod representing an instance of an application corresponds to Applicant’s service and router applications being executed within respective pods, running in a cluster on a node corresponds to executing at the first computing node, and software components using APIs 32 to communicate with each other corresponds to the data access request being communicated locally between the service and router pods at the first computing node, as, since the two pods could be on the same cluster and use an API to communicate, this corresponds to communicating locally at the first computing node. Additionally, since APIs may be private APIs internal to the system 16 for system applications to access other system applications, the data access requests are being communicated locally, i.e., internally to one system.).
and transmitting, by the router application to the at least one data storage node, the data access request for fulfillment of the data access request on behalf of the service application ([0054] In this regard, each application server 100 is configurable or operable to perform various DB functions (e.g., indexing, querying, etc.) […] In some such implementations, an interface system implementing a load balancing function (e.g., an F5 Big-IP load balancer) is communicably coupled between the application servers 100 and the user systems 12 to distribute requests to the application servers 100. In one implementation, the load balancer uses a least-connections algorithm to route user requests to the app servers 100. Please note that the load balancer coupled between the app servers 100 and the user systems 12 to route user requests to the app servers 100 to perform DB functions such as querying corresponds to Applicant’s router application transmitting the data access request for fulfillment of the data access request on behalf of the service application to the data storage node, as it routes the request to be fulfilled with the specifically requested data on behalf of the service application of the app servers 100.).
Brossard and Rudraraju are both considered to be analogous to the claimed invention because they are in the same field of computer request processing. Therefore, it would have been obvious to someone of ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Brossard to incorporate the teachings of Rudraraju to modify the system with a service application executing on a first computing node that initiates a data access request and communicates it to a router application that determines a data storage node that can satisfy it to transmit the data access request for fulfillment of the data access request on behalf of the service application and have the service and router applications executed within respective service and router pods at the first computing node, with the data access request communicated locally between them, allowing for improved efficiency of request processing and system security, as described in Rudraraju.
Regarding Claim 3, Brossard-Rudraraju as described in Claim 1, Brossard further discloses wherein the at least one data storage node is remote to the first computing node, and the data access request is transmitted from the router pod to the at least one data storage node over a communications network ([0018] The 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). Please note that the network-based data warehouse system 102 that is used to access external remotely located data corresponds to Applicant’s data storage node being remote to the first computing node and the data access request is transmitted from the router pod to the at least one data storage node over a communications network, as it uses a network-based system to access the remotely located data to fulfill the previously disclosed data access requests.).
Regarding Claim 4, Brossard-Rudraraju as described in Claim 1, Rudraraju further discloses wherein the at least one data storage node is the first computing node ([0042] . Each application server 100 (also referred to herein as an “app server”, an “API server”, an “HTTP application server,” a “worker node”, and/or the like) is configurable or operable to communicate with tenant DB 22 and the tenant data 23 therein, as well as system DB 24 and the system data 25 therein, to serve requests received from the user systems 12. Please note that the application server 100, that can be a worker node, configurable to communicate with tenant data 23 and system data 25 corresponds to Applicant’s data storage node being the first computing node, as the node can serve requests for the data that is stored.),
and the data access request is transmitted locally from the router pod to a pod comprising the at least one data storage node ([0065] A pod may include a single container or a small number of containers that are tightly coupled and that share resources. Additionally or alternatively, a pod represents one or more processes running on a cluster. A “cluster” refers to a set of worker machines or nodes (e.g., one or more physical and/or virtual machines) that run containerized applications. Each cluster has at least one worker node. A pod encapsulates an application's container (or multiple containers), storage resources, a unique network identity (e.g., IP address or the like). Please note that pods running in a cluster that each have their own processes, where each pod has a unique network identity, corresponds to Applicant’s data access request being transmitted locally from the router pod to a pod comprising the at least one data storage node, since it is known in the art that distinct network identities of pods on a cluster would allow for their applications to transmit information locally to each other, including the previously disclosed data access request.).
Regarding Claim 5, Brossard-Rudraraju as described in Claim 1, Rudraraju further discloses wherein the service application communicates the data access request to the router application at the router pod using a router software development kit (SDK) message ([0057] the system 16 (e.g., an application server 100 in the system 16) may include one or more query engines 103, which is/are a […] SDK […] that takes a description of a search request (e.g., a user query), processes/evaluates the search request, executes the search request, and returns the results back to the calling party. Please note that the system 16 including the application server 100 including query engines 103 which is a SDK that executes a search request corresponds to Applicant’s service application communicating the data access request to the router application at the router pod using a router SDK message, as the SDK can receive queries corresponding to a router SDK message, which could include a data access request.).
Regarding Claim 6, Brossard-Rudraraju as described in Claim 1, Rudraraju further discloses wherein the service pod and the router pod each comprise a Kubernetes pod ([0065] A pod is the basic execution unit of a Kubernetes application, and is the smallest and simplest unit in the Kubernetes object model that can be created and deployed. A pod represents a unit of deployment, which is a single instance of an application in Kubernetes. A pod may include a single container or a small number of containers that are tightly coupled and that share resources. Additionally or alternatively, a pod represents one or more processes running on a cluster. A “cluster” refers to a set of worker machines or nodes (e.g., one or more physical and/or virtual machines) that run containerized applications. Each cluster has at least one worker node. Please note that the pod representing a unit of deployment, which is a single instance of an application in Kubernetes, corresponds to Applicant’s service pod and router pod each comprising a Kubernetes pod, as they are instances of Kubernetes applications.).
Regarding Claim 7, Brossard-Rudraraju as described in Claim 1, Rudraraju further discloses wherein the service pod is one of a plurality of service pods executed at the first computing node ([0065] A pod is the basic execution unit of a Kubernetes application, and is the smallest and simplest unit in the Kubernetes object model that can be created and deployed. A pod represents a unit of deployment, which is a single instance of an application in Kubernetes. A pod may include a single container or a small number of containers that are tightly coupled and that share resources. Additionally or alternatively, a pod represents one or more processes running on a cluster. A “cluster” refers to a set of worker machines or nodes (e.g., one or more physical and/or virtual machines) that run containerized applications. Each cluster has at least one worker node. Please note that since the pods run on a cluster, where each cluster has a worker node, this corresponds to Applicant’s service pod being of a plurality of service pods executed at the first computing node, as it is known in the art that a cluster may contain multiple pods.),
and wherein each of the plurality of service pods issues data access requests through the router pod ([0049] one or more APIs 32 (also referred to as a “web service”) to system 16 resident processes, which allow users or developers at user systems 12 to access the resident processes. The API(s) 32 is/are interface(s) for software components to communicate with each other.; [0054] In some such implementations, an interface system implementing a load balancing function (e.g., an F5 Big-IP load balancer) is communicably coupled between the application servers 100 and the user systems 12 to distribute requests to the application servers 100. In one implementation, the load balancer uses a least-connections algorithm to route user requests to the app servers 100. Please note that APIs 32 allowing software components to communicate with each other, such as with the load balancer that routes user requests to the app servers 100 from the user systems 12, this corresponds to each of the plurality of service pods issuing data access requests through the router pod, as the pods could use APIs to communicate with each other, such as for the user system 12 to convey user requests to the load balancing function to be routed.).
Regarding Claim 8, Brossard-Rudraraju as described in Claim 1, Brossard further discloses determining, by an authorizer application executed within the router pod at the first computing node, whether the service is authorized to issue the data access request ([0026] The cloud computing storage platform 104 also comprises […] a web proxy 120 […] The web proxy 120 handles tasks involved in accepting and processing concurrent API calls, including […] authorization and access control. Please note that the web proxy 120 that handles tasks involved in accepting and processing API calls including authorization corresponds to Applicant’s authorizer application executed within the router pod at the first computing node that determines whether the service is authorized to issue the data access request, as it decides whether the service issuing the API call is authorized to do so.);
in response to the determining that the service is authorized, determining, by the router application, the at least one data storage node from among the plurality of distributed data storage nodes using a deterministic selection process based on the key ([0030] compute service manager 112 may determine what data is needed to process a task and further determine which nodes within the execution platform 114 are best suited to process the task […]Metadata stored in the database 116 assists the compute service manager 112 in determining which nodes in the execution platform 114 have already cached at least a portion of the data needed to process the task.; [0035] 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. Please note that using metadata to assist the compute service manager 112 in determining which nodes in the execution platform 114 have cached the data needed to process the task, and the configuration and metadata manager 216 using the metadata to determine which data micro-partitions need to be access to retrieve data for processing a particular task corresponds to Applicant’s determining the at least one data storage node from among the plurality of distributed data storage nodes using a deterministic selection process based on the key, as a request seeking a specific piece of data would deterministically be routed to the micro-partition that contains that particular data. Furthermore, since it does so based on metadata, it is known in the art that requests, such as API requests, often include keys; therefore, this could be used in the process to determine the data storage node.);
Rudraraju further discloses based on a key corresponding to service data that is a subject of the data access request ([0031] In some embodiments, the user system 12 may include Trusted Compute resources that preserve data confidentiality, execution integrity and enforces data access policies. The Trusted Compute resources may be used to store cryptographic keys, digital certificates, credentials, and/or other sensitive information, and could be used to operate some aspects of an app 12y […] an app 12y is capable of interfacing with the Trusted Compute resources using a suitable API 32. Please note that since the user system 12 includes Trusted Compute resources to enforce data access policies such as cryptographic keys corresponds to Applicant’s key that is the subject of the data access request, as these keys are used to enforce data access policies, and therefore the keys for particular data that are a subject of requests would be checked.)
and initiating transmission, by the router application to the at least one data storage node, of the data access request ([0054] In this regard, each application server 100 is configurable or operable to perform various DB functions (e.g., indexing, querying, etc.) […] In some such implementations, an interface system implementing a load balancing function (e.g., an F5 Big-IP load balancer) is communicably coupled between the application servers 100 and the user systems 12 to distribute requests to the application servers 100. In one implementation, the load balancer uses a least-connections algorithm to route user requests to the app servers 100. Please note that the load balancer coupled between the app servers 100 and the user systems 12 to route user requests to the app servers 100 to perform DB functions such as querying corresponds to Applicant’s router application transmitting the data access request to the data storage node, as it routes the request to be fulfilled with the specifically requested data on behalf of the service application of the app servers 100.).
Regarding Claim 9, Brossard-Rudraraju as described in Claim 8, Brossard further discloses wherein the at least one data storage node infers the service is authorized to make the data access request for the service data based on the determination of the router application, and the at least one data storage node fulfills the data access request for the service without performing a second service authorization ([0026] The cloud computing storage platform 104 also comprises […] a web proxy 120 […] The web proxy 120 handles tasks involved in accepting and processing concurrent API calls, including […] authorization and access control. Please note that the web proxy 120 accepting and then processing API calls including authorization corresponds to Applicant’s data storage node inferring the service is authorized to make the data access request for the service data based on the determination of the router application, and the data storage node fulfilling the data access request for the service without performing a second service authorization. This is because the authorization task being handled by the web proxy 120 corresponds to the data storage node inferring the service is authorized to make the request, and since it proceeds to process the call, this corresponds to fulfilling the request without performing a second service authorization, as it only performs the authorization initially.).
Regarding Claim 10, Brossard discloses One or more non-transitory computer readable storage media having instructions stored thereupon ([0076] The various memories […]may store one or more sets of instructions 916. Please note the memories storing instructions 916 corresponds to Applicant’s non-transitory computer readable storage media having instructions stored thereupon.) which, when executed by a system having at least a processor and a memory therein ([0072] The machine 900 includes processors 910, memory 930), cause the system to perform operations ([0070] a computer system within which a set of instructions may be executed for causing the machine 900 to perform any one or more of the methodologies discussed herein. Please note that the instructions causing the machine 900 to perform discussed methodologies corresponds to Applicant’s causing the system to perform operations.) for executing data access requests in a distributed storage system ([0024] Execution platform 114 is coupled to multiple data storage devices 124-1 to 124-n that are part of a cloud computing storage platform 104 […] cloud computing storage platform 104 may include distributed file systems. Please note that an execution platform 114 coupled to multiple data storage devices 124-1 to 124-n that are part of a cloud computing storage platform 104, where 104 includes distributed file systems, corresponds to Applicant’s executing data access requests in a distributed storage system.), comprising:
initiating, by a service application executing on a first computing node, the first computing node corresponding to a single service node, a data access request to manage service data using a plurality of distributed data storage nodes that store service data for the service ([0025] The execution platform 114 comprises a plurality of compute nodes (e.g., virtual warehouses). A set of processes on a compute node executes a query plan compiled by the compute service manager 112.; [0032] a request processing service 202 manages received data storage requests and data retrieval requests (e.g., jobs to be performed on database data). For example, the request processing service 202 may determine the data necessary to process a received query (e.g., a data storage request or data retrieval request). The data may be stored in a cache within the execution platform 114 or in a data storage device in cloud computing storage platform 104. Please note that a compute node of the execution platform 114 coupled with the request processing service 202 of the compute service manager 112 to initiate data retrieval requests to be performed on data stored in the distributed storage of the cloud computing storage platform corresponds to Applicant’s initiating a data access request to manage service data using a plurality of distributed data storage nodes that store service data for the service, as the request processing service 202 corresponds to the service application executing on a first computing node corresponding to a single service node, i.e., one of the plurality, and the distributed storage of the cloud computing platform 104 corresponds to Applicant’s plurality of distributed data storage nodes that store service data for the service.);
communicating, by the service application to a router application executing on the first computing node, the data access request ([0051] The foreground GS 400 may receive query requests and develop query plans to execute the query requests. The foreground GS 400 may broker requests to nodes 410.1-410.N that execute a query plan, as explained in further detail herein. Please note that the foreground GS 400 brokering query requests to nodes 410.1-410.N to execute the query plan corresponds to Applicant’s router application executing on the first computing node that has the data access communicated to it by the service application, as the previously disclosed request processing service 202 manages the received data retrieval requests, which are then brokered by the foreground GS 400.);
determining, by the router application, at least one data storage node from the plurality of distributed data storage nodes that can satisfy the data access request ([0025] A set of processes on a compute node executes a query plan compiled by the compute service manager 112.; [0030] compute service manager 112 may determine what data is needed to process a task and further determine which nodes within the execution platform 114 are best suited to process the task. Please note that the determining what data is needed to process a task corresponds to determining at least one data storage node from the plurality of distributed data storage nodes that can satisfy the data access request, as it would select a data storage node from the previously disclosed distributed storage of cloud computing platform 104 that contains the data needed to satisfy the request. Furthermore, since the foreground GS 400 develops query plans to execute the query requests, which can also be compiled by the compute service manager 112, this corresponds to doing so by the router application, as it would accomplish the same outcome.);
Brossard does not explicitly disclose wherein the service application is executed within a service pod at the first computing node, the router application is executed within a router pod at the first computing node, and the data access request is communicated locally between the service pod and the router pod at the first computing node;
and transmitting, by the router application to the at least one data storage node, the data access request for fulfillment of the data access request on behalf of the service application.
However, Rudraraju discloses wherein the service application is executed within a service pod at the first computing node, the router application is executed within a router pod at the first computing node, and the data access request is communicated locally between the service pod and the router pod at the first computing node ([0049] one or more APIs 32 (also referred to as a “web service”) to system 16 resident processes, which allow users or developers at user systems 12 to access the resident processes. The API(s) 32 is/are interface(s) for software components to communicate with each other.; [0052] Private APIs are APIs 32 that are private or internal to the system 16, which allows system applications (e.g., tenant management process 110, system process 102, query engine(s) 103, crypto processor(s) 105, and validation processor(s) 105 to access other system applications. […] use of the private APIs 32 may be restricted to machines inside a private network (or an enterprise network); [0065] A pod is the basic execution unit of a Kubernetes application, and is the smallest and simplest unit in the Kubernetes object model that can be created and deployed. A pod represents a unit of deployment, which is a single instance of an application in Kubernetes. A pod may include a single container or a small number of containers that are tightly coupled and that share resources. Additionally or alternatively, a pod represents one or more processes running on a cluster. A “cluster” refers to a set of worker machines or nodes (e.g., one or more physical and/or virtual machines) that run containerized applications. Each cluster has at least one worker node. Please note that each pod representing an instance of an application corresponds to Applicant’s service and router applications being executed within respective pods, running in a cluster on a node corresponds to executing at the first computing node, and software components using APIs 32 to communicate with each other corresponds to the data access request being communicated locally between the service and router pods at the first computing node, as, since the two pods could be on the same cluster and use an API to communicate, this corresponds to communicating locally at the first computing node. Additionally, since APIs may be private APIs internal to the system 16 for system applications to access other system applications, the data access requests are being communicated locally, i.e., internally to one system.).
and transmitting, by the router application to the at least one data storage node, the data access request for fulfillment of the data access request on behalf of the service application ([0054] In this regard, each application server 100 is configurable or operable to perform various DB functions (e.g., indexing, querying, etc.) […] In some such implementations, an interface system implementing a load balancing function (e.g., an F5 Big-IP load balancer) is communicably coupled between the application servers 100 and the user systems 12 to distribute requests to the application servers 100. In one implementation, the load balancer uses a least-connections algorithm to route user requests to the app servers 100. Please note that the load balancer coupled between the app servers 100 and the user systems 12 to route user requests to the app servers 100 to perform DB functions such as querying corresponds to Applicant’s router application transmitting the data access request for fulfillment of the data access request on behalf of the service application to the data storage node, as it routes the request to be fulfilled with the specifically requested data on behalf of the service application of the app servers 100.).
Brossard and Rudraraju are both considered to be analogous to the claimed invention because they are in the same field of computer request processing. Therefore, it would have been obvious to someone of ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Brossard to incorporate the teachings of Rudraraju to modify the system with a service application executing on a first computing node that initiates a data access request and communicates it to a router application that determines a data storage node that can satisfy it to transmit the data access request for fulfillment of the data access request on behalf of the service application and have the service and router applications executed within respective service and router pods at the first computing node, with the data access request communicated locally between them, allowing for improved efficiency of request processing and system security, as described in Rudraraju.
Regarding Claim 12, Brossard-Rudraraju as described in Claim 10, Brossard further discloses wherein the at least one data storage node is remote to the first computing node, and the data access request is transmitted from the router pod to the at least one data storage node over a communications network ([0018] The 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). Please note that the network-based data warehouse system 102 that is used to access external remotely located data corresponds to Applicant’s data storage node being remote to the first computing node and the data access request is transmitted from the router pod to the at least one data storage node over a communications network, as it uses a network-based system to access the remotely located data to fulfill the previously disclosed data access requests.).
Regarding Claim 13, Brossard-Rudraraju as described in Claim 10, Rudraraju further discloses wherein the at least one data storage node is the first computing node ([0042] . Each application server 100 (also referred to herein as an “app server”, an “API server”, an “HTTP application server,” a “worker node”, and/or the like) is configurable or operable to communicate with tenant DB 22 and the tenant data 23 therein, as well as system DB 24 and the system data 25 therein, to serve requests received from the user systems 12. Please note that the application server 100, that can be a worker node, configurable to communicate with tenant data 23 and system data 25 corresponds to Applicant’s data storage node being the first computing node, as the node can serve requests for the data that is stored.),
and the data access request is transmitted locally from the router pod to a pod comprising the at least one data storage node ([0065] A pod may include a single container or a small number of containers that are tightly coupled and that share resources. Additionally or alternatively, a pod represents one or more processes running on a cluster. A “cluster” refers to a set of worker machines or nodes (e.g., one or more physical and/or virtual machines) that run containerized applications. Each cluster has at least one worker node. A pod encapsulates an application's container (or multiple containers), storage resources, a unique network identity (e.g., IP address or the like). Please note that pods running in a cluster that each have their own processes, where each pod has a unique network identity, corresponds to Applicant’s data access request being transmitted locally from the router pod to a pod comprising the at least one data storage node, since it is known in the art that distinct network identities of pods on a cluster would allow for their applications to transmit information locally to each other, including the previously disclosed data access request.).
Regarding Claim 14, Brossard-Rudraraju as described in Claim 10, Brossard further discloses determining, by an authorizer application executed within the router pod at the first computing node, whether the service is authorized to issue the data access request ([0026] The cloud computing storage platform 104 also comprises […] a web proxy 120 […] The web proxy 120 handles tasks involved in accepting and processing concurrent API calls, including […] authorization and access control. Please note that the web proxy 120 that handles tasks involved in accepting and processing API calls including authorization corresponds to Applicant’s authorizer application executed within the router pod at the first computing node that determines whether the service is authorized to issue the data access request, as it decides whether the service issuing the API call is authorized to do so.);
in response to the determining that the service is authorized, determining, by the router application, the at least one data storage node from among the plurality of distributed data storage nodes using a deterministic selection process based on the key ([0030] compute service manager 112 may determine what data is needed to process a task and further determine which nodes within the execution platform 114 are best suited to process the task […]Metadata stored in the database 116 assists the compute service manager 112 in determining which nodes in the execution platform 114 have already cached at least a portion of the data needed to process the task.; [0035] 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. Please note that using metadata to assist the compute service manager 112 in determining which nodes in the execution platform 114 have cached the data needed to process the task, and the configuration and metadata manager 216 using the metadata to determine which data micro-partitions need to be access to retrieve data for processing a particular task corresponds to Applicant’s determining the at least one data storage node from among the plurality of distributed data storage nodes using a deterministic selection process based on the key, as a request seeking a specific piece of data would deterministically be routed to the micro-partition that contains that particular data. Furthermore, since it does so based on metadata, it is known in the art that requests, such as API requests, often include keys; therefore, this could be used in the process to determine the data storage node.);
Rudraraju further discloses based on a key corresponding to service data that is a subject of the data access request ([0031] In some embodiments, the user system 12 may include Trusted Compute resources that preserve data confidentiality, execution integrity and enforces data access policies. The Trusted Compute resources may be used to store cryptographic keys, digital certificates, credentials, and/or other sensitive information, and could be used to operate some aspects of an app 12y […] an app 12y is capable of interfacing with the Trusted Compute resources using a suitable API 32. Please note that since the user system 12 includes Trusted Compute resources to enforce data access policies such as cryptographic keys corresponds to Applicant’s key that is the subject of the data access request, as these keys are used to enforce data access policies, and therefore the keys for particular data that are a subject of requests would be checked.)
and initiating transmission, by the router application to the at least one data storage node, of the data access request ([0054] In this regard, each application server 100 is configurable or operable to perform various DB functions (e.g., indexing, querying, etc.) […] In some such implementations, an interface system implementing a load balancing function (e.g., an F5 Big-IP load balancer) is communicably coupled between the application servers 100 and the user systems 12 to distribute requests to the application servers 100. In one implementation, the load balancer uses a least-connections algorithm to route user requests to the app servers 100. Please note that the load balancer coupled between the app servers 100 and the user systems 12 to route user requests to the app servers 100 to perform DB functions such as querying corresponds to Applicant’s router application transmitting the data access request to the data storage node, as it routes the request to be fulfilled with the specifically requested data on behalf of the service application of the app servers 100.).
Regarding Claim 15, Brossard-Rudraraju as described in Claim 14, Brossard further discloses wherein the at least one data storage node infers the service is authorized to make the data access request for the service data based on the determination of the router application, and the at least one data storage node fulfills the data access request for the service without performing a second service authorization ([0026] The cloud computing storage platform 104 also comprises […] a web proxy 120 […] The web proxy 120 handles tasks involved in accepting and processing concurrent API calls, including […] authorization and access control. Please note that the web proxy 120 accepting and then processing API calls including authorization corresponds to Applicant’s data storage node inferring the service is authorized to make the data access request for the service data based on the determination of the router application, and the data storage node fulfilling the data access request for the service without performing a second service authorization. This is because the authorization task being handled by the web proxy 120 corresponds to the data storage node inferring the service is authorized to make the request, and since it proceeds to process the call, this corresponds to fulfilling the request without performing a second service authorization, as it only performs the authorization initially.).
Regarding Claim 16, Brossard discloses A first computer node for executing data access requests in a distributed storage system ([0024] Execution platform 114 is coupled to multiple data storage devices 124-1 to 124-n that are part of a cloud computing storage platform 104 […] cloud computing storage platform 104 may include distributed file systems.; 0025] The execution platform 114 comprises a plurality of compute nodes Please note that an execution platform 114 coupled to multiple data storage devices 124-1 to 124-n that are part of a cloud computing storage platform 104, where 104 includes distributed file systems, corresponds to Applicant’s executing data access requests in a distributed storage system with a first computing node, as the execution platform 114 comprises nodes.), comprising: a memory having instructions stored thereupon ([0076] The various memories […]may store one or more sets of instructions 916. Please note the memories storing instructions 916 corresponds to Applicant’s memory having instructions stored thereupon.); and one or more processors coupled with the memory, configured to execute the instructions, causing the one or more processors to perform operations ([0072] The machine 900 includes processors 910, memory 930; [0070] a computer system within which a set of instructions may be executed for causing the machine 900 to perform any one or more of the methodologies discussed herein. Please note that the instructions causing the machine 900 to perform discussed methodologies, in a system with processors 910 and memory 930, corresponds to Applicant’s processor coupled with the memory and being configured to cause the processor to perform operations.), comprising:
initiating, by a service application executing on the first computing node, the first computing node corresponding to a single service node, a data access request to manage service data using a plurality of distributed data storage nodes that store service data for the service ([0025] The execution platform 114 comprises a plurality of compute nodes (e.g., virtual warehouses). A set of processes on a compute node executes a query plan compiled by the compute service manager 112.; [0032] a request processing service 202 manages received data storage requests and data retrieval requests (e.g., jobs to be performed on database data). For example, the request processing service 202 may determine the data necessary to process a received query (e.g., a data storage request or data retrieval request). The data may be stored in a cache within the execution platform 114 or in a data storage device in cloud computing storage platform 104. Please note that a compute node of the execution platform 114 coupled with the request processing service 202 of the compute service manager 112 to initiate data retrieval requests to be performed on data stored in the distributed storage of the cloud computing storage platform corresponds to Applicant’s initiating a data access request to manage service data using a plurality of distributed data storage nodes that store service data for the service, as the request processing service 202 corresponds to the service application executing on a first computing node corresponding to a single service node, i.e., one of the plurality, and the distributed storage of the cloud computing platform 104 corresponds to Applicant’s plurality of distributed data storage nodes that store service data for the service.);
communicating, by the service application to a router application executing on the first computing node, the data access request ([0051] The foreground GS 400 may receive query requests and develop query plans to execute the query requests. The foreground GS 400 may broker requests to nodes 410.1-410.N that execute a query plan, as explained in further detail herein. Please note that the foreground GS 400 brokering query requests to nodes 410.1-410.N to execute the query plan corresponds to Applicant’s router application executing on the first computing node that has the data access communicated to it by the service application, as the previously disclosed request processing service 202 manages the received data retrieval requests, which are then brokered by the foreground GS 400.);
determining, by the router application, at least one data storage node from the plurality of distributed data storage nodes that can satisfy the data access request ([0025] A set of processes on a compute node executes a query plan compiled by the compute service manager 112.; [0030] compute service manager 112 may determine what data is needed to process a task and further determine which nodes within the execution platform 114 are best suited to process the task. Please note that the determining what data is needed to process a task corresponds to determining at least one data storage node from the plurality of distributed data storage nodes that can satisfy the data access request, as it would select a data storage node from the previously disclosed distributed storage of cloud computing platform 104 that contains the data needed to satisfy the request. Furthermore, since the foreground GS 400 develops query plans to execute the query requests, which can also be compiled by the compute service manager 112, this corresponds to doing so by the router application, as it would accomplish the same outcome.);
Brossard does not explicitly disclose wherein the service application is executed within a service pod at the first computing node, the router application is executed within a router pod at the first computing node, and the data access request is communicated locally between the service pod and the router pod at the first computing node;
and transmitting, by the router application to the at least one data storage node, the data access request for fulfillment of the data access request on behalf of the service application.
However, Rudraraju discloses wherein the service application is executed within a service pod at the first computing node, the router application is executed within a router pod at the first computing node, and the data access request is communicated locally between the service pod and the router pod at the first computing node ([0049] one or more APIs 32 (also referred to as a “web service”) to system 16 resident processes, which allow users or developers at user systems 12 to access the resident processes. The API(s) 32 is/are interface(s) for software components to communicate with each other.; [0052] Private APIs are APIs 32 that are private or internal to the system 16, which allows system applications (e.g., tenant management process 110, system process 102, query engine(s) 103, crypto processor(s) 105, and validation processor(s) 105 to access other system applications. […] use of the private APIs 32 may be restricted to machines inside a private network (or an enterprise network); [0065] A pod is the basic execution unit of a Kubernetes application, and is the smallest and simplest unit in the Kubernetes object model that can be created and deployed. A pod represents a unit of deployment, which is a single instance of an application in Kubernetes. A pod may include a single container or a small number of containers that are tightly coupled and that share resources. Additionally or alternatively, a pod represents one or more processes running on a cluster. A “cluster” refers to a set of worker machines or nodes (e.g., one or more physical and/or virtual machines) that run containerized applications. Each cluster has at least one worker node. Please note that each pod representing an instance of an application corresponds to Applicant’s service and router applications being executed within respective pods, running in a cluster on a node corresponds to executing at the first computing node, and software components using APIs 32 to communicate with each other corresponds to the data access request being communicated locally between the service and router pods at the first computing node, as, since the two pods could be on the same cluster and use an API to communicate, this corresponds to communicating locally at the first computing node. Additionally, since APIs may be private APIs internal to the system 16 for system applications to access other system applications, the data access requests are being communicated locally, i.e., internally to one system.).
and transmitting, by the router application to the at least one data storage node, the data access request for fulfillment of the data access request on behalf of the service application ([0054] In this regard, each application server 100 is configurable or operable to perform various DB functions (e.g., indexing, querying, etc.) […] In some such implementations, an interface system implementing a load balancing function (e.g., an F5 Big-IP load balancer) is communicably coupled between the application servers 100 and the user systems 12 to distribute requests to the application servers 100. In one implementation, the load balancer uses a least-connections algorithm to route user requests to the app servers 100. Please note that the load balancer coupled between the app servers 100 and the user systems 12 to route user requests to the app servers 100 to perform DB functions such as querying corresponds to Applicant’s router application transmitting the data access request for fulfillment of the data access request on behalf of the service application to the data storage node, as it routes the request to be fulfilled with the specifically requested data on behalf of the service application of the app servers 100.).
Brossard and Rudraraju are both considered to be analogous to the claimed invention because they are in the same field of computer request processing. Therefore, it would have been obvious to someone of ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Brossard to incorporate the teachings of Rudraraju to modify the system with a service application executing on a first computing node that initiates a data access request and communicates it to a router application that determines a data storage node that can satisfy it to transmit the data access request for fulfillment of the data access request on behalf of the service application and have the service and router applications executed within respective service and router pods at the first computing node, with the data access request communicated locally between them, allowing for improved efficiency of request processing and system security, as described in Rudraraju.
Regarding Claim 18, Brossard-Rudraraju as described in Claim 16, Brossard further discloses wherein the at least one data storage node is remote to the first computing node, and the data access request is transmitted from the router pod to the at least one data storage node over a communications network ([0018] The 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). Please note that the network-based data warehouse system 102 that is used to access external remotely located data corresponds to Applicant’s data storage node being remote to the first computing node and the data access request is transmitted from the router pod to the at least one data storage node over a communications network, as it uses a network-based system to access the remotely located data to fulfill the previously disclosed data access requests.).
Regarding Claim 19, Brossard-Rudraraju as described in Claim 16, Rudraraju further discloses wherein the at least one data storage node is the first computing node ([0042] . Each application server 100 (also referred to herein as an “app server”, an “API server”, an “HTTP application server,” a “worker node”, and/or the like) is configurable or operable to communicate with tenant DB 22 and the tenant data 23 therein, as well as system DB 24 and the system data 25 therein, to serve requests received from the user systems 12. Please note that the application server 100, that can be a worker node, configurable to communicate with tenant data 23 and system data 25 corresponds to Applicant’s data storage node being the first computing node, as the node can serve requests for the data that is stored.),
and the data access request is transmitted locally from the router pod to a pod comprising the at least one data storage node ([0065] A pod may include a single container or a small number of containers that are tightly coupled and that share resources. Additionally or alternatively, a pod represents one or more processes running on a cluster. A “cluster” refers to a set of worker machines or nodes (e.g., one or more physical and/or virtual machines) that run containerized applications. Each cluster has at least one worker node. A pod encapsulates an application's container (or multiple containers), storage resources, a unique network identity (e.g., IP address or the like). Please note that pods running in a cluster that each have their own processes, where each pod has a unique network identity, corresponds to Applicant’s data access request being transmitted locally from the router pod to a pod comprising the at least one data storage node, since it is known in the art that distinct network identities of pods on a cluster would allow for their applications to transmit information locally to each other, including the previously disclosed data access request.).
Regarding Claim 20, Brossard-Rudraraju as described in Claim 14, Brossard further discloses determining, by an authorizer application executed within the router pod at the first computing node, whether the service is authorized to issue the data access request ([0026] The cloud computing storage platform 104 also comprises […] a web proxy 120 […] The web proxy 120 handles tasks involved in accepting and processing concurrent API calls, including […] authorization and access control. Please note that the web proxy 120 that handles tasks involved in accepting and processing API calls including authorization corresponds to Applicant’s authorizer application executed within the router pod at the first computing node that determines whether the service is authorized to issue the data access request, as it decides whether the service issuing the API call is authorized to do so.);
in response to the determining that the service is authorized, determining, by the router application, the at least one data storage node from among the plurality of distributed data storage nodes using a deterministic selection process based on the key ([0030] compute service manager 112 may determine what data is needed to process a task and further determine which nodes within the execution platform 114 are best suited to process the task […]Metadata stored in the database 116 assists the compute service manager 112 in determining which nodes in the execution platform 114 have already cached at least a portion of the data needed to process the task.; [0035] 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. Please note that using metadata to assist the compute service manager 112 in determining which nodes in the execution platform 114 have cached the data needed to process the task, and the configuration and metadata manager 216 using the metadata to determine which data micro-partitions need to be access to retrieve data for processing a particular task corresponds to Applicant’s determining the at least one data storage node from among the plurality of distributed data storage nodes using a deterministic selection process based on the key, as a request seeking a specific piece of data would deterministically be routed to the micro-partition that contains that particular data. Furthermore, since it does so based on metadata, it is known in the art that requests, such as API requests, often include keys; therefore, this could be used in the process to determine the data storage node.);
Rudraraju further discloses based on a key corresponding to service data that is a subject of the data access request ([0031] In some embodiments, the user system 12 may include Trusted Compute resources that preserve data confidentiality, execution integrity and enforces data access policies. The Trusted Compute resources may be used to store cryptographic keys, digital certificates, credentials, and/or other sensitive information, and could be used to operate some aspects of an app 12y […] an app 12y is capable of interfacing with the Trusted Compute resources using a suitable API 32. Please note that since the user system 12 includes Trusted Compute resources to enforce data access policies such as cryptographic keys corresponds to Applicant’s key that is the subject of the data access request, as these keys are used to enforce data access policies, and therefore the keys for particular data that are a subject of requests would be checked.)
and initiating transmission, by the router application to the at least one data storage node, of the data access request ([0054] In this regard, each application server 100 is configurable or operable to perform various DB functions (e.g., indexing, querying, etc.) […] In some such implementations, an interface system implementing a load balancing function (e.g., an F5 Big-IP load balancer) is communicably coupled between the application servers 100 and the user systems 12 to distribute requests to the application servers 100. In one implementation, the load balancer uses a least-connections algorithm to route user requests to the app servers 100. Please note that the load balancer coupled between the app servers 100 and the user systems 12 to route user requests to the app servers 100 to perform DB functions such as querying corresponds to Applicant’s router application transmitting the data access request to the data storage node, as it routes the request to be fulfilled with the specifically requested data on behalf of the service application of the app servers 100.).
Regarding Claim 21, Brossard-Rudraraju as described in Claim 1, Rudraraju further discloses wherein the locally communicated data access request is performed without network-based messaging ([0049] one or more APIs 32 (also referred to as a “web service”) to system 16 resident processes, which allow users or developers at user systems 12 to access the resident processes. The API(s) 32 is/are interface(s) for software components to communicate with each other.; [0052] Private APIs are APIs 32 that are private or internal to the system 16, which allows system applications (e.g., tenant management process 110, system process 102, query engine(s) 103, crypto processor(s) 105, and validation processor(s) 105 to access other system applications. […] use of the private APIs 32 may be restricted to machines inside a private network (or an enterprise network); [0065] A pod is the basic execution unit of a Kubernetes application, and is the smallest and simplest unit in the Kubernetes object model that can be created and deployed. A pod represents a unit of deployment, which is a single instance of an application in Kubernetes. A pod may include a single container or a small number of containers that are tightly coupled and that share resources. Additionally or alternatively, a pod represents one or more processes running on a cluster. A “cluster” refers to a set of worker machines or nodes (e.g., one or more physical and/or virtual machines.). Since Applicant states in [0052] of the Specification that “the communication between blocks 504 and 506 involves communication between local hosts of the same node (e.g., the first node). The communication between the router application and the data node, however, is a network-based communication,” this implies that a communication between local hosts of the same node is an instance of a locally communicated data access request being performed without network-based messaging. Therefore, in an instance in which both pods, tightly coupled, sharing resources, running on one node of a cluster that may be one physical machine, communicate via a private API corresponds to Applicant’s locally communicated data access request being performed without network-based messaging.)
Regarding Claim 22, Brossard-Rudraraju as described in Claim 21, Rudraraju further discloses wherein the locally communicated data access request comprises an inter-process communication within a single host device ([0049] one or more APIs 32 (also referred to as a “web service”) to system 16 resident processes, which allow users or developers at user systems 12 to access the resident processes. The API(s) 32 is/are interface(s) for software components to communicate with each other.; [0052] Private APIs are APIs 32 that are private or internal to the system 16, which allows system applications (e.g., tenant management process 110, system process 102, query engine(s) 103, crypto processor(s) 105, and validation processor(s) 105 to access other system applications. […] use of the private APIs 32 may be restricted to machines inside a private network (or an enterprise network); [0065] A pod is the basic execution unit of a Kubernetes application, and is the smallest and simplest unit in the Kubernetes object model that can be created and deployed. A pod represents a unit of deployment, which is a single instance of an application in Kubernetes. A pod may include a single container or a small number of containers that are tightly coupled and that share resources. Additionally or alternatively, a pod represents one or more processes running on a cluster. A “cluster” refers to a set of worker machines or nodes (e.g., one or more physical and/or virtual machines.) Please note that since the pods each running a process may be on one physical machine for a node of a cluster, using internal private APIs for the software components to communicate, this corresponds to the locally communicated data access request comprising an inter-process communication within a single host device.)
Regarding Claim 23, Brossard-Rudraraju as described in Claim 10, Rudraraju further discloses wherein the locally communicated data access request is performed without network-based messaging ([0049] one or more APIs 32 (also referred to as a “web service”) to system 16 resident processes, which allow users or developers at user systems 12 to access the resident processes. The API(s) 32 is/are interface(s) for software components to communicate with each other.; [0052] Private APIs are APIs 32 that are private or internal to the system 16, which allows system applications (e.g., tenant management process 110, system process 102, query engine(s) 103, crypto processor(s) 105, and validation processor(s) 105 to access other system applications. […] use of the private APIs 32 may be restricted to machines inside a private network (or an enterprise network); [0065] A pod is the basic execution unit of a Kubernetes application, and is the smallest and simplest unit in the Kubernetes object model that can be created and deployed. A pod represents a unit of deployment, which is a single instance of an application in Kubernetes. A pod may include a single container or a small number of containers that are tightly coupled and that share resources. Additionally or alternatively, a pod represents one or more processes running on a cluster. A “cluster” refers to a set of worker machines or nodes (e.g., one or more physical and/or virtual machines.) Since Applicant states in [0052] of the Specification that “the communication between blocks 504 and 506 involves communication between local hosts of the same node (e.g., the first node). The communication between the router application and the data node, however, is a network-based communication,” this implies that a communication between local hosts of the same node is an instance of a locally communicated data access request being performed without network-based messaging. Therefore, in an instance in which both pods, tightly coupled, sharing resources, running on one node of a cluster that may be one physical machine, communicate via a private API corresponds to Applicant’s locally communicated data access request being performed without network-based messaging.)
Response to Arguments
Applicant's arguments filed 02/04/2026 have been fully considered but they are not persuasive.
Applicant’s arguments are summarized as follows:
Regarding the rejection of amended independent Claim 1, incorporating the limitations of Claim 2, Rudraraju does not teach that “the service application is executed within a service pod at the first computing node, the router application is executed within a router pod at the first computing node, and the data access request is communicated locally between the service pod and the router pod at the first computing node.” This is because though the Examiner states that the two pods could be on the same cluster and use an API to communicate, corresponding to communicating locally at the first computing node, this cannot be seen as suggesting the claimed features that the service and router pod are on the same service node (the first computing node) where the data access request is communicated locally between them. Brossard was cited for other reasons, and fails to cure this deficiency. Therefore, Claim 1 is allowable, and the rejection under 35 U.S.C. 103 should be withdrawn.
Regarding Claims 8, 14, and 20, Rudraraju is cited as teaching the limitations. However, regarding the “deterministic selection process,” it is not clear that Rudraraju’s “using metadata to determine which data micro-partitions need to be accessed” is a deterministic process, i.e., will always return the same data micro-partitions. Additionally, it is not clear that “using metadata to determine which data micro-partitions need to be accessed” is based on the key “corresponding to service data that is a subject of the data request,” since there is no basis for interpreting metadata as a “key.” Thirdly, the Office Action previously asserts the “key” as a cryptographic key, which is contextually incompatible with the later assertion of the key as “metadata to determine which data micro-partitions need to be accessed.” Brossard was cited for other reasons and fails to cure these deficiencies.
Regarding independent Claims 10 and 16, for similar reasons as described for Claim 1, they are allowable, and the rejections under 35 U.S.C. 103 should be withdrawn.
Regarding the dependent Claims, since they depend on allowable Claims and additionally define aspects of the invention, they are allowable, and the rejections under 35 U.S.C. 103 should be withdrawn.
Regarding A, the examiner respectfully disagrees. The API recited by Rudraraju in [0049] is provided “to system 16 resident processes, which allow users or developers at user systems 12 to access the resident processes,” and since APIs may be private APIs internal to the system 16 for system applications to access other system applications, the data access requests are being communicated locally, i.e., internally to one system. It additionally recites “A pod represents a unit of deployment, which is a single instance of an application in Kubernetes. A pod may include a single container or a small number of containers that are tightly coupled and that share resources. Additionally or alternatively, a pod represents one or more processes running on a cluster. A “cluster” refers to a set of worker machines or nodes (e.g., one or more physical and/or virtual machines).” Since the pods may be on one physical machine for a node of a cluster, using internal private APIs to communicate, this corresponds to communicating locally.
Therefore, the recited features can be found in the cited combination of references, and independent Claims 1 remains rejected under 35 U.S.C. 103 for the reasons stated above, and the combinations cited would have been obvious to a person of ordinary skill in the art prior to the effective filing date of the application. The rejections under 35 U.S.C. 103 are maintained.
Regarding B, the examiner respectfully disagrees.
It should be noted that the citation regarding the configuration and metadata manager 216 using the metadata to determine which data micro-partitions need to be accessed is from Brossard, not Rudraraju. [0043] of Brossard recites “the job optimizer 208 assigns input file sets to the nodes using a consistent hashing scheme to hash over table file names of the data accessed (e.g., data in database 116 or database 122). Subsequent or concurrent queries accessing the same table file will therefore be performed on the same node”, while [0036] of the Specification recites “a deterministic data distribution technique, such as the jump hash technique, is able to repeatedly calculate, based on the received key and total number of nodes for a service/end user, which node in the ordered listing data to be accessed is stored at.” Therefore, Brossard recites a hashing scheme for subsequent or concurrent queries accessing the same table file, analogous to the deterministic data distribution technique that is a jump hash technique for repeatedly calculating which node to be accessed. Thus, Brossard would be able to use this as a mechanism when using the metadata to determine which data micro-partitions need to be accessed to retrieve data for processing a particular task, corresponding to Applicant’s determining the at least one data storage node from among the plurality of distributed data storage nodes using a deterministic selection process based on the key, as a request seeking a specific piece of data would deterministically be routed to the micro-partition that contains that particular data by utilizing the hashing scheme for subsequent/concurrent queries to route the requests.
As stated above, the metadata analogous to the key in Brossard routes requests based on metadata, and it is known in the art that requests, such as API requests, often include keys; therefore, this could be used in the process to determine the data storage node, and in Rudraraju, the cryptographic keys are used to enforce data access policies, and therefore the keys for particular data that are a subject of requests would be checked. In other words, the cryptographic key and the metadata are both used as identifiers for data access and request routing, analogous to Applicant’s key that determines authorization and node selection for requests.
Therefore, the recited features can be found in the cited combination of references, and Claims 8, 14, and 20 remain rejected under 35 U.S.C. 103 for the reasons stated above, and the combinations cited would have been obvious to a person of ordinary skill in the art prior to the effective filing date of the application. Additionally, contrary to Applicant’s arguments, because the Claims 8, 14, and 20 depend on unpatentable claims and do not add limitations that overcome the rejection, they likewise remain rejected for that reason. The rejections under 35 U.S.C. 103 are maintained.
Regarding D, the examiner respectfully disagrees. Contrary to Applicant’s arguments, because the independent Claims 10 and 16 contain similar limitations to rejected Claim 1 and do not add limitations that overcome the rejection, they likewise remain rejected. The rejections under 35 U.S.C. 103 are maintained.
Regarding D, the examiner respectfully disagrees. Contrary to Applicant’s arguments, because the dependent claims depend on unpatentable independent Claims 1, 10, and 18 and do not add limitations that overcome the rejection, they likewise remain rejected. The rejections under 35 U.S.C. 103 are maintained.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Kaul (US 20230127847 A1) discloses pods deployed together on the same node, sharing local storage and networking within pods, with the system receiving access requests to interact with object storage data (see [0027, 0050]).
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 nonprovisional extension fee (37 CFR 1.17(a)) 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 mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FARAZ T AKBARI whose telephone number is (571)272-4166. The examiner can normally be reached Monday-Thursday 9:30am-7:30pm ET.
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, April Blair can be reached at (571)270-1014. 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.
/FARAZ T AKBARI/Examiner, Art Unit 2196
/APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196
Prosecution Insights