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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on December 6, 2024 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
The information disclosure statement (IDS) submitted on June 27, 2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1, 8, 9, 11, 13-17, 19-22, and 26 are rejected under 35 U.S.C. 103 as being unpatentable over Nevrekar (PG Pub. No. 2017/0199875 A1) and further in view of Hiroshige (PG Pub. No. 2019/0065570 A1).
Regarding Claim 1, Nevrekar discloses a method implemented by a data processing system for processing records with an executable dataflow graph by transmitting the records over a dataflow of the dataflow graph and by transmitting, among the records, information, associated with the processing of the records, over the same dataflow without modifying the records, the method including:
accessing, by the data processing system, the dataflow graph having nodes and edges, with each node specifying computer-executable code for executing one or more processes and with each edge specifying dataflow between two or more of the nodes, wherein a first node of the nodes is configured to transmit data to a second node of the nodes (see Nevrekar, paragraph [0011], where Fig; 4 shows an example dataflow graph of a database operation; see also Fig. 4, where dataflow graph is depicted as nodes of operators with arrows indicating direction of data flow);
processing, by the first node of the dataflow graph, a record in accordance with a process specified by computer-executable code specified by the first node (see Nevrekar, paragraph [0011], where Fig; 4 shows an example dataflow graph of a database operation; see also Fig. 4, where dataflow graph is depicted as nodes of operators with arrows indicating direction of data flow);
based on the processing, producing, by the first node, a processed record to be transmitted to the second node, wherein the first node is configured to transmit records in an order to the second node, with the processed record being at a location in the order (see Nevrekar, paragraph [0011], where Fig; 4 shows an example dataflow graph of a database operation; see also Fig. 4, where dataflow graph is depicted as nodes of operators with arrows indicating direction of data flow); and
based on the processing, identifying, by the first node, information associated with processing of the processed record (see Nevrekar, paragraph [0162], where instead of or in addition to timestamps and tracked retrieval times, monotonically-increasing record identifiers and a tracked identifier of the last record retrieved can be used).
Nevrekar does not disclose:
associating, by the first node, the identified information with the processed record by: determining a value specifying the location of the processed record in the order; and
updating the identified information with the value; and
transmitting, by the first node to the second node, a plurality of records including the processed record in the specified location in the order and the updated information among the records in the plurality, by, for each of the records:
identifying a location of the record among the records in the plurality;
determining whether the record is the processed record associated with the updated information by determining whether the identified location corresponds to the value, specifying the location of the processed record, in the updated information; and
when the identified location corresponds to the value in the updated information, transmitting, over a dataflow specified by an edge from the first node to the second node, the record to the second node at the location in the order; and
transmitting, over the same dataflow to the second node, the updated information in proximity to the transmitted record.
Nevrekar in view of Hiroshige discloses:
associating, by the first node, the identified information with the processed record by: determining a value specifying the location of the processed record in the order (see Hiroshige, paragraph [0011], where embodiments of this system can automatically attach version information to the programs created based on the conversion metadata; the programs that convert data may attach the version information to the resultant data);
updating the identified information with the value (see Hiroshige, paragraph [0011], where embodiments of this system can automatically attach version information to the programs created based on the conversion metadata; the programs that convert data may attach the version information to the resultant data); and
transmitting, by the first node to the second node, a plurality of records including the processed record in the specified location in the order and the updated information among the records in the plurality (see Hiroshige, paragraph [0058], where a sequential grouping of data builds 121, 122, 123, may be referred to as a data flow 120; see also paragraph [0059], where Fig. 5 illustrates an example of how plurality of data builds 121, 122, 123 can be tracked according to various embodiments described herein), by, for each of the records:
identifying a location of the record among the records in the plurality (see Hiroshige, paragraph [0012], where the platform includes a database capable of storing conversion metadata, multiple datasets and a central management module that provides access to conversion metadata as well as the location of the resultant datasets);
determining whether the record is the processed record associated with the updated information by determining whether the identified location corresponds to the value, specifying the location of the processed record, in the updated information (see Hiroshige, paragraph [0012], where the platform includes a database capable of storing conversion metadata, multiple datasets and a central management module that provides access to conversion metadata as well as the location of the resultant datasets); and
when the identified location corresponds to the value in the updated information (see Hiroshige, paragraph [0012], where the platform includes a database capable of storing conversion metadata, multiple datasets and a central management module that provides access to conversion metadata as well as the location of the resultant datasets), transmitting, over a dataflow specified by an edge from the first node to the second node, the record to the second node at the location in the order (see Hiroshige, paragraph [0058], where a sequential grouping of data builds 121, 122, 123, may be referred to as a data flow 120; see also paragraph [0059], where Fig. 5 illustrates an example of how plurality of data builds 121, 122, 123 can be tracked according to various embodiments described herein); and
transmitting, over the same dataflow to the second node, the updated information in proximity to the transmitted record (see Hiroshige, paragraph [0058], where a sequential grouping of data builds 121, 122, 123, may be referred to as a data flow 120; see also paragraph [0059], where Fig. 5 illustrates an example of how plurality of data builds 121, 122, 123 can be tracked according to various embodiments described herein; see also Claim 1, where the system includes associate and store the unique version number with the conversion metadata, with the conversion program, and with the target dataset in the memory [it is the position of the Examiner that Hiroshige contemplates storing conversion metadata and the target dataset separately]).
Nevrekar and Hiroshige are both directed to dataflow management. Accordingly, it is the position of the Examiner that it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to combine Nevrekar with Hiroshige as it amounts to combining prior art elements according to known techniques to yield predictable results (see MPEP 2143(I)(A)).
Regarding Claim 8, Nevrekar in view of Hiroshige discloses the method of Claim 1, further including:
determining that the second node of the dataflow graph is a final node of the dataflow graph without additional nodes (see Nevrekar, Fig. 4, where node ‘result data set 420’ is the final node in the dataflow graph); and
transmitting the updated information to a publisher system (see Nevrekar, Fig. 4, where node ‘result data set 420’ is the final node in the dataflow graph).
Regarding Claim 9, Nevrekar in view of Hiroshige discloses the method of Claim 1, further including:
determining that the second node of the dataflow graph is a final node of the dataflow graph without additional nodes (see Nevrekar, Fig. 4, where node ‘result data set 420’ is the final node in the dataflow graph); and
storing the plurality of records in a data store (see Nevrekar, paragraph [0171], where in some examples, execution module 260 can store the output, e.g., by writing to disk).
Regarding Claim 11, Nevrekar in view of Hiroshige discloses the method of Claim 1, wherein:
Nevrekar does not disclose the updated information associated with the processed record includes trace data describing how the first node processed the processed record. Hiroshige discloses the updated information associated with the processed record includes trace data describing how the first node processed the processed record (see Hiroshige, paragraph [0058], where a sequential grouping of data builds 121, 122, 123, may be referred to as a data flow 120; see also paragraph [0059], where Fig. 5 illustrates an example of how plurality of data builds 121, 122, 123 can be tracked according to various embodiments described herein).
Nevrekar and Hiroshige are both directed to dataflow management. Accordingly, it is the position of the Examiner that it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to combine Nevrekar with Hiroshige as it amounts to combining prior art elements according to known techniques to yield predictable results (see MPEP 2143(I)(A)).
Regarding Claim 13, Nevrekar in view of Hiroshige discloses the method of Claim 1, wherein the second node is configured to receive additional records from a third node over a different dataflow and additional information associated with the additional records over the different dataflow (see Nevrekar, Fig. 4, where merger node 418 receives data from two different dataflow branches).
Regarding Claim 14, Nevrekar in view of Hiroshige discloses the method of Claim 13, wherein:
Nevrekar does not disclose the second node selects either the additional information or the updated information for associating with processed records of the third node. Nevrekar in view of Hiroshige discloses the second node selects either the additional information or the updated information for associating with processed records of the third node (see Hiroshige, paragraph [0059], where in some embodiments, the target dataset 220a of a first data build 121 is used as a second source dataset 210b to create a second data build 122 comprising the second source dataset 210b, a second conversion metadata with a second associated unique version number, and a second target dataset 220b with the second associated unique version number; information regarding all conversion activities in the data flow 120 may be maintained in the data build database 185; since the conversion metadata in the data build database 185 is recorded and used to create the conversion programs 141a, 141b of the data builds 121, 122, 123 for each data flow 120, the conversion metadata information is guaranteed to be consistent with respect to all datasets 210, 131, involved in a data flow 120).
Nevrekar and Hiroshige are both directed to dataflow management. Accordingly, it is the position of the Examiner that it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to combine Nevrekar with Hiroshige as it amounts to combining prior art elements according to known techniques to yield predictable results (see MPEP 2143(I)(A)).
Regarding Claim 15, Nevrekar in view of Hiroshige discloses the method of Claim 13, wherein:
Nevrekar does not disclose the second node selects both the additional information and the updated information for associating with processed records of the third node. Nevrekar in view of Hiroshige discloses the second node selects both the additional information and the updated information for associating with processed records of the third node (see Hiroshige, paragraph [0069], where a data merger process 162 may be performed allowing data from any data set 210, 220, can be merged; for example, using the data build manager 180, a user can determine what data sets 210, 220 have been processed to conform to a specific data standard through the conversion metadata).
Nevrekar and Hiroshige are both directed to dataflow management. Accordingly, it is the position of the Examiner that it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to combine Nevrekar with Hiroshige as it amounts to combining prior art elements according to known techniques to yield predictable results (see MPEP 2143(I)(A)).
Regarding Claim 16, Nevrekar in view of Hiroshige discloses the method of Claim 1, wherein the processing, by the first node of the dataflow graph, of the record in accordance with the process specified by computer-executable code encapsulated by the first node is performed to obtain the processed record (see Nevrekar, paragraph [0149], where Fig. 5 shows a template tree 500 (or DAG, and likewise throughout) for an example query of Table 2 and Fig. 4; see also Fig. 5 where each node executes operators and sends data to the next node in the dataflow).
Regarding Claim 17, Nevrekar in view of Hiroshige discloses the method of Claim 1, wherein the updated information associated with the processed record includes one or more values specifying one or more data processing parameters to be used by the second node for defining a portion of processing, by the second node, of the processed record (see Nevrekar, paragraph [0149], where Fig. 5 shows a template tree 500 (or DAG, and likewise throughout) for an example query of Table 2 and Fig. 4; see also Fig. 5 where each node executes operators and sends data to the next node in the dataflow).
Regarding Claim 19, Nevrekar in view of Hiroshige discloses the method of Claim 1, further comprising processing, by the second node of the dataflow graph, the transmitted processed record in accordance with a process specified by computer-executable code specified by the second node, wherein, as the second node processes the processed data record, the second node reads parameter values from the transmitted updated information for processing the processed data record in accordance with the read parameter values (see Nevrekar, paragraph [0149], where Fig. 5 shows a template tree 500 (or DAG, and likewise throughout) for an example query of Table 2 and Fig. 4; see also Fig. 5 where each node executes operators and sends data to the next node in the dataflow).
Regarding Claim 20, Nevrekar in view of Hiroshige discloses the method of Claim 19, further including:
Nevrekar does not disclose updating the information associated with the processed record in accordance with the processing of the processed record by the second node. Nevrekar in view of Hiroshige discloses updating the information associated with the processed record in accordance with the processing of the processed record by the second node (see Hiroshige, paragraph [0059], where in some embodiments, the target dataset 220a of a first data build 121 is used as a second source dataset 210b to create a second data build 122 comprising the second source dataset 210b, a second conversion metadata with a second associated unique version number, and a second target dataset 220b with the second associated unique version number; information regarding all conversion activities in the data flow 120 may be maintained in the data build database 185; since the conversion metadata in the data build database 185 is recorded and used to create the conversion programs 141a, 141b of the data builds 121, 122, 123 for each data flow 120, the conversion metadata information is guaranteed to be consistent with respect to all datasets 210, 131, involved in a data flow 120).
Nevrekar and Hiroshige are both directed to dataflow management. Accordingly, it is the position of the Examiner that it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to combine Nevrekar with Hiroshige as it amounts to combining prior art elements according to known techniques to yield predictable results (see MPEP 2143(I)(A)).
Regarding Claim 21, Nevrekar in view of Hiroshige discloses the method of Claim 20, wherein:
Nevrekar does not disclose the information updated in accordance with the processing of the processed record by the second node specifies a time of processing of the processed record at the second node and/or identifies the second node as last node that processed the processed record. Nevrekar in view of Hiroshige discloses the information updated in accordance with the processing of the processed record by the second node specifies a time of processing of the processed record at the second node (see Hiroshige, paragraph [0053], where conversion runtime information, such as the time of execution and execution status, may be created by the conversion program) and/or identifies the second node as last node that processed the processed record.
Nevrekar and Hiroshige are both directed to dataflow management. Accordingly, it is the position of the Examiner that it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to combine Nevrekar with Hiroshige as it amounts to combining prior art elements according to known techniques to yield predictable results (see MPEP 2143(I)(A)).
Regarding Claim 22, Nevrekar discloses data processing system including a memory and one or more processors for performing operations comprising:
accessing, by the data processing system, the dataflow graph having nodes and edges, with each node specifying computer-executable code for executing one or more processes and with each edge specifying dataflow between two or more of the nodes, wherein a first node of the nodes is configured to transmit data to a second node of the nodes (see Nevrekar, paragraph [0011], where Fig; 4 shows an example dataflow graph of a database operation; see also Fig. 4, where dataflow graph is depicted as nodes of operators with arrows indicating direction of data flow);
processing, by the first node of the dataflow graph, a record in accordance with a process specified by computer-executable code specified by the first node (see Nevrekar, paragraph [0011], where Fig; 4 shows an example dataflow graph of a database operation; see also Fig. 4, where dataflow graph is depicted as nodes of operators with arrows indicating direction of data flow);
based on the processing, producing, by the first node, a processed record to be transmitted to the second node, wherein the first node is configured to transmit records in an order to the second node, with the processed record being at a location in the order (see Nevrekar, paragraph [0011], where Fig; 4 shows an example dataflow graph of a database operation; see also Fig. 4, where dataflow graph is depicted as nodes of operators with arrows indicating direction of data flow); and
based on the processing, identifying, by the first node, information associated with processing of the processed record (see Nevrekar, paragraph [0162], where instead of or in addition to timestamps and tracked retrieval times, monotonically-increasing record identifiers and a tracked identifier of the last record retrieved can be used).
Nevrekar does not disclose:
associating, by the first node, the identified information with the processed record by: determining a value specifying the location of the processed record in the order; and
updating the identified information with the value; and
transmitting, by the first node to the second node, a plurality of records including the processed record in the specified location in the order and the updated information among the records in the plurality, by, for each of the records:
identifying a location of the record among the records in the plurality;
determining whether the record is the processed record associated with the updated information by determining whether the identified location corresponds to the value, specifying the location of the processed record, in the updated information; and
when the identified location corresponds to the value in the updated information, transmitting, over a dataflow specified by an edge from the first node to the second node, the record to the second node at the location in the order; and
transmitting, over the same dataflow to the second node, the updated information in proximity to the transmitted record.
Nevrekar in view of Hiroshige discloses:
associating, by the first node, the identified information with the processed record by: determining a value specifying the location of the processed record in the order (see Hiroshige, paragraph [0011], where embodiments of this system can automatically attach version information to the programs created based on the conversion metadata; the programs that convert data may attach the version information to the resultant data);
updating the identified information with the value (see Hiroshige, paragraph [0011], where embodiments of this system can automatically attach version information to the programs created based on the conversion metadata; the programs that convert data may attach the version information to the resultant data); and
transmitting, by the first node to the second node, a plurality of records including the processed record in the specified location in the order and the updated information among the records in the plurality (see Hiroshige, paragraph [0058], where a sequential grouping of data builds 121, 122, 123, may be referred to as a data flow 120; see also paragraph [0059], where Fig. 5 illustrates an example of how plurality of data builds 121, 122, 123 can be tracked according to various embodiments described herein), by, for each of the records:
identifying a location of the record among the records in the plurality (see Hiroshige, paragraph [0012], where the platform includes a database capable of storing conversion metadata, multiple datasets and a central management module that provides access to conversion metadata as well as the location of the resultant datasets);
determining whether the record is the processed record associated with the updated information by determining whether the identified location corresponds to the value, specifying the location of the processed record, in the updated information (see Hiroshige, paragraph [0012], where the platform includes a database capable of storing conversion metadata, multiple datasets and a central management module that provides access to conversion metadata as well as the location of the resultant datasets); and
when the identified location corresponds to the value in the updated information (see Hiroshige, paragraph [0012], where the platform includes a database capable of storing conversion metadata, multiple datasets and a central management module that provides access to conversion metadata as well as the location of the resultant datasets), transmitting, over a dataflow specified by an edge from the first node to the second node, the record to the second node at the location in the order (see Hiroshige, paragraph [0058], where a sequential grouping of data builds 121, 122, 123, may be referred to as a data flow 120; see also paragraph [0059], where Fig. 5 illustrates an example of how plurality of data builds 121, 122, 123 can be tracked according to various embodiments described herein); and
transmitting, over the same dataflow to the second node, the updated information in proximity to the transmitted record (see Hiroshige, paragraph [0058], where a sequential grouping of data builds 121, 122, 123, may be referred to as a data flow 120; see also paragraph [0059], where Fig. 5 illustrates an example of how plurality of data builds 121, 122, 123 can be tracked according to various embodiments described herein; see also Claim 1, where the system includes associate and store the unique version number with the conversion metadata, with the conversion program, and with the target dataset in the memory [it is the position of the Examiner that Hiroshige contemplates storing conversion metadata and the target dataset separately]).
Nevrekar and Hiroshige are both directed to dataflow management. Accordingly, it is the position of the Examiner that it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to combine Nevrekar with Hiroshige as it amounts to combining prior art elements according to known techniques to yield predictable results (see MPEP 2143(I)(A)).
Regarding Claim 26, Nevrekar discloses one or more non-transitory computer-readable hardware storage devices storing instructions that, when executed by one or more processors, enable the one or more processors to perform operations comprising:
accessing, by the data processing system, the dataflow graph having nodes and edges, with each node specifying computer-executable code for executing one or more processes and with each edge specifying dataflow between two or more of the nodes, wherein a first node of the nodes is configured to transmit data to a second node of the nodes (see Nevrekar, paragraph [0011], where Fig; 4 shows an example dataflow graph of a database operation; see also Fig. 4, where dataflow graph is depicted as nodes of operators with arrows indicating direction of data flow);
processing, by the first node of the dataflow graph, a record in accordance with a process specified by computer-executable code specified by the first node (see Nevrekar, paragraph [0011], where Fig; 4 shows an example dataflow graph of a database operation; see also Fig. 4, where dataflow graph is depicted as nodes of operators with arrows indicating direction of data flow);
based on the processing, producing, by the first node, a processed record to be transmitted to the second node, wherein the first node is configured to transmit records in an order to the second node, with the processed record being at a location in the order (see Nevrekar, paragraph [0011], where Fig; 4 shows an example dataflow graph of a database operation; see also Fig. 4, where dataflow graph is depicted as nodes of operators with arrows indicating direction of data flow); and
based on the processing, identifying, by the first node, information associated with processing of the processed record (see Nevrekar, paragraph [0162], where instead of or in addition to timestamps and tracked retrieval times, monotonically-increasing record identifiers and a tracked identifier of the last record retrieved can be used).
Nevrekar does not disclose:
associating, by the first node, the identified information with the processed record by: determining a value specifying the location of the processed record in the order; and
updating the identified information with the value; and
transmitting, by the first node to the second node, a plurality of records including the processed record in the specified location in the order and the updated information among the records in the plurality, by, for each of the records:
identifying a location of the record among the records in the plurality;
determining whether the record is the processed record associated with the updated information by determining whether the identified location corresponds to the value, specifying the location of the processed record, in the updated information; and
when the identified location corresponds to the value in the updated information, transmitting, over a dataflow specified by an edge from the first node to the second node, the record to the second node at the location in the order; and
transmitting, over the same dataflow to the second node, the updated information in proximity to the transmitted record.
Nevrekar in view of Hiroshige discloses:
associating, by the first node, the identified information with the processed record by: determining a value specifying the location of the processed record in the order (see Hiroshige, paragraph [0011], where embodiments of this system can automatically attach version information to the programs created based on the conversion metadata; the programs that convert data may attach the version information to the resultant data);
updating the identified information with the value (see Hiroshige, paragraph [0011], where embodiments of this system can automatically attach version information to the programs created based on the conversion metadata; the programs that convert data may attach the version information to the resultant data); and
transmitting, by the first node to the second node, a plurality of records including the processed record in the specified location in the order and the updated information among the records in the plurality (see Hiroshige, paragraph [0058], where a sequential grouping of data builds 121, 122, 123, may be referred to as a data flow 120; see also paragraph [0059], where Fig. 5 illustrates an example of how plurality of data builds 121, 122, 123 can be tracked according to various embodiments described herein), by, for each of the records:
identifying a location of the record among the records in the plurality (see Hiroshige, paragraph [0012], where the platform includes a database capable of storing conversion metadata, multiple datasets and a central management module that provides access to conversion metadata as well as the location of the resultant datasets);
determining whether the record is the processed record associated with the updated information by determining whether the identified location corresponds to the value, specifying the location of the processed record, in the updated information (see Hiroshige, paragraph [0012], where the platform includes a database capable of storing conversion metadata, multiple datasets and a central management module that provides access to conversion metadata as well as the location of the resultant datasets); and
when the identified location corresponds to the value in the updated information (see Hiroshige, paragraph [0012], where the platform includes a database capable of storing conversion metadata, multiple datasets and a central management module that provides access to conversion metadata as well as the location of the resultant datasets), transmitting, over a dataflow specified by an edge from the first node to the second node, the record to the second node at the location in the order (see Hiroshige, paragraph [0058], where a sequential grouping of data builds 121, 122, 123, may be referred to as a data flow 120; see also paragraph [0059], where Fig. 5 illustrates an example of how plurality of data builds 121, 122, 123 can be tracked according to various embodiments described herein); and
transmitting, over the same dataflow to the second node, the updated information in proximity to the transmitted record (see Hiroshige, paragraph [0058], where a sequential grouping of data builds 121, 122, 123, may be referred to as a data flow 120; see also paragraph [0059], where Fig. 5 illustrates an example of how plurality of data builds 121, 122, 123 can be tracked according to various embodiments described herein; see also Claim 1, where the system includes associate and store the unique version number with the conversion metadata, with the conversion program, and with the target dataset in the memory [it is the position of the Examiner that Hiroshige contemplates storing conversion metadata and the target dataset separately]).
Nevrekar and Hiroshige are both directed to dataflow management. Accordingly, it is the position of the Examiner that it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to combine Nevrekar with Hiroshige as it amounts to combining prior art elements according to known techniques to yield predictable results (see MPEP 2143(I)(A)).
Claims 2-5, 7, 18, and 23-25 are rejected under 35 U.S.C. 103 as being unpatentable over Nevrekar and Hiroshige as applied to Claims 1, 8, 9, 11, 13-17, 19-22, and 26 above, and further in view of Beckerle (PG Pub. No. 2013/0007750 A1).
Regarding Claim 2, Nevrekar in view of Hiroshige discloses the method of Claim 1, further including:
receiving, at the first node, a set of records to be processed (see Nevrekar, Fig. 4, where filter operator 404 receives data from data source 402).
Nevrekar does not disclose:
storing in a first buffer, for the set of records, a set of data items, a data item of the set of data items including information associated with a record of the set of records, the data item of the set of data items including a count indicating the record associated with the data item; and
storing the set of records in a second buffer.
Nevrekar in view of Beckerle discloses:
storing in a first buffer, for the set of records, a set of data items (see Beckerle, paragraph [0053], where there could be any sort of buffers in between the operators of the flow and the semantics are not affected), a data item of the set of data items including information associated with a record of the set of records, the data item of the set of data items including a count indicating the record associated with the data item (see Nevrekar, paragraph [0162], where instead of or in addition to timestamps and tracked retrieval times, monotonically-increasing record identifiers and a tracked identifier of the last record retrieved can be used); and
storing the set of records in a second buffer (see Beckerle, paragraph [0053], where there could be any sort of buffers in between the operators of the flow and the semantics are not affected).
Nevrekar and Beckerle are both directed to dataflow management. Accordingly, it is the position of the Examiner that it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to combine Nevrekar with Beckerle as it amounts to combining prior art elements according to known techniques to yield predictable results (see MPEP 2143(I)(A)).
Regarding Claim 3, Nevrekar in view of Hiroshige and Beckerle discloses the method of Claim 2, further including for processing a particular record of the set of records:
determining, for the particular record, whether a data item in the first buffer includes a particular count that associates the data item with the particular record (see Nevrekar, paragraph [0162], where instead of or in addition to timestamps and tracked retrieval times, monotonically-increasing record identifiers and a tracked identifier of the last record retrieved can be used).
Nevrekar does not disclose:
when the first buffer includes the data item having the particular count associated with the particular record, processing the particular record by the first node; and
updating the data item based on processing the particular record by the first node; and
when the first buffer does not include the data item having the particular count associated with the particular record, processing the particular record by the first node; and
generating a new data item based on processing the particular record by the first node for being associated with the particular record.
Nevrekar in view of Hiroshige discloses:
when the first buffer includes the data item having the particular count associated with the particular record, processing the particular record by the first node (see Hiroshige, paragraph [0059], where in some embodiments, the target dataset 220a of a first data build 121 is used as a second source dataset 210b to create a second data build 122 comprising the second source dataset 210b, a second conversion metadata with a second associated unique version number, and a second target dataset 220b with the second associated unique version number; information regarding all conversion activities in the data flow 120 may be maintained in the data build database 185; since the conversion metadata in the data build database 185 is recorded and used to create the conversion programs 141a, 141b of the data builds 121, 122, 123 for each data flow 120, the conversion metadata information is guaranteed to be consistent with respect to all datasets 210, 131, involved in a data flow 120),
updating the data item based on processing the particular record by the first node (see Hiroshige, paragraph [0059], where in some embodiments, the target dataset 220a of a first data build 121 is used as a second source dataset 210b to create a second data build 122 comprising the second source dataset 210b, a second conversion metadata with a second associated unique version number, and a second target dataset 220b with the second associated unique version number; information regarding all conversion activities in the data flow 120 may be maintained in the data build database 185; since the conversion metadata in the data build database 185 is recorded and used to create the conversion programs 141a, 141b of the data builds 121, 122, 123 for each data flow 120, the conversion metadata information is guaranteed to be consistent with respect to all datasets 210, 131, involved in a data flow 120);
when the first buffer does not include the data item having the particular count associated with the particular record, processing the particular record by the first node (see Hiroshige, paragraph [0059], where in some embodiments, the target dataset 220a of a first data build 121 is used as a second source dataset 210b to create a second data build 122 comprising the second source dataset 210b, a second conversion metadata with a second associated unique version number, and a second target dataset 220b with the second associated unique version number; information regarding all conversion activities in the data flow 120 may be maintained in the data build database 185; since the conversion metadata in the data build database 185 is recorded and used to create the conversion programs 141a, 141b of the data builds 121, 122, 123 for each data flow 120, the conversion metadata information is guaranteed to be consistent with respect to all datasets 210, 131, involved in a data flow 120), and
generating a new data item based on processing the particular record by the first node for being associated with the particular record (see Hiroshige, paragraph [0073], where a unique version number may be created to correspond to new development or changes in the conversion metadata).
Nevrekar and Hiroshige are both directed to dataflow management. Accordingly, it is the position of the Examiner that it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to combine Nevrekar with Hiroshige as it amounts to combining prior art elements according to known techniques to yield predictable results (see MPEP 2143(I)(A)).
Regarding Claim 4, Nevrekar in view of Hiroshige discloses the method of Claim 1, further including:
Nevrekar does not disclose:
storing, at a first output buffer, the processed record among a set of output records;
determining an output order count for the processed record for being output among the set of output records;
associating the updated information with the output order count for the processed record; and
storing, a at second output buffer, the updated information and the output order count among other updated information for other output records.
Hiroshige discloses:
determining an output order count for the processed record for being output among the set of output records (see Hiroshige, paragraph [0059], where in some embodiments, the target dataset 220a of a first data build 121 is used as a second source dataset 210b to create a second data build 122 comprising the second source dataset 210b, a second conversion metadata with a second associated unique version number, and a second target dataset 220b with the second associated unique version number; information regarding all conversion activities in the data flow 120 may be maintained in the data build database 185; since the conversion metadata in the data build database 185 is recorded and used to create the conversion programs 141a, 141b of the data builds 121, 122, 123 for each data flow 120, the conversion metadata information is guaranteed to be consistent with respect to all datasets 210, 131, involved in a data flow 120); and
associating the updated information with the output order count for the processed record; (see Hiroshige, paragraph [0059], where in some embodiments, the target dataset 220a of a first data build 121 is used as a second source dataset 210b to create a second data build 122 comprising the second source dataset 210b, a second conversion metadata with a second associated unique version number, and a second target dataset 220b with the second associated unique version number; information regarding all conversion activities in the data flow 120 may be maintained in the data build database 185; since the conversion metadata in the data build database 185 is recorded and used to create the conversion programs 141a, 141b of the data builds 121, 122, 123 for each data flow 120, the conversion metadata information is guaranteed to be consistent with respect to all datasets 210, 131, involved in a data flow 120).
Nevrekar and Hiroshige are both directed to dataflow management. Accordingly, it is the position of the Examiner that it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to combine Nevrekar with Hiroshige as it amounts to combining prior art elements according to known techniques to yield predictable results (see MPEP 2143(I)(A)).
Nevrekar in view of Hiroshige does not disclose:
storing, at a first output buffer, the processed record among a set of output records; and
storing, a at second output buffer, the updated information and the output order count among other updated information for other output records.
Nevrekar in view of Hiroshige and Beckerle discloses:
storing, at a first output buffer, the processed record among a set of output records (see Beckerle, paragraph [0053], where there could be any sort of buffers in between the operators of the flow and the semantics are not affected); and
storing, a at second output buffer, the updated information and the output order count among other updated information for other output records (see Beckerle, paragraph [0053], where there could be any sort of buffers in between the operators of the flow and the semantics are not affected).
Nevrekar, Hiroshige, and Beckerle are all directed to dataflow management. Accordingly, it is the position of the Examiner that it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to combine Nevrekar and Hiroshige with Beckerle as it amounts to combining prior art elements according to known techniques to yield predictable results (see MPEP 2143(I)(A)).
Regarding Claim 5, Nevrekar in view of Hiroshige and Beckerle discloses the method of Claim 4, wherein:
Nevrekar does not disclose transmitting, over the same dataflow to the second node, the updated information in proximity to the processed record includes transmitting the updated information based on the output order count associated with the updated information.
Beckerle discloses transmitting, over the same dataflow to the second node, the updated information in proximity to the processed record includes transmitting the updated information based on the output order count associated with the updated information (see Beckerle, paragraph [0045], where the last transaction item of the aggregate is followed by an end-of-work-unit (also known as a ‘wave’) marker [it is the position of the Examiner that sending a end-of-work unit after the data in the dataflow is not patentably distinguishable from transmitting updated information immediately subsequent to the transmitted record on the same dataflow).
Nevrekar and Beckerle are both directed to dataflow management. Accordingly, it is the position of the Examiner that it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to combine Nevrekar with Beckerle as it amounts to combining prior art elements according to known techniques to yield predictable results (see MPEP 2143(I)(A)).
Regarding Claim 7, Nevrekar in view of Hiroshige discloses the method of Claim 1, wherein:
Nevrekar does not disclose transmitting, over the same dataflow to the second node, the updated information in proximity to the transmitted record comprises transmitted the updated information immediately subsequent to the transmitted record on the same dataflow. Beckerle discloses transmitting, over the same dataflow to the second node, the updated information in proximity to the transmitted record comprises transmitted the updated information immediately subsequent to the transmitted record on the same dataflow (see Beckerle, paragraph [0045], where the last transaction item of the aggregate is followed by an end-of-work-unit (also known as a ‘wave’) marker [it is the position of the Examiner that sending a end-of-work unit after the data in the dataflow is not patentably distinguishable from transmitting updated information immediately subsequent to the transmitted record on the same dataflow).
Nevrekar and Beckerle are both directed to dataflow management. Accordingly, it is the position of the Examiner that it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to combine Nevrekar with Beckerle as it amounts to combining prior art elements according to known techniques to yield predictable results (see MPEP 2143(I)(A)).
Regarding Claim 18, Nevrekar in view of Hiroshige discloses the method of Claim 1, wherein:
Nevrekar does not disclose the updated information associated with the processed record includes diagnostic information indicating a performance metric of the first node when processing the processed data record. Beckerle discloses the updated information associated with the processed record includes diagnostic information indicating a performance metric of the first node when processing the processed data record (see Beckerle, Claim 4, where the method further comprises detecting one or more errors and for each of the one or more errors, extracting a message identifier that is associated with a transaction that caused the error).
Nevrekar and Beckerle are both directed to dataflow management. Accordingly, it is the position of the Examiner that it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to combine Nevrekar with Beckerle as it amounts to combining prior art elements according to known techniques to yield predictable results (see MPEP 2143(I)(A)).
Regarding Claim 23, Nevrekar in view of Hiroshige discloses the data processing system of Claim 22, the operations further including:
receiving, at the first node, a set of records to be processed (see Nevrekar, Fig. 4, where filter operator 404 receives data from data source 402).
Nevrekar does not disclose:
storing in a first buffer, for the set of records, a set of data items, a data item of the set of data items including information associated with a record of the set of records, the data item of the set of data items including a count indicating the record associated with the data item; and
storing the set of records in a second buffer.
Nevrekar in view of Beckerle discloses:
storing in a first buffer, for the set of records, a set of data items (see Beckerle, paragraph [0053], where there could be any sort of buffers in between the operators of the flow and the semantics are not affected), a data item of the set of data items including information associated with a record of the set of records, the data item of the set of data items including a count indicating the record associated with the data item (see Nevrekar, paragraph [0162], where instead of or in addition to timestamps and tracked retrieval times, monotonically-increasing record identifiers and a tracked identifier of the last record retrieved can be used); and
storing the set of records in a second buffer (see Beckerle, paragraph [0053], where there could be any sort of buffers in between the operators of the flow and the semantics are not affected).
Nevrekar and Beckerle are both directed to dataflow management. Accordingly, it is the position of the Examiner that it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to combine Nevrekar with Beckerle as it amounts to combining prior art elements according to known techniques to yield predictable results (see MPEP 2143(I)(A)).
Regarding Claim 24, Nevrekar in view of Hiroshige and Beckerle discloses the data processing system of Claim 23, the operations further including, for processing a particular record of the set of records:
determining, for the particular record, whether a data item in the first buffer includes a particular count that associates the data item with the particular record (see Nevrekar, paragraph [0162], where instead of or in addition to timestamps and tracked retrieval times, monotonically-increasing record identifiers and a tracked identifier of the last record retrieved can be used).
Nevrekar does not disclose:
when the first buffer includes the data item having the particular count associated with the particular record, processing the particular record by the first node; and
updating the data item based on processing the particular record by the first node; and
when the first buffer does not include the data item having the particular count associated with the particular record, processing the particular record by the first node; and
generating a new data item based on processing the particular record by the first node for being associated with the particular record.
Nevrekar in view of Hiroshige discloses:
when the first buffer includes the data item having the particular count associated with the particular record, processing the particular record by the first node (see Hiroshige, paragraph [0059], where in some embodiments, the target dataset 220a of a first data build 121 is used as a second source dataset 210b to create a second data build 122 comprising the second source dataset 210b, a second conversion metadata with a second associated unique version number, and a second target dataset 220b with the second associated unique version number; information regarding all conversion activities in the data flow 120 may be maintained in the data build database 185; since the conversion metadata in the data build database 185 is recorded and used to create the conversion programs 141a, 141b of the data builds 121, 122, 123 for each data flow 120, the conversion metadata information is guaranteed to be consistent with respect to all datasets 210, 131, involved in a data flow 120),
updating the data item based on processing the particular record by the first node (see Hiroshige, paragraph [0059], where in some embodiments, the target dataset 220a of a first data build 121 is used as a second source dataset 210b to create a second data build 122 comprising the second source dataset 210b, a second conversion metadata with a second associated unique version number, and a second target dataset 220b with the second associated unique version number; information regarding all conversion activities in the data flow 120 may be maintained in the data build database 185; since the conversion metadata in the data build database 185 is recorded and used to create the conversion programs 141a, 141b of the data builds 121, 122, 123 for each data flow 120, the conversion metadata information is guaranteed to be consistent with respect to all datasets 210, 131, involved in a data flow 120);
when the first buffer does not include the data item having the particular count associated with the particular record, processing the particular record by the first node (see Hiroshige, paragraph [0059], where in some embodiments, the target dataset 220a of a first data build 121 is used as a second source dataset 210b to create a second data build 122 comprising the second source dataset 210b, a second conversion metadata with a second associated unique version number, and a second target dataset 220b with the second associated unique version number; information regarding all conversion activities in the data flow 120 may be maintained in the data build database 185; since the conversion metadata in the data build database 185 is recorded and used to create the conversion programs 141a, 141b of the data builds 121, 122, 123 for each data flow 120, the conversion metadata information is guaranteed to be consistent with respect to all datasets 210, 131, involved in a data flow 120), and
generating a new data item based on processing the particular record by the first node for being associated with the particular record (see Hiroshige, paragraph [0073], where a unique version number may be created to correspond to new development or changes in the conversion metadata).
Nevrekar and Hiroshige are both directed to dataflow management. Accordingly, it is the position of the Examiner that it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to combine Nevrekar with Hiroshige as it amounts to combining prior art elements according to known techniques to yield predictable results (see MPEP 2143(I)(A)).
Regarding Claim 25, Nevrekar in view of Hiroshige discloses the data processing system of Claim 22, the operations further including:
Nevrekar does not disclose:
storing, at a first output buffer, the processed record among a set of output records;
determining an output order count for the processed record for being output among the set of output records;
associating the updated information with the output order count for the processed record; and
storing, a at second output buffer, the updated information and the output order count among other updated information for other output records.
Hiroshige discloses:
determining an output order count for the processed record for being output among the set of output records (see Hiroshige, paragraph [0059], where in some embodiments, the target dataset 220a of a first data build 121 is used as a second source dataset 210b to create a second data build 122 comprising the second source dataset 210b, a second conversion metadata with a second associated unique version number, and a second target dataset 220b with the second associated unique version number; information regarding all conversion activities in the data flow 120 may be maintained in the data build database 185; since the conversion metadata in the data build database 185 is recorded and used to create the conversion programs 141a, 141b of the data builds 121, 122, 123 for each data flow 120, the conversion metadata information is guaranteed to be consistent with respect to all datasets 210, 131, involved in a data flow 120); and
associating the updated information with the output order count for the processed record; (see Hiroshige, paragraph [0059], where in some embodiments, the target dataset 220a of a first data build 121 is used as a second source dataset 210b to create a second data build 122 comprising the second source dataset 210b, a second conversion metadata with a second associated unique version number, and a second target dataset 220b with the second associated unique version number; information regarding all conversion activities in the data flow 120 may be maintained in the data build database 185; since the conversion metadata in the data build database 185 is recorded and used to create the conversion programs 141a, 141b of the data builds 121, 122, 123 for each data flow 120, the conversion metadata information is guaranteed to be consistent with respect to all datasets 210, 131, involved in a data flow 120).
Nevrekar and Hiroshige are both directed to dataflow management. Accordingly, it is the position of the Examiner that it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to combine Nevrekar with Hiroshige as it amounts to combining prior art elements according to known techniques to yield predictable results (see MPEP 2143(I)(A)).
Nevrekar in view of Hiroshige does not disclose:
storing, at a first output buffer, the processed record among a set of output records; and
storing, a at second output buffer, the updated information and the output order count among other updated information for other output records.
Nevrekar in view of Hiroshige and Beckerle discloses:
storing, at a first output buffer, the processed record among a set of output records (see Beckerle, paragraph [0053], where there could be any sort of buffers in between the operators of the flow and the semantics are not affected); and
storing, a at second output buffer, the updated information and the output order count among other updated information for other output records (see Beckerle, paragraph [0053], where there could be any sort of buffers in between the operators of the flow and the semantics are not affected).
Nevrekar, Hiroshige, and Beckerle are all directed to dataflow management. Accordingly, it is the position of the Examiner that it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to combine Nevrekar and Hiroshige with Beckerle as it amounts to combining prior art elements according to known techniques to yield predictable results (see MPEP 2143(I)(A)).
Regarding Claim 5, Nevrekar in view of Hiroshige and Beckerle discloses the method of Claim 4, wherein:
Nevrekar does not disclose transmitting, over the same dataflow to the second node, the updated information in proximity to the processed record includes transmitting the updated information based on the output order count associated with the updated information.
Beckerle discloses transmitting, over the same dataflow to the second node, the updated information in proximity to the processed record includes transmitting the updated information based on the output order count associated with the updated information (see Beckerle, paragraph [0045], where the last transaction item of the aggregate is followed by an end-of-work-unit (also known as a ‘wave’) marker [it is the position of the Examiner that sending a end-of-work unit after the data in the dataflow is not patentably distinguishable from transmitting updated information immediately subsequent to the transmitted record on the same dataflow).
Nevrekar and Beckerle are both directed to dataflow management. Accordingly, it is the position of the Examiner that it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to combine Nevrekar with Beckerle as it amounts to combining prior art elements according to known techniques to yield predictable results (see MPEP 2143(I)(A)).
Claims 6 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Nevrekar and Hiroshige as applied to Claims 1, 8, 9, 11, 13-17, 19-22, and 26 above, and further in view of Benisty (PG Pub. No. 2018/0069658 A1).
Regarding Claim 6, Nevrekar in view of Hiroshige discloses the method of Claim 1, wherein:
Nevrekar does not disclose transmitting, over the same dataflow to the second node, the updated information in proximity to the transmitted record comprises transmitted the updated information immediately prior to the transmitted record on the same dataflow. Benisty discloses transmitting, over the same dataflow to the second node, the updated information in proximity to the transmitted record comprises transmitted the updated information immediately prior to the transmitted record on the same dataflow (see Benisty, paragraph [0042], where pairs of data and corresponding metadata may be interleaved at the HMB 151 according to one or more of a variety of layouts, as further described with reference to FIG. 2).
Nevrekar discloses a dataflow. Benisty contemplates transmitting data and metadata separately in the same channel. There are only a finite number of ways to transmit data and metadata through the same channel: either metadata first or data first. Therefore it is the position of the Examiner that it would have been obvious to one of ordinary skill in the art at the effective filing date of the invention to try adapting the interleaving techniques of Benisty to the dataflow of Nevrekar (see MPEP 2143(I)(E)).
Regarding Claim 10, Nevrekar in view of Hiroshige discloses the method of Claim 1, wherein:
Nevrekar does not disclose the updated information is interleaved within the records of the plurality such that the updated information is transmitted in the dataflow between two consecutive data records. Benisty discloses the updated information is interleaved within the records of the plurality such that the updated information is transmitted in the dataflow between two consecutive data records (see Benisty, paragraph [0005], where in order to store metadata at the access device, the metadata is sent via a bus or other interface to the access device; data and metadata are interleaved at the memory access device, and metadata is sent in an individual packet that is separate from the data).
Nevrekar discloses a dataflow. Benisty contemplates transmitting data and metadata separately in the same channel. There are only a finite number of ways to transmit data and metadata through the same channel: either metadata first or data first. Therefore it is the position of the Examiner that it would have been obvious to one of ordinary skill in the art at the effective filing date of the invention to try adapting the interleaving techniques of Benisty to the dataflow of Nevrekar (see MPEP 2143(I)(E)).
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Nevrekar and Hiroshige as applied to Claims 1, 8, 9, 11, 13-17, 19-22, and 26 above, and further in view of Nanda (PG Pub. No. 2019/0243836 A1).
Regarding Claim 12, Nevrekar in view of Hiroshige discloses the method of Claim 1, wherein:
Nevrekar does not disclose the updated information associated with the processed record includes metadata describing a location for a service call by one or more nodes of the dataflow graph. Nevrekar in view of Nanda discloses the updated information associated with the processed record includes metadata describing a location for a service call by one or more nodes of the dataflow graph (see Nanda, paragraph [0043], where network operations management is also enabled, such as … service call generation).
Nevrekar and Nanda are both directed toward data flowing through pipelines. Accordingly, it is the position of the Examiner that it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to combine Nevrekar with Nanda as it amounts to combining prior art elements according to known techniques to yield predictable results (see MPEP 2143(I)(A)).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FARHAD AGHARAHIMI whose telephone number is (571)272-9864. The examiner can normally be reached M-F 9am - 5pm 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, Apu Mofiz can be reached at 571-272-4080. 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.
/FARHAD AGHARAHIMI/Examiner, Art Unit 2161
/APU M MOFIZ/Supervisory Patent Examiner, Art Unit 2161