DETAILED ACTION
This communication is in response to the Applicant Arguments/Remarks filed 12/23/2025. Claims 1-20 are pending in the application.
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 . In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Response to Arguments
Applicant's arguments filed 12/23/2025 have been fully considered.
Regarding the arguments on page 10 that Jacobson does not disclose "receiving a data query request by a first data processing engine, wherein the first data processing engine comprises a front-end node and a back-end node, the front-end node receives the data query request, and the back-end node stores data", “Jacobson does not disclose that the selected engine in the execution environment stores data, as does the claimed back-end node”, examiner respectfully disagrees.
The argued limitation includes “a data processing engine” which is fundamentally a form of computer system or software driven computing resource.
A computer system or a data processing engine typically contains a front end that can receive data query requests and a backend that stores data, e.g., a smart phone/handheld computer that accepts input, processes data, and generates output.
Jacobson et al. teaches in para. 134: a computer 3702, computer memory 3706, a storage 3708; para. 66: reading and writing data to and from storage. Thus, said storage does store data that serves the reading/writing requests. The writing request can also be a data query request (since “query” is technically referred to any command sent to a database/storage to perform an action).
Regarding the arguments on page 11 that “Jacobson does not disclose that the execution environment stores data to be queried” and “Nowhere does Jacobson disclose that the "storage" to which the score composer stores the parallel or distributed execution plan is part of the execution environment. Also, Jacobson's parallel or distributed execution plan is not data to be queried. As such, Jacobson does not disclose the claimed back-end node that stores data to be queried”, examiner respectfully disagrees.
In response to applicant's argument that the references fail to show certain features of applicant’s invention, it is noted that the features upon which applicant relies (i.e., to which the score composer stores the parallel or distributed execution plan is part of the execution environment. Also, Jacobson's parallel or distributed execution plan is not data to be queried) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Jacobson et al. teaches in para. 131-134: a computer 3702, computer memory 3706, a storage 3708; para. 66: reading and writing data to and from storage. Thus, said storage does store data that serves the reading/writing requests. The writing request can also be a data query request (since “query” is technically referred to any command sent to a database/storage to perform an action).
Regarding the arguments on pages 12-13 that Jacobson does not disclose the selection step, “Jacobson does not disclose that the engine in the execution environment is selected from a data processing engine candidate set comprising the first data processing engine and a second data processing engine”, “the Office still has not cited any portion of Jacobson that discloses that the engine is selected from a data processing engine candidate set comprising the first data processing engine and a second data processing engine”, “Jacobson does not disclose "in response to the target data processing engine being the first data processing engine that received the data query request ... ”, examiner respectfully disagrees.
Jacobson et al. teaches in fig. 1: an engine manager associates with the engine selector, thus, the engine manager selects relating engine(s) among engines set/list that is/are appropriate to perform the requested task. The engine manager also associates with the execution manager for execution of tasks on the selected engines. See figs. 4-5: execution plan(s) is/are created based on the received request, and serialize/store execution plan to storage for execution. See also figs. 37-38: a computer 3702 with front end application 108 and storage 3708. A server 12 with front end I/O interface(s) 22 and memory includes storage system 34;
para. 52: select a data processing engine based on job characteristics and execution requirements. The data processing engine may be selected from a set of data processing engines of different types. Examples of different types of data processing engines include parallel processing engines and distributed computing engines. For example, a parallel processing engine may be a scalable data integration processing engine, while an example of a distributed computing engine is a scalable distributed computing engine for cloud computing environments, such as Hadoop™, available from Apache Software Foundation. The distributed computing engine may also include a MapReduce model, which provides an interface to facilitate meeting various data integration needs; para. 55-56: the data processing engine may be selected upon determining that the data processing engine best satisfies predefined criteria, such as one or more of speed, efficiency, resource consumption, job execution success rate, user-specified execution time constraints, etc.
Regarding the arguments on pages 15-17 that “Mattson does not disclose in response to the target data processing engine being the first data processing engine that received the data query request. Indeed, the Office does not even attempt to identify any portion of Mattson that discloses this feature of claim 1. Nor does the Office clearly identify which portion of Mattson is allegedly equivalent to the claimed "first data processing engine." By glossing over this distinct feature of claim 1, the Office fails to establish a prima facie case of obviousness”, examiner respectfully disagrees.
It is noted, REFERENCES ARE RELEVANT AS PRIOR ART FOR ALL THEY CONTAIN. "The use of patents as references is not limited to what the patentees describe as their own inventions or to the problems with which they are concerned. They are part of the literature of the art, relevant for all they contain." In re Heck, 699 F.2d 1331, 1332-33,216 USPQ 1038, 1039 (Fed. Cir. 1983) (quoting In re Lemelson, 397 F.2d 1006, 1009, 158 USPQ 275,277 (CCPA 1968)). A reference may be relied upon for all that it would have reasonably suggested to one having ordinary skill in the art, including non-preferred embodiments (see MPEP 2123). The Examiner has cited particular locations in the reference(s) as applied to the claims above for the convenience of the Applicants. Although the specified citations are representative of the teachings of the art and are applied to the specific limitations within the individual claims, typically other passages and figures will apply as well.
Jacobson et al. teaches in figs. 37-38: a computer 3702 with front end application 108 and storage 3708. A server 12 with front end I/O interface(s) 22 and memory includes storage system 34;
para. 52: select a data processing engine based on job characteristics and execution requirements. The data processing engine may be selected from a set of data processing engines of different types. Examples of different types of data processing engines include parallel processing engines and distributed computing engines. For example, a parallel processing engine may be a scalable data integration processing engine, while an example of a distributed computing engine is a scalable distributed computing engine for cloud computing environments, such as Hadoop™, available from Apache Software Foundation. The distributed computing engine may also include a MapReduce model, which provides an interface to facilitate meeting various data integration needs;
para. 55-56: the data processing engine may be selected upon determining that the data processing engine best satisfies predefined criteria, such as one or more of speed, efficiency, resource consumption, job execution success rate, user-specified execution time constraints, etc.
para. 58: the engine manager 118 may be responsible for running the desired job on the appropriate processing engine. To this end, the engine manager 118 may invoke the engine selector to select the appropriate processing engine based on predefined criteria. The engine manager 118 may also invoke the score composer 120 to generate an execution plan for the selected processing engine. The engine manager 118 may also invoke the execution manager to implement the generated execution plan on the selected processing engine.
para. 76: a parallel processing engine has an initial startup phase, during which the parallel processing engine parses an Orchestrate Shell (OSH) script, invokes the score composer to generate a parallel engine score to represent the parallel execution plan, and instantiates a network of processes on a set of nodes that form a parallel engine cluster for the parallel processing engine.
Thus, either the computer 3702 or the server 12 that received a data query request is determined as data processing engine/computer/server that best satisfies the client query as being selected to perform task(s) by the engine manger 118, said computer 3702 or the server 12 is determined as the target data processing engine – See fig. 17: target data processing engine is the first data processing engine.
Mattsson also teaches in para. 10-11: the dispatcher is in communication with one or more engines and receives one or more requests from a client and delegates at least one of the one or more requests to the one or more engines. A first of the engines may have a different service class than a second of the engines. The dispatcher may be configured to parse at least one of said one or more queries and delegate at least one of the one or more queries to a subset of said one or more engines on the basis of query type; para. 50: upon receiving the query, the dispatcher divides the query into sub-queries that relate to different portions of the database (step S6). These portions can include selected rows, selected columns, or combinations thereof. See fig. 3a: the data processing engine 102a that received the data query request is also the target data processing engine.
“Mattsson does not disclose determining a storage position of the data queried by the data query request in the back-end node by the front-end node”, “As such, Mattson does not disclose determining a storage position of the data queried by the data query request in the back-end node by the front-end node, and especially does not disclose doing so in response to the target data processing engine being the first data processing engine that received the data query request”…, examiner respectfully disagrees.
Jacobson et al. teaches in para. 131-134: a computer 3702, computer memory 3706, a storage 3708; para. 66: reading and writing data to and from storage. Thus, said storage does store data that serves the reading/writing requests. The writing request can also be a data query request (since “query” is technically referred to any command sent to a database/storage to perform an action).
para. 58: the engine manager 118 may be responsible for running the desired job on the appropriate processing engine. To this end, the engine manager 118 may invoke the engine selector to select the appropriate processing engine based on predefined criteria. The engine manager 118 may also invoke the score composer 120 to generate an execution plan for the selected processing engine. The engine manager 118 may also invoke the execution manager to implement the generated execution plan on the selected processing engine.
See figs. 4-5: execution plan(s) is/are created based on the received request, and serialize/store execution plan to storage for execution (equivalent to storage location of the data being queried, a backend node).
Mattsson also teaches in para. 10-11: the dispatcher is in communication with one or more engines and receives one or more requests from a client and delegates at least one of the one or more requests to the one or more engines. A first of the engines may have a different service class than a second of the engines. The dispatcher may be configured to parse at least one of said one or more queries and delegate at least one of the one or more queries to a subset of said one or more engines on the basis of query type; para. 50: upon receiving the query, the dispatcher divides the query into sub-queries that relate to different portions of the database (step S6). These portions can include selected rows, selected columns, or combinations thereof, thus, Mattsson does teach determining a storage position of the data queried by the data query request in the back-end node by the front-end node.
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.
Claim(s) 1-11, 13-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Jacobson et al. (US 2014/0282605) in view of Mattsson et al. (US 20080022136).
As per claims 1, 16 and 20, Jacobson et al. (US 2014/0282605) teaches
a method of performing data query and data analysis, comprising: receiving a data query request by a first data processing engine, wherein the first data processing engine comprises a front-end node and a back-end node, the front-end node receives the data query request, and the back-end node stores data to be queried (fig. 1: fig. 1: an engine manager associates with the engine selector, thus, the engine manager selects relating engine(s) among engines set/list that is/are appropriate to perform the requested task. The engine manager also associates with the execution manager for execution of tasks on the selected engines. See figs. 4-5: execution plan(s) is/are created based on the received request, and serialize/store execution plan to backend storage for execution. See also figs. 37-38: a computer 3702 with front end application 108 and backend storage 3708. A server 12 with front end I/O interface(s) 22 and memory includes storage system 34; fig. 19, item 1980: serialize execution plan to storage/backend node; para. 57: the application 108/front-end node includes a request handler, an engine selector, an engine manager, a score composer, and an execution manager, also referred to herein as a process manager; receives a job run request from a client; para. 66: reading and writing data to and from storage. Thus, said storage does store data that serves the reading/writing requests. The writing request can also be a data query request (since “query” is technically referred to any command sent to a database/storage to perform an action));
selecting a target data processing engine from a data processing engine candidate set by the front-end node based on the data query request, wherein the target data processing engine performs data analysis on data queried by the data query request, the data processing engine candidate set comprises the first data processing engine that received the data query request and a second data processing engine (fig. 1: an engine manager associates with the engine selector, thus, the engine manager selects relating engine(s) among engines set/list that is/are appropriate to perform the requested task. The engine manager also associates with the execution manager for execution of tasks on the selected engines. See figs. 4-5: execution plan(s) is/are created based on the received request, and serialize/store execution plan to backend storage for execution; para. 52, 56, 68-69: the engine selector receives request information such as a data flow description, job execution requirements, etc. The engine selector then selects a processing engine based on predefined criteria. The engine selector analyzes the data flow topology of the desired job and application logic of each stage in the data flow; para. 176: data analytics processing);
and a data processing capability of the second data processing engine is higher than a data processing capability of the first data processing engine (para. 83: if the job success rate for the parallel processing engine is higher, then the application 108 runs the desired job on the parallel processing engine. On the other hand, if the job success rate of the distributed computing engine is higher, then the application 108 runs the desired job on the distributed computing engine; para. 87, 152: measured service: cloud systems automatically control and optimize resource use by leveraging a metering
capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth and active user accounts); para. 156: the capability provided to the consumer is to provision processing, storage, networks and other fundamental computing resources; figs. 17-18: item 1720 - select a first data processing engine
from the data processing engines based on a first predefined set of criteria and the sets of characteristics of the data processing engines);
in response to the target data processing engine being the first data processing engine that received the data query request (para. 52, 55-56: the data processing engine may be selected upon determining that the data processing engine best satisfies predefined criteria, such as one or more of speed, efficiency, resource consumption, job execution success rate, user-specified execution time constraints, etc.; para. 58: the engine manager 118 may be responsible for running the desired job on the appropriate processing engine. To this end, the engine manager 118 may invoke the engine selector to select the appropriate processing engine based on predefined criteria. The engine manager may also invoke the score composer to generate an execution plan for the selected processing engine. The engine manager may also invoke the execution manager to implement the generated execution plan on the selected processing engine; fig. 17: target data processing engine is the first data processing engine);
in response to the target data processing engine being the second data processing engine, generating target information by the front-end node of the first data processing engine based on the data query request, and sending the target information to the second data processing engine (figs. 18-19: receive, subsequent to executing the data flow model using the first data processing engine, select a second data processing engine different from the data processing engine, based on a second predefined set of criteria and the sets of characteristics of the data processing engines, target engine is a distributed computing engine and create distributed execution plan based on the query; para. 61: the desired job is executed on a processing engine that is deemed by the application 108/front-end node as being most suitable for executing the desired job, based on predefined criteria such as job characteristics and execution requirements. To this end, a job execution plan for the desired job and that is specific to the selected processing engine is generated, and execution of the desired job commences on the selected processing engine based on the job execution plan).
Jacobson does not explicitly teach a data query request being a Structured Query Language (SQL) statement; in response to the target data processing engine being the first data processing engine that received the data query request, parsing the SQL statement by the front-end node, determining a storage position of the data queried by the data query request in back-end node by the front-end node, sending a parsing result from the front end node to the back-end node, and performing the data analysis on the data by so that the back-end node.
Mattsson et al. teaches
a data query request being a Structured Query Language (SQL) statement (para. 43: between the application and the DBMS is a front-end preprocessor arranged to intercept any query sent from the application to the back-end preprocessor. Preferably, the front-end preprocessor is arranged to recognize a subset of the query language used, e.g., Structured Query Language (SQL). This recognized subset can include simple queries like: "select age from person" and "insert into person values (`john`, `smith`, 34)");
in response to the target data processing engine being the first data processing engine that received the data query request, parsing the SQL statement by the front-end node, determining a storage position of the data queried by the data query request in the back-end node by the front-end node; sending a parsing result from the front-end node to the back-end node, and performing the data analysis on the data by the back-end node (para. 10-11: the dispatcher is in communication with one or more engines and receives one or more requests from a client and delegates at least one of the one or more requests to the one or more engines. A first of the engines may have a different service class than a second of the engines. The dispatcher may be configured to parse at least one of said one or more queries and delegate at least one of the one or more queries to a subset of said one or more engines on the basis of query type; para. 50: upon receiving the query, the dispatcher divides the query into sub-queries that relate to different portions of the database (step S6). These portions can include selected rows, selected columns, or combinations thereof. See fig. 3a: the data processing engine 102a that received the data query request is also the target data processing engine);
wherein the target information comprises the SQL statement (para. 43: between the application 3 and the DBMS 6 is a front-end preprocessor 14 arranged to intercept any query sent from the application 3 to the back-end preprocessor 12. Preferably, the front-end preprocessor 14 is arranged to recognize a subset of the query language used, e.g., Structured Query Language (SQL)),
wherein the second data processing engine parses the SQL statement to determine the storage position of the data in the back-end node of the first data processing engine, obtains the data from the first data processing engine based on the storage position of the data in the back-end node, and performs the data analysis on the data obtained from the first data processing engine (para. 10-11: the dispatcher is in communication with one or more engines and receives one or more requests from a client and delegates at least one of the one or more requests to the one or more engines. A first of the engines may have a different service class than a second of the engines. The dispatcher may be configured to parse at least one of said one or more queries and delegate at least one of the one or more queries to a subset of said one or more engines on the basis of query type; para. 50: upon receiving the query, the dispatcher divides the query into sub-queries that relate to different portions of the database (step S6). These portions can include selected rows, selected columns, or combinations thereof, thus, Mattsson does teach determining a storage position of the data queried by the data query request in the back-end node by the front-end node).
Mattsson also teaches
a data processing capability of the second data processing engine is higher than a data processing capability of the first data processing engine (para. 74: service Classes denote the encryption capabilities of engines. Key Classes and Service Classes may be implemented as alphanumeric categories such as Key Class 1 or Key Class A. Such an implementation allows for easy comparison to determine if an engine has an appropriate Service Class to perform cryptographic operations on a certain Key Class. In an embodiment where higher class numbers represented stronger encryption standards, an engine would be capable of perform cryptographic operations on data of a Key Class if the Service Class number of the engine 124 is greater than or equal to the Key Class number).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Jacobson’s data processing systems with the front-end, backend nodes of Mattsson in order to effectively utilize different database systems which suits certain platforms or to accommodate data processing needed for the data processing system and/or relating resources.
As per claims 2, 17, Jacobson teaches
wherein the selecting a target data processing engine from a data processing engine candidate set in the front-end node based on the data query request comprises: determining, in the front-end node, storage information corresponding to data queried by the data query request, wherein the storage information comprises at least one selected from a group consisting of: space of a storage table, a partition number, and a file number (fig. 4: items 410-435: determining in the front-end node storage information for the received query/request; para. 55: due to the dynamic nature of the predefined criteria, the appropriate data processing engine may vary from execution to execution, even for the same desired job. By providing retargetable engines, the needs of desired jobs may be more readily met, even as the needs change over time, such as in terms of data volume, required execution time, number of partitions, etc.; para. 66: the number and specific types of processing engines supported may be tailored to suit the needs of a particular case);
selecting the second data processing engine as the target data processing engine in response to determining at least one selected from a group consisting of: the space of the storage table being greater than a preset space threshold, the partition number being greater than a preset partition number threshold, and the file number being greater than a preset file number threshold (fig. 1, engines 1 and 3 were selected to handle the request; para. 60, 68: the engine selector 116 receives request information such as a data flow description, job execution requirements, etc. The engine selector 116 then selects a processing engine based on predefined criteria; para. 83: if the job success rate for the parallel processing engine is higher, then the application 108 runs the desired job on the parallel processing engine (step 1690). On the other hand, if the job success rate of the distributed computing engine is higher, then the application 108 runs the desired job on the distributed computing engine (step 1695)); para. 70, 100: the score composer may generate a parallel execution plan for each partial job satisfying predefined parallel subflow criteria, such as the partial job being I/O-centric to a predefined threshold (step 1950). The score composer 120 may generate a distributed execution plan for each partial job satisfying predefined distributed subflow criteria, such as the partial job being performance-centric to a predefined threshold).
As per claims 3, 18, Jacobson teaches
wherein the selecting a target data processing engine from a data processing engine candidate set in the front-end node based on the data query request comprises: determining, in the front-end node, a resource consumption predicted value in a process of processing the data query request; selecting the second data processing engine as the target data processing engine in response to determining that the resource consumption predicted value is greater than a preset resource consumption threshold (para. 54-56: the data processing engine may be selected upon determining that the data processing engine best satisfies predefined criteria, such as one or more of speed, efficiency, resource consumption, job execution success rate, user-specified execution time constraints, etc.; para. 70, 96).
As per claims 4, 19, Jacobson teaches
wherein the generating target information in the front-end node based on the data query request, and sending the target information to the second data processing engine comprises: parsing the data query request in the front-end node, to obtain a first dataset, wherein the first dataset can be processed by the first data processing engine (fig. 3: receive request information including a data flow description and a job execution requirement to a pre-selected engine/first processing engine, create execution plan/parsing the request in order to run the execution plan at the selected first engine/back-end node; para. 53: parallel processing engines may use inter-process communication (IPC) mechanisms for data transfer, whereas MapReduce applications may use filesystem mechanisms for data transfer);
determining whether the first dataset is converted into a second dataset, wherein the second dataset can be processed by the second data processing engine; and if yes, converting the first dataset into the second dataset, and using the second dataset as the target information for transmission to the second data processing engine (para. 127: data sets; para. 70: the job application logic complexity index is determined as a predefined function of one or more of the number of operators that require data be sorted and the number of operators which processing logic includes mapping, merging, aggregation, transformation, passthrough, etc.; para. 110: the second of the sub-flows may run on the parallel processing engine to transform the data).
As per claim 5, Jacobson teaches
wherein after the determining whether the first dataset is converted into a second dataset, the method further comprises: if no, using the data query request as the target information for transmission to the second data processing engine (para. 61: the desired job is executed on a processing engine that is deemed by the application 108 as being most suitable for executing the desired job, based on predefined criteria such as job characteristics and execution requirements. To this end, a job execution plan for the desired job and that is specific to the selected processing engine is generated, and execution of the desired job commences on the selected processing engine based on the job execution plan).
As per claim 6, Jacobson teaches
wherein the data query request comprises an engine identifier of a specified data processing engine; and the selecting a target data processing engine from a data processing engine candidate set in the front-end node based on the data query request comprises: selecting, in the data processing engine candidate set, a data processing engine specified by the data query request as the target data processing engine (fig. 1, engines 1 and 3 were selected to handle the request 106; para. 60, 68: the engine selector 116 receives request information such as a data flow description, job execution requirements, etc. The engine selector 116 then selects a processing engine based on predefined criteria).
As per claim 7, Jacobson teaches
wherein the generating target information in the front-end node based on the data query request, and sending the target information to the second data processing engine comprises: in the front-end node, using the data query request as the target information for transmission to the second data processing engine (fig. 1, engines 1 and 3 were selected to handle the request 106; para. 60, 68: the engine selector 116 receives request information such as a data flow description, job execution requirements, etc. The engine selector 116 then selects a processing engine based on predefined criteria).
As per claim 8, Jacobson teaches
wherein the target information is the data query request; and after the generating target information based on the data query request, and sending the target information to the second data processing engine (para. 83: if the job success rate for the parallel processing engine is higher, then the application 108 runs the desired job on the parallel processing engine (step 1690). On the other hand, if the job success rate of the distributed computing engine is higher, then the application 108 runs the desired job on the distributed computing engine (step 1695)),
the method further comprises: determining whether metadata is buffered in the second data processing engine, wherein the metadata is metadata of a data table that stores data queried by the data query request; if no, obtaining the metadata from the front-end node, buffering the metadata into a memory of the second data processing engine, and obtaining data from the first data processing engine by using the metadata in the second data processing engine, for data query (para. 68: the engine selector receives request information such as a data flow description, job execution requirements, etc. The engine selector 116 then selects a processing engine based on predefined criteria. At least in some embodiments, the predefined criteria may be a job success rate that is determined based on a decision matrix generated by the engine selector; para. 95: the job run information may also be referred to as operational metadata; para. 123: table of operational aspects of job run metadata);
As per claim 9, Jacobson teaches
wherein after the determining whether metadata is buffered in the second data processing engine, the method further comprises: if yes, obtaining the data from the first data processing engine by using the metadata in the second data processing engine, for data query (fig. 1, engines 1 and 3 were selected to handle the request 106; para. 60, 68: the engine selector 116 receives request information such as a data flow description, job execution requirements, etc. The engine selector 116 then selects a processing engine based on predefined criteria; para. 65: the engine manager 118 generates an execution plan for the desired job and specific to the selected or preselected processing engine. At step 340, the engine manager 118 executes the desired job by running the execution plan).
As per claim 10, Jacobson teaches
wherein the obtaining data from the first data processing engine by using the metadata in the second data processing engine, for data query comprises: sending a data obtaining request to the front-end node by using the metadata in the second data processing engine, and receiving data fed back by the front-end node for data query (para. 5; fig. 1: the application node 108 is the front-end node that receives the request and the execution environment 110 is the backend node which carries out execution plan - See fig. 37, the remote execution environment 110/a backend node; figs. 18-19, item 1980: serialize execution plan to storage/backend node; fig. 20: communication of operational metadata in dataflow checkpoints of front-end execution plan; para. 65: the engine manager 118 selects a suitable processing engine/remote back-end node – based on the request information; para. 95: the job run information may also be referred to as operational metadata.)
Mattsson also teaches in fig. 2a: the frond-end processor 14 intercepts and parses a SQL query, forward to dispatcher sub-queries and forward sub-query to designated preprocessor where the DBMS 106 manage storage locations of data associated with engines 124a-n; para. 23: the request includes seeking interaction with first data from the first portion and seeking interaction with second data from the second portion. The second preprocessor is in communication with the first preprocessor and is configured to execute a cryptographic operations on data contained in and produced in response to the request.
As per claim 11, Jacobson teaches
wherein the obtaining data from the first data processing engine by using the metadata in the second data processing engine, for data query comprises (para. 94-95: the job run information may also be referred to as operational metadata; para. 100: the score composer may generate a parallel execution plan for each partial job satisfying predefined parallel sub-flow criteria/metadata, such as the partial job being I/O-centric to a predefined threshold. The score composer may generate a distributed execution plan for each partial job satisfying predefined distributed sub-flow criteria/metadata, such as the partial job being performance-centric to a predefined threshold).
Jacobson does not explicitly teach performing data pulling in the back-end node by using the metadata in the second data processing engine, and performing data query on pulled data.
Mattsson teaches said limitation at para. 49-50: the front-end preprocessor 14 intercepts a query (step S1) sent to the database 7 from the client 22 and/or the application 3, and attempts to parse this query, divides the query into sub-queries that relate to different portions of the database (step S6). These portions can include selected rows, selected columns, or combinations thereof.
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Jacobson to include performing data query on the data relating to the second processing engine of Mattsson in order to effectively retrieve portions of requested data in association with the front-end requested query.
As per claim 13, Jacobson teaches
wherein the parsing the data query request in the front-end node, and sending a parsing result to the back-end node, so that the back-end node performs data query comprises: parsing the data query request in the front-end node, to generate a physical execution plan, splitting the physical execution plan into a plurality of plan fragments, creating a fragment instance according to the plurality of plan fragments, and sending the fragment instance to the back-end node; and processing the fragment instance in the back-end node by using a pipeline link, to query data (fig. 3: receive request information including a data flow description and a job execution requirement to a pre-selected engine/first processing engine, create execution plan/parsing the request in order to run the execution plan at the selected first engine/back-end node; para. 5: work is distributed from the master computing device into the cloud and to the worker computing devices within the cloud. The worker computing devices perform the work and return the results to the master computing device. The master computing device then assembles the results received from the worker computing devices; para. 53, 57: the application 108/front-end node includes a request handler, an engine selector, an engine manager, a score composer, and an execution manager, also referred to herein as a process manager; receives a job run request from a client; para. 65: the engine manager selects a suitable processing engine/back-end node– based on the request information and according to the empirical model described above; para. 103: the score composer may identify subflows appropriate for specific processing engines and generate one or more retargetable checkpoints based on the identified subflows. Similarly, based on the step 2008, the score composer may identify subflows appropriate for increased pipeline parallelism in processing the data flow and generate one or more parallel checkpoints based on the identified subflows).
As per claim 14, Jacobson teaches
obtaining, in the front-end node, a processing result for the data query request from the second data processing engine (para. 5: work is distributed from the master computing device into the cloud and to the worker computing devices within the cloud. The worker computing devices perform the work and return the results to the master computing device. The master computing device then assembles the results received from the worker computing devices; para. 57: the application 108/front-end node includes a request handler, an engine selector, an engine manager, a score composer, and an execution manager, also referred to herein as a process manager; receives a job run request from a client; para. 65: the engine manager selects a suitable processing engine/back-end node– based on the request information and according to the empirical model described above; para. 178: the user may request execution of data flows and access results thereof, from any computing system attached to a network connected to the cloud (e.g., the Internet) and be charged based on the processing
environment(s) used).
As per claim 15, Jacobson teaches
wherein the first data processing engine comprises a massively parallel processing database, and the second data processing engine comprises a distributed computing framework (para. 51-52: massively parallel processing/MPP, distributed computing engines; para. 79).
Claim 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Jacobson et al. (US 2014/0282605) in view of Mattsson et al. (US 20080022136) and further in view of Jundt et al. (US 20180210429).
As per claim 12, Jacobson teaches para. 127: additional partitions may be created by reconfiguring the parallel processing engine to facilitate execution of the sub-flows. Further, other embodiments are broadly contemplated. For example, data segmentation techniques may also be applied for data storage and retrieval at qualified checkpoints.
Mattsson teaches said limitation at para. 49-50: the front-end preprocessor 14 intercepts a query (step S1) sent to the database 7 from the client 22 and/or the application 3, and attempts to parse this query, divides the query into sub-queries that relate to different portions of the database (step S6). These portions can include selected rows, selected columns, or combinations thereof.
Jacobson and Mattsson do not explicitly teach said claim.
Jundt teaches
wherein data in the back-end node is stored in data tablets, and the metadata comprises metadata of the data tablets (para. 90: backend node is a tablet, hand-held smart device etc.; para. 120: at least some of the values of the properties held or stored in the instance of the device placeholder 300 of the field device 102 are stored as metadata);
the performing data pulling in the back-end node by using the metadata comprises: generating at least one data pulling task according to the data tablets, wherein one data pulling task pulls data corresponding to at least one data tablet; and executing the at least one data pulling task, to perform data pulling in the back-end node (fig. 8: communication tasks to backend devices which include tablets; para. 90: generally, a back-end commissioning tool 138 is a laptop or desktop computer (e.g., reference 138a), a tablet or hand-held smart device (e.g., reference 138b), or other portable or stationary computing device disposed in the back-end environment; para. 10, 154: pulling the information from the smart field device).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Jacobson and Mattsson to include the back-end node is stored in data tablets of Jundt in order to effectively utilize different database/device systems which suits the users’ needs or to accommodate data processing needed for the data processing system.
Conclusion
The prior art made of record and not relied upon is considered pertinent to
applicant's disclosure. Chakravarty (US 20250037082) teaches at para. 27: datasets stored in the backend data engines.
Hankins (US 10769166) teaches at col. 21: 2-7: Comet Engines 4010 and 4020 will begin retrieving, pulling, and extracting data and metadata (e.g., tables, fields, etc.) from the user defined databases within the user network 5000 systems and further pushing the retrieved and extracted data to one or more back-end or cloud servers and databases.
Samdadiya et al. (US 2012/0136921) teaches in fig. 1: query front-end, query back-end, monitoring query engine, structured data storage.
Malik et al. (US 20220392176) teaches at para. 68: the processing components, at block 606 such as, for example, a local computer, a smartphone, a tablet, a backend server, cloud computing infrastructure, a blockchain virtual machine executing a smart contract, or other processing components may use the contextual information to call a function, at block 608, that modifies asset metadata or metadata of an NFT mapped to the asset.
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 LINH BLACK whose telephone number is (571)272-4106. The examiner can normally be reached 9AM-5PM EST M-F.
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, Tony Mahmoudi can be reached on 571-272-4078. 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.
/LINH BLACK/Examiner, Art Unit 2163 4/18/2026
/TONY MAHMOUDI/Supervisory Patent Examiner, Art Unit 2163
Prosecution Insights