DETAILED ACTION
Claims 1-21 are pending in the application and claims 1-21 are rejected.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, 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-3, 7, 9-11, 15, 17-19, 21 are/is rejected under 35 U.S.C. 103 as being unpatentable over Canter et al. US2014/0181789 in view of Anant Bhardwaj, Souvik Bhattacherjee, Amit Chavan, Amol Deshpande, Aaron J. Elmore, Samuel Madden, Aditya Parameswaran, “DataHub: Collaborative Data Science & Dataset Version Management at Scale”, 9/2/2014, https://arxiv.org/pdf/1409.0798 hereinafter referenced as Bhardwaj in view of Pande et al. US2019/0171435
Regarding claim 1, Canter teaches: identifying a first master branch of a data processing pipeline, (Canter see paragraph 0004 0027 0036 master branch to be edited by developer by editing source code document and pushing it to master branch to be merged with central version)
creating a first test branch of the data processing pipeline, wherein the first test branch referencing the data and a second software logic,
wherein the second software logic programs that implement a second data transformation operation to be applied (Canter see paragraph 0002 0004 0027 0036 0037 developers making edits to create their own branch based on master branch and retrieving central version of source code and making changes to that source code such that software packages comprised of code)
merging the first test branch into the first master branch to generate a second master branch by causing the second master branch to reference the second software logic
wherein the second master branch references the second set of software different from the first set of software referenced by the first master branch (Canter see paragraph 0002 0004 0027 0036 0037 merging developers’ edited line with master branch synchronizing changes to code documents with those in central repository such that software packages comprised of code. Developers making edits to create their own branch based on master branch and retrieving central version of source code and making changes to that source code such that any number or multiple developers reads on any number of multiple test branches with further number of logic and datasets)
wherein the method is performed using one or more processors. (Canter see paragraph 0021 processor)
Canter does not distinctly disclose: the first master branch referencing a first dataset, a first software logic, and a second dataset,
wherein the first software logic includes a first set of software scripts or programs that implement a first data transformation operation to be applied to one or more datasets,
wherein the second dataset results from applying the first software logic to the first dataset,
Wherein the data processing pipeline includes one or more ordered data transformation operations
the first dataset
includes a second set of software scripts or programs, one or more data sets
wherein the second software logic is different from the first software logic
generating a third dataset by applying the second logic to the first dataset; and
master branch to reference the first dataset and the third dataset,
set of software scripts or programs that are different from the first set of software transcripts or programs
Updating the data processing pipeline using the second master branch referencing the second software logic
However, Hecker teaches: the first master branch referencing a first dataset, a first software logic, and a second dataset,
wherein the first software logic that implement a first data transformation operation to be applied to one or more datasets,
wherein the second dataset results from applying the first software logic to the first dataset,
Wherein the data processing pipeline includes one or more ordered data transformation operations (Bhardwaj see pages 1, 3-5, dataset version control where a user can create a branch which is a new version of the data set, make edits and updates to the dataset in the branch and merge the branch back into the master branch where the master branch is culmination of all previous edits to the dataset. User issuing command to create a branch and edit dataset reads on software logic, newly edited dataset reads on any number of datasets resulting from any number of software logic to a dataset, editing updating deleting reads on data transformation operation)
the first dataset
one or more data sets
wherein the second software logic is different from the first software logic (Bhardwaj see pages 1, 3-5, dataset version control where a user can create a branch which is a new version of the data set, make edits and updates to the dataset in the branch and merge the branch back into the master branch where the master branch is culmination of all previous edits to the dataset. Each version each branch is its own software logic which is different from the previous logic)
generating a third dataset by applying the second logic to the first dataset; and
master branch to reference the first dataset and the third dataset,
Updating the data processing pipeline using the second master branch referencing the second software logic (Bhardwaj see pages 1, 3-5, dataset version control where a user can create a branch which is a new version of the data set, make edits and updates to the dataset in the branch and merge the branch back into the master branch where the master branch is culmination of all previous edits to the dataset. Newly edited dataset reads on any number of datasets resulting from any number of software logic to a dataset, users creating branches or multiple users creating multiple different branches reads on any number of branches being merged with master branch)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified a version control system as taught by Canter to include Dataset Version Control System as taught by Bhardwaj for the predictable result of more combining the concept of a version control system and applying to datasets to more efficiently manage data.
Canter as modified does not distinctly disclose: includes a first set of software scripts or programs
includes a second set of software scripts or programs,
set of software scripts or programs that are different from the first set of software transcripts or programs
Pande teaches: includes a first set of software scripts or programs (Pande see paragraph 0044 upgrade logic to carry out a first set of main upgrade scripts step logic to carry out a second set of scripts)
includes a second set of software scripts or programs, (Pande see paragraph 0044 upgrade logic to carry out a first set of main upgrade scripts step logic to carry out a second set of scripts)
set of software scripts or programs that are different from the first set of software transcripts or programs (Pande see paragraph 0044 upgrade logic to carry out a first set of main upgrade scripts step logic to carry out a second set of scripts)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified a version control system as taught by Canter to include multiple scripts as taught by Pande for the predictable result of more efficiently organizing and writing code and developing programs and modifying files
Regarding claim 2 Canter teaches: identifying a difference between the first software logic and the second software logic; and (Canter see paragraph 0050 0053 displaying unique visual characteristics to distinguish status of each line of code and seeing the edits)
receiving, via a user interface, an approval of the difference. (Canter see paragraph 0053 0071 device with monitor to compile and push edits)
Regarding claim 3 Canter teaches: identifying a difference between the second dataset and the third dataset; and(Canter see paragraph 0050 0053 displaying unique visual characteristics to distinguish status of each line of code and seeing the edits such that code being displayed includes a local code status indicating code relevant to developer, global indicator indicating code that all developers can see, and restricted code indicating code being edited by another developer where the existence of restricted code reads on difference)
receiving, via a user interface, an approval of the difference. (Canter see paragraph 0053 0071 device with monitor to compile and push edits)
Regarding claim 7 Canter teaches: responsive to receiving user input requesting a second test branch corresponding to the master branch, creating the second test branch, wherein the second test branch references the first dataset and a copy of the first software logic;
receiving a request to modify the second test branch, the request comprising at least one change to the copy of the first software logic;
modifying the second test branch independently of the master branch to include a third software logic reflecting the at least one change to the copy of the first software logic, the third software logic to be applied to the first dataset to produce a fourth dataset; and
responsive to user input requesting a merge of the modified second test branch into the master branch, merging the modified second test branch into the master branch by causing the master branch to reference the first dataset, the third software logic, and the fourth dataset. (Canter see paragraph 0004 0027 0036 0037 developers making edits to create their own branch based on master branch and retrieving central version of source code and making changes to that source code such that any number or multiple developers reads on any number of multiple test branches with further number of logic and datasets)
Regarding claims 9-11, 15, 17-19, note the rejection of claim(s) 1-3 and 7. The instant claims recite substantially same limitations as the above-rejected claims and are therefore rejected under same prior-art teachings.
Regarding claim 21 Canter teaches: wherein the first master branch includes a copy of the first software logic before the merging, wherein merging the first test branch into the first master branch further comprises replacing the copy of the first software logic with a copy of the second software logic (Canter see paragraph 0027 line edit to include changed line, new line or deleted line)
Claim(s) 5 ,6, 8, 13, 14, 16 are/is rejected under 35 U.S.C. 103 as being unpatentable over Canter et al. US2014/0181789 in view of Anant Bhardwaj, Souvik Bhattacherjee, Amit Chavan, Amol Deshpande, Aaron J. Elmore, Samuel Madden, Aditya Parameswaran, “DataHub: Collaborative Data Science & Dataset Version Management at Scale”, 9/2/2014, https://arxiv.org/pdf/1409.0798 hereinafter referenced as Bhardwaj in view of Pande et al. US2019/0171435 in view of Leblang et al. US5649200
Regarding claim 5, Canter does not teach: wherein merging the first test branch into the master branch further comprises: performing a data health check operation by applying one or more conditions to the second dataset, the one or more conditions comprising a verification that a creation of the second dataset completed successfully and a verification that the second dataset is not stale
However, Leblang teaches: wherein merging the first test branch into the master branch further comprises: performing a data health check operation by applying one or more conditions to the second dataset, the one or more conditions comprising a verification that a creation of the second dataset completed successfully and a verification that the second dataset is not stale. (Leblang see col. 15 lines 39-55 col. 19 lines 56-67 col. 20 lines 1-2 col. 22 lines 1-19 testing source code by compiling, linking and testing to make sure file is correct and fixing bugs before release)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified a version control system as taught by Canter as modified to include bug fixing and subbranches with a graph as taught by Leblang for the predictable result of more efficiently using a version control system
Regarding claim 6, Canter teaches: responsive to receiving, via a user interface, a first request to protect the first test branch, preventing other users from further modifying the first test branch; and (Canter see paragraph 0038 restricted code being code locally written by another developer)
Canter does not teach: responsive to receiving, via the user interface, a second request to further modify the first test branch, creating a child test branch associated with the first test branch
However, Leblang teaches: responsive to receiving, via the user interface, a second request to further modify the first test branch, creating a child test branch associated with the first test branch. (Leblang see col. 7 lines 33-55 multiple levels of subbranches to be created in version control)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified a version control system as taught by Canter as modified to include bug fixing and subbranches with a graph as taught by Leblang for the predictable result of more efficiently using a version control system
Regarding claim 8, Canter does not teach: rendering a visual representation of the data pipeline, including a first graph corresponding to the first master branch and a second graph corresponding to the first test branch,
wherein the first graph includes a first node representing the first dataset, a second node representing the second dataset, and a first edge connecting the first node and the second node
wherein the first edge references the first software logic to be applied to the first dataset in order to produce the second dataset, and
wherein the second graph includes a third node representing the first dataset, a fourth node representing the third dataset, and a second edge connecting the third node and the fourth node, wherein the second edge references the second software logic to be applied to the first dataset in order to produce the third dataset.
However, Leblang teaches: rendering a visual representation of the data pipeline, including a first graph corresponding to the first master branch and a second graph corresponding to the first test branch,
wherein the first graph includes a first node representing the first dataset, a second node representing the second dataset, and a first edge connecting the first node and the second node
wherein the first edge references the first software logic to be applied to the first dataset in order to produce the second dataset, and
wherein the second graph includes a third node representing the first dataset, a fourth node representing the third dataset, and a second edge connecting the third node and the fourth node, wherein the second edge references the second software logic to be applied to the first dataset in order to produce the third dataset. (Leblang: Fig. 5-— show file tree structure “graph with nodes and edges”; col. 25; lines 25-35 - Each configuration record includes a listing of all source file versions that were used, versions of build tools, and all build options that were specified. Special commands compare configuration records, showing the differences between two builds of the same program. Other commands can place version labels on object versions listed in the configuration record; col. 29, lines 26-39).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified a version control system as taught by Canter as modified to include bug fixing and subbranches with a graph as taught by Leblang for the predictable result of more efficiently using a version control system
Regarding claims 13, 14, 16, note the rejection of claim(s) 5, ,6, and 8. The instant claims recite substantially same limitations as the above-rejected claims and are therefore rejected under same prior-art teachings.
Claim(s) 4, 12, and 20 are/is rejected under 35 U.S.C. 103 as being unpatentable over Canter et al. US2014/0181789 in view of Anant Bhardwaj, Souvik Bhattacherjee, Amit Chavan, Amol Deshpande, Aaron J. Elmore, Samuel Madden, Aditya Parameswaran, “DataHub: Collaborative Data Science & Dataset Version Management at Scale”, 9/2/2014, https://arxiv.org/pdf/1409.0798 hereinafter referenced as Bhardwaj in view of Pande et al. US2019/0171435 in view of Van Ryzin US5909689
Regarding claim 4, Canter does not teach: identifying a conflict between the first software logic and the second software logic; and
receiving, via a user interface, a selection of a third software logic to resolve the conflict
However, Leblang teaches: identifying a conflict between the first software logic and the second software logic; and
receiving, via a user interface, a selection of a third software logic to resolve the conflict (Van Ryzin: Col 5 lines 30-37, discussing “yes” branch in Fig. 2c element 230 discloses approving a merger operation upon being informed that there are differences in versions)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified a version control system as taught by Canter as modified to include resolving differences in code versions as taught by Van Ryzin for the predictable result of more efficiently using a version control system
Regarding claims 12 and 20, note the rejection of claim(s) 4. The instant claims recite substantially same limitations as the above-rejected claims and are therefore rejected under same prior-art teachings.
Response to Arguments
Applicant’s argument: Prior art of record does not teach newly amended claims.
Examiner’s response: Applicant’s argument is moot as newly amended subject matter is responded to in thew above rejection
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALLEN S LIN whose telephone number is (571)270-0612. The examiner can normally be reached on M-F 9-5.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kavita Stanley can be reached on (571)272-8352. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ALLEN S LIN/Primary Examiner, Art Unit 2153
Prosecution Insights