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 08/03/2026. Claims 2, 11, and 17 were previously cancelled. Claims 1, 10, 16, and 21-23 have been amended. 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.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 08/03/2026 has been entered.
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), and further in view of Sen et al. (US 20210075633 A1 ) hereinafter referred to as Brossard, Rudraraju, and Sen, 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.
Brossard-Rudraraju does not explicitly disclose the data access request is communicated in-memory within the first computing node between the service pod and the router pod
However, Sen discloses the data access request is communicated in-memory within the first computing node between the service pod and the router pod ([0091] DMA engine 1602 could inspect address information (e.g., a physical or virtual address, address space identifier, etc.) in the DMA data transfer request and use that information to determine where the source or destination data is located (e.g., in local memory 1608 […] DMA engine 1602 and/or network interface 1604 can be coupled to one or more of CPUs 1606 and local memory 1608 using a device interface (e.g., DDR, CXL, PCIe). In some examples, network interface 1604 can directly access local memory 1608 without intervention by CPUs 1606 to access data. ; [0097] in compute node 1600, DMA engine 1602 can determine whether the source address corresponds to an address in local memory 1608; [0106] a requester can access local buffers in local memory 1608 and not manage network connections, setup or shutdown. Please note that the DMA data transfer request containing information relating to the source/destination data being located in local memory 1608, where the DMA engine 1602 and network interface 1604 are coupled to local memory 1608 using a device interface, where requesters may access local buffers in local memory 1608 without managing network connections corresponds to Applicant’s data access request being communicated in-memory within the first computing node between the service pod and the router pod that were previously disclosed by Brossard-Rudraraju.)
Brossard-Rudraraju and Sen are both considered to be analogous to the claimed invention because they are in the same field of computer data access 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-Rudraraju to incorporate the teachings of Sen to modify the previously described system to have the data access request communicated in-memory within the first computing node between the service pod and the router pod, allowing for improved efficiency and speed of request processing along with less processing overhead for maintaining a connection, as described in Sen.
Regarding Claim 3, Brossard-Rudraraju-Sen 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-Sen 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-Sen 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 an 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-Sen 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-Sen 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-Sen 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-Sen 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.
Brossard-Rudraraju does not explicitly disclose the data access request is communicated in-memory within the first computing node between the service pod and the router pod
However, Sen discloses the data access request is communicated in-memory within the first computing node between the service pod and the router pod ([0091] DMA engine 1602 could inspect address information (e.g., a physical or virtual address, address space identifier, etc.) in the DMA data transfer request and use that information to determine where the source or destination data is located (e.g., in local memory 1608 […] DMA engine 1602 and/or network interface 1604 can be coupled to one or more of CPUs 1606 and local memory 1608 using a device interface (e.g., DDR, CXL, PCIe). In some examples, network interface 1604 can directly access local memory 1608 without intervention by CPUs 1606 to access data. ; [0097] in compute node 1600, DMA engine 1602 can determine whether the source address corresponds to an address in local memory 1608; [0106] a requester can access local buffers in local memory 1608 and not manage network connections, setup or shutdown. Please note that the DMA data transfer request containing information relating to the source/destination data being located in local memory 1608, where the DMA engine 1602 and network interface 1604 are coupled to local memory 1608 using a device interface, where requesters may access local buffers in local memory 1608 without managing network connections corresponds to Applicant’s data access request being communicated in-memory within the first computing node between the service pod and the router pod that were previously disclosed by Brossard-Rudraraju.)
Brossard-Rudraraju and Sen are both considered to be analogous to the claimed invention because they are in the same field of computer data access 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-Rudraraju to incorporate the teachings of Sen to modify the previously described system to have the data access request communicated in-memory within the first computing node between the service pod and the router pod, allowing for improved efficiency and speed of request processing along with less processing overhead for maintaining a connection, as described in Sen.
Regarding Claim 12, Brossard-Rudraraju-Sen 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-Sen 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-Sen 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-Sen 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 the 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.
Brossard-Rudraraju does not explicitly disclose the data access request is communicated in-memory within the first computing node between the service pod and the router pod
However, Sen discloses the data access request is communicated in-memory within the first computing node between the service pod and the router pod ([0091] DMA engine 1602 could inspect address information (e.g., a physical or virtual address, address space identifier, etc.) in the DMA data transfer request and use that information to determine where the source or destination data is located (e.g., in local memory 1608 […] DMA engine 1602 and/or network interface 1604 can be coupled to one or more of CPUs 1606 and local memory 1608 using a device interface (e.g., DDR, CXL, PCIe). In some examples, network interface 1604 can directly access local memory 1608 without intervention by CPUs 1606 to access data. ; [0097] in compute node 1600, DMA engine 1602 can determine whether the source address corresponds to an address in local memory 1608; [0106] a requester can access local buffers in local memory 1608 and not manage network connections, setup or shutdown. Please note that the DMA data transfer request containing information relating to the source/destination data being located in local memory 1608, where the DMA engine 1602 and network interface 1604 are coupled to local memory 1608 using a device interface, where requesters may access local buffers in local memory 1608 without managing network connections corresponds to Applicant’s data access request being communicated in-memory within the first computing node between the service pod and the router pod that were previously disclosed by Brossard-Rudraraju.)
Brossard-Rudraraju and Sen are both considered to be analogous to the claimed invention because they are in the same field of computer data access 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-Rudraraju to incorporate the teachings of Sen to modify the previously described system to have the data access request communicated in-memory within the first computing node between the service pod and the router pod, allowing for improved efficiency and speed of request processing along with less processing overhead for maintaining a connection, as described in Sen.
Regarding Claim 18, Brossard-Rudraraju-Sen 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-Sen 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-Sen 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-Sen as described in Claim 1, Sen further discloses wherein communicating the data access request in-memory between the service pod and the router pod is performed without network-based messaging ([0091] DMA engine 1602 could inspect address information (e.g., a physical or virtual address, address space identifier, etc.) in the DMA data transfer request and use that information to determine where the source or destination data is located (e.g., in local memory 1608 […] DMA engine 1602 and/or network interface 1604 can be coupled to one or more of CPUs 1606 and local memory 1608 using a device interface (e.g., DDR, CXL, PCIe). In some examples, network interface 1604 can directly access local memory 1608 without intervention by CPUs 1606 to access data. ; [0097] in compute node 1600, DMA engine 1602 can determine whether the source address corresponds to an address in local memory 1608; [0106] a requester can access local buffers in local memory 1608 and not manage network connections, setup or shutdown. Please note that the DMA data transfer request containing information relating to the source/destination data being located in local memory 1608, where requesters may access local buffers in local memory 1608 without managing network connections corresponds to Applicant’s communicating the data access request in-memory between the service pod and the router pod being performed without network-based messaging.)
Regarding Claim 22, Brossard-Rudraraju-Sen as described in Claim 21, Sen further discloses communicating the data access request in-memory ([0091] DMA engine 1602 could inspect address information (e.g., a physical or virtual address, address space identifier, etc.) in the DMA data transfer request and use that information to determine where the source or destination data is located (e.g., in local memory 1608 […] DMA engine 1602 and/or network interface 1604 can be coupled to one or more of CPUs 1606 and local memory 1608 using a device interface (e.g., DDR, CXL, PCIe). In some examples, network interface 1604 can directly access local memory 1608 without intervention by CPUs 1606 to access data. ; [0097] in compute node 1600, DMA engine 1602 can determine whether the source address corresponds to an address in local memory 1608; [0106] a requester can access local buffers in local memory 1608 and not manage network connections, setup or shutdown. Please note that the DMA data transfer request containing information relating to the source/destination data being located in local memory 1608, where the DMA engine 1602 and network interface 1604 are coupled to local memory 1608 using a device interface, where requesters may access local buffers in local memory 1608 without managing network connections corresponds to Applicant’s data access request being communicated in-memory.)
Rudraraju further discloses wherein communicating the 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 communicating the data access request comprising an inter-process communication within a single host device.)
Regarding Claim 23, Brossard-Rudraraju-Sen as described in Claim 10, Sen further discloses wherein communicating the data access request in-memory between the service pod and the router pod is performed without network-based messaging ([0091] DMA engine 1602 could inspect address information (e.g., a physical or virtual address, address space identifier, etc.) in the DMA data transfer request and use that information to determine where the source or destination data is located (e.g., in local memory 1608 […] DMA engine 1602 and/or network interface 1604 can be coupled to one or more of CPUs 1606 and local memory 1608 using a device interface (e.g., DDR, CXL, PCIe). In some examples, network interface 1604 can directly access local memory 1608 without intervention by CPUs 1606 to access data. ; [0097] in compute node 1600, DMA engine 1602 can determine whether the source address corresponds to an address in local memory 1608; [0106] a requester can access local buffers in local memory 1608 and not manage network connections, setup or shutdown. Please note that the DMA data transfer request containing information relating to the source/destination data being located in local memory 1608, where requesters may access local buffers in local memory 1608 without managing network connections corresponds to Applicant’s communicating the data access request in-memory between the service pod and the router pod being performed without network-based messaging.)
Response to Arguments
Applicant's arguments filed 08/03/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, Rudraraju does not teach that “the data access request is communicated in-memory within the first computing node between the service pod and router pod.” This is because though Rudraraju teaches API-based interfaces, but does not disclose this amended limitation. For example, Rudraraju discloses the system including APIs through which applications communicate with each other, and private APIs as interfaces that permit internal applications to communicate while restricting external access, but the private APIs do not establish how the communications are physically or logically communicate, and even if the two components may reside on the same machine, this does not inherently mean the requests are carried out in-memory within the first computing node. Brossard does not cure this deficiency, as it discloses assigning file sets to nodes using a consistent hashing scheme to hash over table file names such that subsequent queries are performed on the same node, and is directed towards workload assignment, cache usage, and node selection, but not the amended limitations. The Kaul reference, though not applied in the rejection, it also does not disclose this amended feature. Therefore, Claim 1 is allowable, and the rejection under 35 U.S.C. 103 should be withdrawn.
Regarding Claims 8, 14, and 20, the cited references do not teach determining the at least one data storage node “using a deterministic selection process based on the key.” The Office Action relies on Brossard’s consistent hashing of table file names, but Brossard does not teach using a particular key recited in claim 8 both as a key corresponding to the service data that is the subject of the request and as the basis for the claimed deterministic storage-node selection. Claim 8 requires “a key corresponding to service data that is a subject of the data access request” and requires the deterministic selection process to be “based on the key.” Brossard’s metadata-related disclosures and Rudraraju’s cryptographic-key disclosures do not meet these limitations. Brossard’s file names and associated metadata are used for workload distribution and cache management, and Rudraraju’s cryptographic keys are security artifacts. Therefore, the cited references do not teach the “key corresponding to service data” nor determining the data storage node using a deterministic selection process based on that key, and the rejections under 35 U.S.C. 103 should be withdrawn.
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 Applicant’s arguments are moot, as the rejections of the Claim now relies on a new grounds of rejection, Brossard-Rudraraju-Sen, which discloses the limitations stated by the Applicant via the combination of references, as stated above. 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. Firstly, the Applicant’s arguments are moot, as the rejections of the Claim now relies on a new grounds of rejection, Brossard-Rudraraju-Sen, which discloses the limitations stated by the Applicant via the combination of references, as stated above. Additionally, as described above, [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. In response to applicant's argument that since Rudraraju’s keys are security artifacts, and are thus not analogous to the key as claimed, a recitation of the intended use of the claimed invention must result in a structural difference between the claimed invention and the prior art in order to patentably distinguish the claimed invention from the prior art. If the prior art structure is capable of performing the intended use, then it meets the claim.
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]).
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