DETAILED ACTION
1. The present application 19/300,465 filed on 08/14/2025, is being examined under the first inventor to file provisions of the AIA . Claims 1-20 are pending.
Drawings
2. The drawings received on 08/14/2025 are accepted by the Examiner.
Priority
3. Acknowledgment is made of applicant’s claim for priority to the earlier-filed applications:
No: 18/533,003, filed on 12/07/2023, which issued as U.S. Patent No.12,399,870.
No: 17/463,345, filed on 08/31/2021, which issued as U.S. Patent No 11,841,835.
No: 16/018,777, filed on 06/26/2018, which issued as U.S. Patent No 11,106,638.
No: 15/262,207, filed on 09/12/2016, which issued as U.S. Patent No 10,007,674.
No: 62,349,548, filed on 06/13/2016.
Review under 35 USC § 101
4. Claims 1-20 are directed to a process, a machine and an article of manufacture have been reviewed. Claims 1-10 are appeared to be in one of the statutory categories [e.g., a process], the process is a method of managing builds in dataset branches and transmitting information regarding the build in response to a request. Claims 1-10 do not fall within at least one of the groupings of abstract ideas enumerated in the 2019 PEG. Claims 11-20 are appeared to be in one of the statutory categories [e.g., Machine], the machine comprising a memory; one or more processors coupled to the memory and configured to manage builds in dataset branches and transmit information regarding the build in response to a request. Claims 11-20 do not fall within at least one of the groupings of abstract ideas enumerated in the 2019 PEG. Therefore, 1-20 are qualified as eligible subject Matter under 35 USC 101.
Double Patenting
5. The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory obviousness-type double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the conflicting application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. Effective January 1, 1994, a registered attorney or agent of record may sign a terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 37 CFR 3.73(b).
6. Claims 1-20 are rejected on the ground of nonstatutory obvious double patenting over claims 1-17 of Patent No.: US 11,106,638 B2. The subject matter claimed in the instant application is disclosed in the Patent No.: US 11,106,638 B2. For example:
Patent No.: US 11,106,638 B2
Instant Application: 19/300,465
1. A method for data revision control in a large-scale data analytic system:
storing a first version of a first dataset that is derived from a first version of a second dataset based on a first execution of a first version of a driver program;
storing, in a build catalog, a first build catalog entry comprising an identifier of the first version of the first dataset, an identifier of the first version of the second dataset, a first branch name, and an identifier of the first version of the driver program;
storing a second version of the first dataset that is derived from a second version of the second dataset based on a second execution of the first version of the driver program;
storing, in the build catalog, a second build catalog entry comprising an identifier of the second version of the first dataset, an identifier of the second version of the second dataset, a second branch name that is different from the first branch name, and an identifier of the first version of the driver program, the build catalog including the first build catalog entry and the second build catalog entry; and causing display of a provenance graph in a graphical user interface based on the first build catalog entry and the second build catalog entry, the provenance graph display comprising: a first node representing the first version of the first dataset, a second node representing the first version of the second dataset, a third node representing the second version of the first dataset, a fourth node, representing the second version of the second dataset, a first directed edge from the first node to the second node, and a second directed edge from the third node to the fourth node.
15. A system, comprising: one or more processors; one or more storage media storing one or more programs which, when executed by the one or more processors, cause:
storing a first version of a first dataset that is derived from a first version of a second dataset based on a first execution of a first version of a driver program;
storing, in a build catalog, a first build catalog entry comprising an identifier of the first version of the first dataset, an identifier of the first version of the second dataset, a first branch name, and an identifier of the first version of the driver program;
storing a second version of the first dataset that is derived from a second version of the second dataset based on a second execution of the first version of the driver program;
storing, in the build catalog, a second build catalog entry comprising an identifier of the second version of the first dataset, an identifier of the second version of the second dataset, a second branch name that is different from the first branch name, and an identifier of the first version of the driver program, the build catalog including the first build catalog entry and the second build catalog entry; and causing display of a provenance graph in a graphical user interface based on the first build catalog entry and the second build catalog entry, the provenance graph display comprising:
a first node representing the first version of the first dataset, a second node representing the first version of the second dataset, a third node representing the second version of the first dataset, a fourth node, representing the second version of the second dataset, a first directed edge from the first node to the second node, and a second directed edge from the third node to the fourth node.
1. A method of managing builds in dataset branches, comprising:
storing, in a build catalog, an entry for each update of a dataset, the entry including a branch identifier, an identifier and a version of the dataset, and build dependency information; receiving a first request to build a second branch having a first branch as a parent branch, the first branch being associated with a first version of a first driver program for building a first dataset from a set of child datasets of the first dataset, the second branch being associated with a second version of the first driver program;
determining that the second branch does not have any version of a specific child dataset of the set of child datasets based on the build catalog; retrieving a latest version of the specific child dataset from the first branch based on the build catalog; causing a build of the first dataset based on the latest version of the specific child dataset and the second version of the first driver program to obtain a first new version of the first dataset; transmitting information regarding the build in response to the first request, wherein the method is performed by one or more processors.
11. A system for managing builds in dataset branches, comprising: a memory; one or more processors coupled to the memory and configured to perform:
storing, in a build catalog, an entry for each update of a dataset, the entry including a branch identifier, an identifier and a version of the dataset, and build dependency information;
receiving a first request to build a second branch having a first branch as a parent branch, the first branch being associated with a first version of a first driver program for building a first dataset from a set of child datasets of the first dataset, the second branch being associated with a second version of the first driver program; determining that the second branch does not have any version of a specific child dataset of the set of child datasets based on the build catalog; retrieving a latest version of the specific child dataset from the first branch based on the build catalog; causing a build of the first dataset based on the latest version of the specific child dataset and the second version of the first driver program to obtain a first new version of the first dataset; transmitting information regarding the build in response to the first request.
creating a trigger for building the first dataset when a newer version of a particular child dataset of the set of child datasets than a version used to build a current version of the first dataset becomes available for use in the first branch based on the build catalog.
7. Claims 1-20 are rejected on the ground of nonstatutory obvious double patenting over claims 1-8 of Patent No.: US 10007674 B2. The subject matter claimed in the instant application is disclosed in the Patent No.: US 10007674 B2. For example:
Patent No.: US 10,007,674 B2
Instant Application: 19/300,465
1. A method for data revision control in a large-scale data analytic system: at one or more machines comprising one or more processors and memory storing one or more programs executed by the one or more processors to perform the method, performing operations comprising:
storing a first version of a first dataset that is derived from a first version of a second dataset based on a first execution of a first version of a driver program; storing a first build catalog entry comprising an identifier of the first version of the first dataset, an identifier of the first version of the second dataset, a first branch name, and an identifier of the first version of the driver program; storing a second version of the first dataset that is derived from a second version of the second dataset based on a second execution of the first version of the driver program; storing a second build catalog entry comprising an identifier of the second version of the first dataset, an identifier of the second version of the second dataset, a second branch name that is different from the first branch name, and an identifier of the first version of the driver program; storing a first transaction entry in a database, the first transaction entry comprising a first transaction commit identifier of the first version of the first dataset; wherein the first build catalog entry comprises the first transaction commit identifier; storing a second transaction entry in the database, the second transaction entry comprising a second transaction commit identifier of the first version of the second dataset; wherein the identifier of the first version of the second dataset in the first build catalog entry is the second transaction commit identifier; storing a third transaction entry in the database, the third transaction entry comprising a third transaction commit identifier of the second version of the second dataset; wherein the identifier of the second version of the second dataset in the second build catalog entry is the third transaction commit identifier; and causing display of a provenance graph in a graphical user interface based on the first build catalog entry, the provenance graph display including display of: a first node representing the first version of the first dataset, a second node representing the first version of the second dataset, and a first directed edge from the first node to the second node.
5. One or more non-transitory computer-readable media storing a set of instructions for execution by one or more processors, the set of instructions configured for performing operations comprising: storing a first version of a first dataset that is derived from a first version of a second dataset based on a first execution of a first version of a driver program; storing a first build catalog entry comprising an identifier of the first version of the first dataset, an identifier of the first version of the second dataset, a first branch name, and an identifier of the first version of the driver program; storing a second version of the first dataset that is derived from a second version of the second dataset based on a second execution of the first version of the driver program; storing a second build catalog entry comprising an identifier of the second version of the first dataset, an identifier of the second version of the second dataset, a second branch name that is different from the first branch name, and an identifier of the first version of the driver program; storing a first transaction entry in a database, the first transaction entry comprising a first transaction commit identifier of the first version of the first dataset; wherein the first build catalog entry comprises the first transaction commit identifier; storing a second transaction entry in the database, the second transaction entry comprising a second transaction commit identifier of the first version of the second dataset; wherein the identifier of the first version of the second dataset in the first build catalog entry is the second transaction commit identifier; storing a third transaction entry in the database, the third transaction entry comprising a third transaction commit identifier of the second version of the second dataset; wherein the identifier of the second version of the second dataset in the second build catalog entry is the third transaction commit identifier; and causing display of a provenance graph in a graphi
1. A method of managing builds in dataset branches, comprising:
storing, in a build catalog, an entry for each update of a dataset, the entry including a branch identifier, an identifier and a version of the dataset, and build dependency information; receiving a first request to build a second branch having a first branch as a parent branch, the first branch being associated with a first version of a first driver program for building a first dataset from a set of child datasets of the first dataset, the second branch being associated with a second version of the first driver program;
determining that the second branch does not have any version of a specific child dataset of the set of child datasets based on the build catalog; retrieving a latest version of the specific child dataset from the first branch based on the build catalog; causing a build of the first dataset based on the latest version of the specific child dataset and the second version of the first driver program to obtain a first new version of the first dataset; transmitting information regarding the build in response to the first request, wherein the method is performed by one or more processors.
11. A system for managing builds in dataset branches, comprising: a memory; one or more processors coupled to the memory and configured to perform:
storing, in a build catalog, an entry for each update of a dataset, the entry including a branch identifier, an identifier and a version of the dataset, and build dependency information;
receiving a first request to build a second branch having a first branch as a parent branch, the first branch being associated with a first version of a first driver program for building a first dataset from a set of child datasets of the first dataset, the second branch being associated with a second version of the first driver program; determining that the second branch does not have any version of a specific child dataset of the set of child datasets based on the build catalog; retrieving a latest version of the specific child dataset from the first branch based on the build catalog; causing a build of the first dataset based on the latest version of the specific child dataset and the second version of the first driver program to obtain a first new version of the first dataset; transmitting information regarding the build in response to the first request.
creating a trigger for building the first dataset when a newer version of a particular child dataset of the set of child datasets than a version used to build a current version of the first dataset becomes available for use in the first branch based on the build catalog.
8. Claims 1-20 are rejected on the ground of nonstatutory obvious double patenting over claims 1-19 of Patent No.: US 9,229,952 B2. The subject matter claimed in the instant application is disclosed in the Patent No.: US 9,229,952 B2. For example:
Patent No.: US 9,229,952 B2
Instant Application: 19/300,465
1. A method for preserving history of a derived dataset, the method comprising: at one or more computing devices comprising one or more processors and storage media storing one or more computer programs executed by the one or more processors to perform the method, perform operations of: storing a first version of a derived dataset; wherein the first version of the derived dataset is derived from at least a first version of another dataset by executing a first version of derivation program associated with the derived dataset; storing a first build catalog entry, the first build catalog entry associated with the derived dataset and comprising an identifier of the first version of the other dataset and comprising an identifier of the first version of the derivation program; wherein the first build catalog entry comprises a name of the derived dataset and an identifier of the first version of the derived dataset; updating the other dataset to produce a second version of the other dataset; storing a second version of the derived dataset; wherein the second version of the derived dataset is derived from at least the second version of the other dataset by executing the first version of the derivation program associated with the derived dataset; storing a second build catalog entry, the second build catalog entry associated with the derived dataset and comprising an identifier of the second version of the other dataset and comprising an identifier of the first version of the derivation program; and wherein the second build catalog entry comprises the name of the derived dataset and an identifier of the second version of the derived dataset.
18. A history preserving data pipeline system comprising: one or more computing devices having one or more processors and memory; means for storing a first version of a derived dataset; wherein the first version of the derived dataset is derived from at least a first version of another dataset by executing a first version of derivation program associated with the derived dataset; means for storing a first build catalog entry, the first build catalog entry associated with the derived dataset and comprising an identifier of the first version of the other dataset and comprising an identifier of the first version of the derivation program; wherein the first build catalog entry comprises a name of the derived dataset and an identifier of the first version of the derived dataset; means for updating the other dataset to produce a second version of the other dataset; means for storing a second version of the derived dataset; wherein the second version of the derived dataset is derived from at least the second version of the other dataset by executing the first version of the derivation program associated with the derived dataset; means for storing a second build catalog entry, the second build catalog entry associated with the derived dataset and comprising an identifier of the second version of the other dataset and comprising an identifier of the first version of the derivation program; and wherein the second build catalog entry comprises the name of the derived dataset and an identifier of the second version of the derived dataset.
1. A method of managing builds in dataset branches, comprising:
storing, in a build catalog, an entry for each update of a dataset, the entry including a branch identifier, an identifier and a version of the dataset, and build dependency information; receiving a first request to build a second branch having a first branch as a parent branch, the first branch being associated with a first version of a first driver program for building a first dataset from a set of child datasets of the first dataset, the second branch being associated with a second version of the first driver program;
determining that the second branch does not have any version of a specific child dataset of the set of child datasets based on the build catalog; retrieving a latest version of the specific child dataset from the first branch based on the build catalog; causing a build of the first dataset based on the latest version of the specific child dataset and the second version of the first driver program to obtain a first new version of the first dataset; transmitting information regarding the build in response to the first request, wherein the method is performed by one or more processors.
11. A system for managing builds in dataset branches, comprising: a memory; one or more processors coupled to the memory and configured to perform:
storing, in a build catalog, an entry for each update of a dataset, the entry including a branch identifier, an identifier and a version of the dataset, and build dependency information;
receiving a first request to build a second branch having a first branch as a parent branch, the first branch being associated with a first version of a first driver program for building a first dataset from a set of child datasets of the first dataset, the second branch being associated with a second version of the first driver program; determining that the second branch does not have any version of a specific child dataset of the set of child datasets based on the build catalog; retrieving a latest version of the specific child dataset from the first branch based on the build catalog; causing a build of the first dataset based on the latest version of the specific child dataset and the second version of the first driver program to obtain a first new version of the first dataset; transmitting information regarding the build in response to the first request.
creating a trigger for building the first dataset when a newer version of a particular child dataset of the set of child datasets than a version used to build a current version of the first dataset becomes available for use in the first branch based on the build catalog.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
Claims 1-20 rejected under 35 U.S.C. 112(a), as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. Claims 1 and 11 recite “determining that the second branch does not have any version of a specific child dataset of the set of child datasets based on the build catalog; retrieving a latest version of the specific child dataset from the first branch based on the build catalog; causing a build of the first based on the latest version of the specific child dataset and the second version of the first driver program to obtain a first new version of the dataset,” however, the originally filed specification, including the drawings, do not reasonably convey to one of ordinary skill in the art that the inventor had passion of the claimed subject matter as of the filling data. Specifically, the specification does not describe or otherwise disclose this feature. Accordingly, the originally filed disclosure fails to provide adequate written description support for the limitation. Claims 2-10 and 12-20 are rejected because they depended on claims 1 and 11.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION. —The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b), as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 1 and 11 recite "determining that the second branch does not have any version of a specific child dataset of the set of child datasets based on the build catalog," followed by the steps of "retrieving a latest version of the specific child dataset," "causing a build," and "transmitting information." However, the claim only recites the operations corresponding to the condition that the second branch does not have a version of the specific child dataset. The claim does not specify what occurs if the second branch does have a version of the specific child dataset.
Consequently, it is unclear whether the subsequent limitations of retrieving the latest version of the specific child dataset, causing the build, and transmitting information are performed only when the stated condition is satisfied, are performed regardless of the determination, or are replaced by alternative operations when the condition is not satisfied. Therefore, the metes and bounds of the claimed invention cannot be determined with reasonable certainty, rendering claims 1 and 11 indefinite.
The omission of the alternative execution path renders the scope of the claimed method ambiguous because a person of ordinary skill in the art cannot determine, with reasonable certainty, whether the subsequent method steps are conditional upon the recited determination or are unconditional steps of the claimed method. Claims 2-10 and 11-20 are rejected because they depended on claims 1 and 11.
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 (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.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-4, 8, 9, 11-14, 18 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Briggs (US 8,510,304 B1) and in view of Newcombe (US 8,266,122 B1).
Referring to claims 1 and 11, Briggs discloses a method [system] (See Figure 1 and col 5, lines 1-40, a data access environment 100 implemented on one or more devices 104, a server 108 and storage servers 112(1)-112(N), the server includes one or more processor 118, a memory 120 and/or user controls that enable a user to interact with the device) of managing builds in dataset branches (See col 35 and lines 1-28, managing versions in trees of data blobs), comprising: storing, in a build catalog, an entry for each update of a dataset(See Figure 4, col 15, lines 25-67 and col 26, lines 50-67 and Figure 10, lines 1-30, a transactional index includes a plurality of index entries, such as entries 402(1)-402(N)), the entry including a branch identifier (See Figure 10 and col 27, lines 15-50, Master-12 can be the branch Identifier), an identifier (See Figure 10 and col 27, lines 15-50, the identifier can be John-12-1) and a version of the dataset each of the index entries tracks a plurality and build dependency information (Figure 10 and col 27, lines 15-25, the versioned number 1020 is 11, which holds information regarding the first purchased item of the online purchase order. 12 [e.g., Harry Potter DVD]);
receiving a first request to build a second branch (See Figure 10 and col 27, lines 15-50, the system creates and stores different online purchase orders placed by the customer “John Doe”, the system creates an entry indicating 12-2 [ e.g., second branch], which holds information regarding a second purchased item of an online purchase order no. 12 ) having a first branch as a parent branch (See Figure 10 and col 27, lines 15-50, the first branch is 12), the first branch being associated with a first version of a first driver program for building a first dataset from a set of child datasets of the first dataset (See Figure 10 and co1 27, lines 1-50, the first branch is associated with an e-commerce application [e.g. original version ] for building data blobs from a sets of data blobs [e.g., child 12-1, 12-2] from master-12 [e.g., parent], note the term “program” broadly encompasses executable software components that provide functionality within an application environment);
determining that the second branch [ …has] any version of a specific child dataset of the set of child datasets based on the build catalog (See Figure 10, col 27, lines 1-50, determining the second branch [e.g., 12-2] has a versioned number 5);
retrieving a latest version of the specific child dataset from the first branch based on the build catalog (See Figure 10, col 27, lines 1-50 and col 28, lines 1-67, retrieving latest version for data blob 12-1 from branch 12, the latest version is versioned number 11);
causing a build of the first dataset based on the latest version of the specific child dataset and the second version of the first driver program to obtain a first new version of the first dataset (See Figures 10, 11 , col 27, lines 1-50; col 28, lines 1-67 and col 29, lines 1-67 creating an entry for the data blob 1014 based on the latest version of data blob 1018 and a gift wrap service of the e-commerce application, note the term “program” broadly encompasses executable software components that provide functionality within an application environment, and the gift service of the e-commerce application operates as a distinct version of a software component that performs a particular service function, therefore corresponds to a second version of the driver program); transmitting information regarding the build in response to the first request, wherein the method is performed by one or more processors (See Figures 10, 11 ; col 27, lines 1-50; col 28, lines 1-67 and col 29, lines 1-67, in response to the customer request, the system updates data blob 1012 because the gift wrap service [e.g. the second version] needs to be added to data blob 1014, the data blob 1002 is to be modified because the cost of the gift wrap is $ 2.00, altering the total amount due kept in the data blob 1002 from $ 10 to $ 12).
Briggs does not explicitly disclose determining that a branch or a transaction does not have any version of a specific child datasets of a set of child datasets based on a build catalog.
Newcombe discloses determining that a branch or a transaction does not have any version of a specific child datasets of a set of child datasets based on a build catalog and retrieving a latest version of the specific child dataset from the first branch based on the build catalog (See claim 12, determining if a given version in a child branch is not a direct successor of the latest version in the parent branch and initiating creation of a new version in the parent branch)
Therefore, it would have been obvious to one having ordinary skill in the art at the time of invention was made to modify the Briggs’s system to include determining whether a branch or a transaction lacks any version of a specific child datasets, as taught by Newcombe. Skilled artisan would have been motivated to facilitate a merge process by checking whether required dataset versions are present before performing the merge, thereby reducing merge conflicts and avoiding unnecessary merge attempts (See Newcombe, col 17, lines 36-50). In addition, both of the references (Newcombe and Briggs) teach features that are directed to analogous art and they are directed to the same field of endeavor, such as versioning data in a distributed data store. This close relation between both of the references highly suggests an expectation of success.
As to claims 2 and 12, Briggs discloses comprising storing in the build catalog a first parent-child relationship between the first branch and the second branch or a second parent-child relationship between the second branch and a third branch (See Figure 10 and co1 27, lines 1-50, storing a first branch master-12 [e.g., a parent] and a second branch [e.g., child 12-1 or child 12-2]).
As to claims 3 and 13, Briggs discloses receiving a second request to build a third branch having the second branch as a parent branch; determining that the third branch [… has] a certain version of the first driver program based on the build catalog (See Figure 10, col 27, lines 1-50, determining a third branch [e.g., 12-1, 12-2] ); retrieving the certain version of the first driver program from the second branch based on the build catalog; causing a build of the first dataset based on the certain version of the first driver program to obtain a second new version of the first dataset (See Figures 10, 11 , col 27, lines 1-50; col 28, lines 1-67 and col 29, lines 1-67 creating an entry for the data blob 1014 based on the latest version of data blob 1018 and a gift wrap service [e.g. a second version] of the e-commerce application).
Briggs does not explicitly disclose determining that a branch or a transaction does not have a certain version based on a build catalog.
Newcombe discloses determining that a branch or a transaction does not have a certain version based on a build catalog (See claim 12, determining if a given version in a child branch is not a direct successor of the latest version in the parent branch and initiating creation of a new version in the parent branch)
Therefore, it would have been obvious to one having ordinary skill in the art at the time of invention was made to modify the Briggs’s system to include determining whether a branch or a transaction lacks any version of a specific child datasets, as taught by Newcombe. Skilled artisan would have been motivated to facilitate a merge process by checking whether required dataset versions are present before performing the merge, thereby reducing merge conflicts and avoiding unnecessary merge attempts (See Newcombe, col 17, lines 36-50). In addition, both of the references (Newcombe and Briggs) teach features that are directed to analogous art and they are directed to the same field of endeavor, such as versioning data in a distributed data store. This close relation between both of the references highly suggests an expectation of success.
As to claims 4 and 14, Briggs discloses receiving a second request to build a third branch having the second branch as a parent branch; determining that the third branch […] have any version of the specific child dataset based on the build catalog See Figure 10, col 27, lines 1-50, determining the second branch or third branch [e.g., 12-1, 12-2]);; determining that the second branch […have] any version of the specific child dataset based on the build catalog; retrieving the latest version of the specific child dataset from the first branch based on the build catalog; causing a build of the first dataset based on the latest version of the specific child dataset to obtain a second new version of the first dataset (See Figures 10, 11 , col 27, lines 1-50; col 28, lines 1-67 and col 29, lines 1-67 creating an entry for the data blob 1014 based on the latest version of data blob 1018 and a gift wrap service [e.g. a second version] of the e-commerce application).
Briggs does not explicitly disclose determining that a branch or a transaction does not have a certain version based on a build catalog.
Newcombe discloses determining that a branch or a transaction does not have a certain version based on a build catalog (See claim 12, determining if a given version in a child branch is not a direct successor of the latest version in the parent branch and initiating creation of a new version in the parent branch)
Therefore, it would have been obvious to one having ordinary skill in the art at the time of invention was made to modify the Briggs’s system to include determining whether a branch or a transaction lacks any version of a specific child datasets, as taught by Newcombe. Skilled artisan would have been motivated to facilitate a merge process by checking whether required dataset versions are present before performing the merge, thereby reducing merge conflicts and avoiding unnecessary merge attempts (See Newcombe, col 17, lines 36-50). In addition, both of the references (Newcombe and Briggs) teach features that are directed to analogous art and they are directed to the same field of endeavor, such as versioning data in a distributed data store. This close relation between both of the references highly suggests an expectation of success.
As to claims 8 and 18, Briggs discloses determining that a newer version of the first driver program than a version used to build a current version of the first dataset becomes available for use in the first branch based on the build catalog; causing a build of the first dataset based on the newer version of the first driver program (See Figures 10, 11 , col 27, lines 1-50; col 28, lines 1-67 and col 29, lines 1-67 creating an entry for the data blob 1014 based on the latest version of data blob 1018 and a gift wrap service of the e-commerce application, note the term “program” broadly encompasses executable software components that provide functionality within an application environment, and the gift service of the e-commerce application operates as a distinct version of a software component that performs a particular service function, therefore corresponds to a second version of the driver program).
As to claims 9 and 19, Briggs discloses determining that a new child dataset is added or removed from the set of child datasets, leading to an updated set of child datasets (See Figure 10, col 27, lines 1-50 and col 28, lines 1-67, retrieving latest version for data blob 12-1 from branch 12, the latest version is versioned number 11); causing a build of the first dataset based on the updated set of child datasets (See Figures 10, 11 , col 27, lines 1-50; col 28, lines 1-67 and col 29, lines 1-67 creating an entry for the data blob 1014 based on the latest version of data blob 1018 and a gift wrap service of the e-commerce application).
Claims 5, 10, 15 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Briggs (US 8,510,304 B1) and in view of Newcombe (US 8,266,122 B1) and further in view of Ng (US 4627019 A).
As to claims 5 and 15, Briggs does not explicitly disclose a new version of a dataset being available for use only within a branch or a transaction.
However, Ng discloses a new version of a dataset being available for use only within a branch or a transaction (See col 2, lines 1-15, each of the active transactions is permitted access only to a relation version defined by a relation block associated with a database transaction).
Therefore, it would have been obvious to one having ordinary skill in the art at the time of invention was made to modify the Briggs’s system to include controls access to a version of a dataset, as taught by Ng. Skilled artisan would have been motivated to make sures same versions will be associated with the transaction until the transaction is terminated such that the user process has a consistent view of the database throughout the transaction (See Ng, col 6, lines 55-67). In addition, all of the references (Ng, Newcombe and Briggs) teach features that are directed to analogous art and they are directed to the same field of endeavor, such as versioning data in a distributed data store. This close relation between all of the references highly suggests an expectation of success.
.As to claims 10 and 20, Briggs discloses build a current version of a first dataset becomes available for use in a first branch based on the build catalog but does not explicitly creating a trigger for accessing a first dataset when a newer version of a particular child dataset than a version used to build a current version becomes available for use.
Ng discloses creating a trigger for accessing first dataset when a newer version of a particular child dataset than a version used to build a current version becomes available for use (See col 2, lines 1-15, each of the active transactions is permitted access only to a relation version defined by a relation block associated with a database transaction, the relation version can be defined to grant access when a newer version of a child dataset become available for use).
Therefore, it would have been obvious to one having ordinary skill in the art at the time of invention was made to modify the Briggs’s system to include controls access to a version of a dataset, as taught by Ng. Skilled artisan would have been motivated to make sures same versions will be associated with the transaction until the transaction is terminated such that the user process has a consistent view of the database throughout the transaction (See Ng, col 6, lines 55-67). In addition, all of the references (Ng, Newcombe and Briggs) teach features that are directed to analogous art and they are directed to the same field of endeavor, such as versioning data in a distributed data store. This close relation between all of the references highly suggests an expectation of success.
Claims 6, 7, 16 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Briggs (US 8,510,304 B1) and in view of Newcombe (US 8,266,122 B1) and further in view of Hug (US 5806078 A).
As to claims 6 and 16, Briggs discloses the build dependency information including an identifier and a version of each child dataset from which the dataset is derived (See Figure 15).
Briggs does not explicitly disclose an identifier and a version of a module program for building the dataset.
Hug discloses an identifier and a version of a module program for building the dataset (See Figure 56).
Therefore, it would have been obvious to one having ordinary skill in the art at the time of invention was made to modify the Briggs’s system to include an identifier and a version of a module program for building the dataset, as taught by Hug. Skilled artisan would have been motivated to have a system to store identifiers and versions of a module program to determine relevance for a particular version to improve processing speed (See Hug, Figure 3). In addition, all of the references (Hug, Newcombe and Briggs) teach features that are directed to analogous art and they are directed to the same field of endeavor, such as versioning data in a distributed data store. This close relation between all of the references highly suggests an expectation of success.
As to claims 7 and 17, Briggs does not explicitly query the build catalog for an entry having a given identifier and a latest version.
Hug discloses query the build catalog for an entry having a given identifier and a latest version (See Figures 27 and 28, querying a latest version with version number/name).
Therefore, it would have been obvious to one having ordinary skill in the art at the time of invention was made to modify the Briggs’s system to query a database using an identifier and a version, as taught by Hug. Skilled artisan would have been motivated to have a system to query the database using identifiers and versions to determine relevance for a particular version to improve processing speed (See Hug, Figure 3). In addition, all of the references (Hug, Newcombe and Briggs) teach features that are directed to analogous art and they are directed to the same field of endeavor, such as versioning data in a distributed data store. This close relation between all of the references highly suggests an expectation of success.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Arun et al. (US 6557012 B1) discloses a version control system is described for use in connection with a database management system to facilitate versioning of a database table, the system including a database table and a version control module. The database table comprises a plurality of records, each record including at least one data field for storing user data and at least some of the records including a version control field including version control information. The version control module is configured to, in response to a user query related to the database table and related to a version, generate an augmented query for processing by the database management system, the augmented query relating to the user query and the version control information. The version control module facilitates association of versions of the database with respective ones of a hierarchy of states and allows conflicts therebetween to be resolved, data to be posted from child states to respective parent states in the hierarchy, and referential constraints between tables to be preserved.
Martin et al. (US 9244651 B2) discloses a method for managing document revisions. The method includes receiving a request to access a parent file stored on a server, where the parent file is associated with one or more child files; determining whether a first option is enabled that is associated with selecting a latest version or revision of a child file, where a revision includes one or more versions; determining whether a second option is enabled, where the second option is associated with selecting a released version or revision of a child file; and, for each child file, providing access to a version or revision of the child file based on whether the first option is enabled and whether the second option is enabled.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to YUK TING CHOI whose telephone number is (571)270-1637. The examiner can normally be reached Monday-Friday 9am-6pm.
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, AMY NG can be reached at 5712701698. 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.
/YUK TING CHOI/Primary Examiner, Art Unit 2164
Prosecution Insights