DETAILED ACTION
This action is in response to the claims filed October 14, 2025. Claims 1-6, 10, and 13-18 are pending. Claims 1 and 14 are independent claims. Claims 1, 3-4, 10, and 13-18 have been amended. Claims 7-9 and 11-12 have been cancelled.
The objections to the claim are withdrawn in view of Applicant’s amendments to the claims.
The claim rejections under 35 U.S.C 112(b) are withdrawn in view of Applicant’s amendments to the claims.
The claim rejections under 35 U.S.C. 101 are withdrawn in view of Applicant’s arguments and amendments to the claims.
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 § 112(a)
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.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
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 of carrying out his invention.
Claims 15-18 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, 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.
Claim 15 recites “wherein, a usage metric is tracked for each of the one or more data buckets”. While the specification discloses “a usage metric may be tracked for each of the one or more component objects” (see Paragraph [0008]) and “a usage metric may be tracked for each of the one or more data objects” (see Paragraph [0012]), the specification does not provide support for tracking usage data on data buckets. Because the specification does not adequately support the claimed subject matter, it would not reasonably convey to one skilled in the relevant art that the inventor(s), at the time the application was filed, had possession of the claimed invention. Claims 16-18 are rejected in view of their dependency on claim 15.
Claim 16 recites “wherein, for any data bucket run by the user, the user selects a source data object to be run, and wherein the selection comprises”. While the specification discloses “wherein, for any data object run by the user…” (see paragraph [0013]), the specification does not provide support for running a data bucket, which appears to be a method of storage. Because the specification does not adequately support the claimed subject matter, it would not reasonably convey to one skilled in the relevant art that the inventor(s), at the time the application was filed, had possession of the claimed invention. Claims 17-18 are rejected in view of their dependency on claim 16.
Claim 17 recites “wherein, when a new source data object of a data bucket or a new code object is selected by the user, one or more pieces of code are identified as needing to be re-run based on a dependency tree of a new target data object”. While the specification discloses “one or more pieces of code may be identified as needing to be re-run based on the dependency tree of the new version” (see paragraph [0014]), the specification does not provide support for “one or more pieces of code are identified as needing to be re-run based on a new dependency tree of a new target data object”. Specifically, the specification does not support re-running based on a dependency tree of “a new target data object”. Because the specification does not adequately support the claimed subject matter, it would not reasonably convey to one skilled in the relevant art that the inventor(s), at the time the application was filed, had possession of the claimed invention. Claims 18 is rejected in view of its dependency on claim 17.
Claim 18 recites “wherein each data bucket and code object further comprises: statistics including an identity of one or more consuming users…”. While the specification discloses “each data object and code object further may comprise statistics including an identity of one or more consuming users…” (see paragraph [0015]), the specification does not provide support for the statistics being tracked for each data bucket. Because the specification does not adequately support the claimed subject matter, it would not reasonably convey to one skilled in the relevant art that the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim Rejections - 35 USC § 112(b)
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.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 14-18 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, 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.
Claim 14 recites the limitation "the two or more selected target data objects" in lines 23 and 26. There is insufficient antecedent basis for this limitation in the claim. Claim 14 recites “a selection of two or more source data objects” on line 21. It is unclear whether the claim should recite “selected target object” or “selected source object” for the cited lines. For the purpose of examination, both “source data objects” and “target data objects” are interpreted to be “data objects” as is consistent with the wording of the specification. Claims 15-18 are rejected in view of their dependency on claim 14.
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-6 are rejected under 35 U.S.C. 103 as being unpatentable over US 20120324417 A1 (hereinafter “Somani”), in view of “Protego: In-Memory Version Control System in the Cloud” by Gioachin et. al (hereinafter “Gioachin”).
Regarding claim 1, Somani discloses:
A method to comprehensively track and version code and data in a collaborative development environment, the method comprising (Fig. 2, Fig. 3):
generating, by a user working on a project, a package (Paragraph [0018], “In the method 200, a plurality of binary libraries sufficient for building a software project is received by the development environment 102 from the binary repository 104 (operation 202). A request is received from a user to modify source code 116 for at least one of the plurality of binary libraries 114 (operation 204) [generating, by a user working on a project, a package]”) [Examiner’s remarks: A user working on a project requests modifications on files used in the package for their project.];
consuming, by the package, one or more source data objects in a data bucket and one or more component objects, wherein each of the one or more component objects comprises one or more component versions and wherein one of the one or more component versions is selected for consumption (Paragraph [0018]; “In the method 200, a plurality of binary libraries sufficient for building a software project is received by the development environment 102 from the binary repository 104 (operation 202) [consuming, by the package, …one or more component objects]”; Paragraph [0023], “Communicatively coupled with the development environment 302 is a dependency metadata system 308 configured to maintain dependency metadata 318, or to at least provide access thereto. 111 one embodiment, the dependency metadata 318 includes information that determines which code elements, such as source files and binary libraries, are to be included for a particular project or application, which source files are to be compiled before linking, and the like [one or more source data objects in a data bucket]”; Paragraph [0040], “In reference to the example of FIGS. 5A and 5B, the validation environment 410 has published the new library A′ associated with the new checkpoint CP2 to the repository 404, with the new library A′ residing in the repository 404 with the previous version of the library A corresponding to the (previous checkpoint CP1. Thus, depending upon which checkpoint is being requested, the development environment 402 may download the older library A (if checkpoint CP1 is desired), or the most recent library A′ (if the new checkpoint CP2 is being requested) [wherein each of the one or more component objects comprises one or more component versions and wherein one or the one or more component versions is selected for consumption]”);
requesting, by the user, modifications of one or more of the one or more component objects (Paragraph [0018], “A request is received from a user to modify source code 116 for at least one of the plurality of binary libraries 114 (operation 204). As shown in FIG. 1, the user request results in a request for the source code 116 that may be forwarded as a source code request 204A from the development environment 102 to the source control system 106 [requesting, by the user, modifications of one or more of the one or more component objects]”);
generating, by a developer, a new component version for each requested component object modification (Paragraph [0018], “The retrieved source code 116 may take the form of one or more source files that may be edited by the user. The development environment 102 may present the received source code 116 to the user (operation 208), who may then modify the received source code 116, such as by way of the development environment 102 [generating, by a developer, a new component version for each requested component object modification]”);
validating, against the package of the requesting user, the new component versions of the component objects (Paragraph [0037], “The same modified source files may also be forwarded by either the development environment 402 or the source control system 406 to the validation environment 410 (operation 504). The validation environment 410 may then build the project by compiling the modified source files A1.src (MOD), A2.src (MOD) and linking them with the binary libraries B, C associated with the checkpoint CP1 (operation 508). In one example, the validation environment 410 accesses the dependency metadata 418 associated with the current project to perform the build and other associated activities [validating, against the package of the requesting user, the new component versions of the component objects]”);
updating, with their corresponding new component version, each component object (Paragraph [0037], “After the developer has modified the source files A1.src, A2.src in the development environment 402 (operation 464 of FIG. 4B), the developer may check-in the modified source files (labeled A1.src (MOD) and a2.src (MOD) in FIG. 5A) into the source control system 406 (operation 502)”; Paragraph [0039], “If instead, the tests executed in the validation environment 410, or some minimum set of the tests, were successful, the validation environment 410 may generate one or more new libraries (and possibly associated dependency metadata 418) (operation 516), and associate the new libraries with a new checkpoint. In the example of FIG. 5A, the validation environment 410 may combine the compiled code derived from the modified source files A1.src (MOD), A2.src (MOD) with the remaining binary code in the associated library A to generate a new version of the library A (labeled library A′ in FIG. SA) associated with a new checkpoint CP2. The validation environment 410 may then publish the new library A′ (designated in FIG. SA by way of vertical line segments associated with the new checkpoint CP2) to the binary repository 404 (operation 518).” [updating, with their corresponding new component version, each component object]) [Examiner’s remarks: Each component is updated, including with the new code and dependency information.];
updating the package with the updated component objects (Paragraph [0037], “After the developer has modified the source files A1.src, A2.src in the development environment 402 (operation 464 of FIG. 4B), the developer may check-in the modified source files (labeled A1.src (MOD) and a2.src (MOD) in FIG. 5A) into the source control system 406 (operation 502)”; Paragraph [0039], “If instead, the tests executed in the validation environment 410, or some minimum set of the tests, were successful, the validation environment 410 may generate one or more new libraries (and possibly associated dependency metadata 418) (operation 516), and associate the new libraries with a new checkpoint. In the example of FIG. 5A, the validation environment 410 may combine the compiled code derived from the modified source files A1.src (MOD), A2.src (MOD) with the remaining binary code in the associated library A to generate a new version of the library A (labeled library A′ in FIG. SA) associated with a new checkpoint CP2. The validation environment 410 may then publish the new library A′ (designated in FIG. SA by way of vertical line segments associated with the new checkpoint CP2) to the binary repository 404 (operation 518).” [updating the package with the updated component objects]) [Examiner’s remarks: The package (library) is updated with the updated component objects.]:
executing, by a server, the package, wherein the execution comprises consuming the one or more source data objects and the updated component objects, and wherein the execution generates one or more target data objects (Paragraph [0037], “The same modified source files may also be forwarded by either the development environment 402 or the source control system 406 to the validation environment 410 (operation 504). The validation environment 410 may then build the project by compiling the modified source files A1.src (MOD), A2.src (MOD) and linking them with the binary libraries B, C associated with the checkpoint CP1 (operation 508). In one example, the validation environment 410 accesses the dependency metadata 418 associated with the current project to perform the build and other associated activities [executing… the package, wherein the execution comprises consuming the one or more source data objects and the updated component objects ]”; Paragraph [0039], “If instead, the tests executed in the validation environment 410, or some minimum set of the tests, were successful, the validation environment 410 may generate one or more new libraries (and possibly associated dependency metadata 418) (operation 516), and associate the new libraries with a new checkpoint [and wherein the execution generates one or more target data objects]”; Paragraph [0046], “In example embodiments, one or more computer systems (e.g., a standalone, client, or server computer system) or one or more hardware modules of a computer system (e.g., a processor or a group of processors) may be configured by software (e.g., an application or application portion) as a hardware module that operates to perform certain operations as described herein [by the server]”) [Examiner’s remarks: During execution of the package, modified source files (updated component objects), source data objects (dependency metadata), and target data objects (new libraries and associated dependency data) are used and generated.]:
…
saving, to a versioning database, each updated component object (Paragraph [0026], “After the desired modifications are made, the user 320 may then “check in” the modified source code to allow other users to access the modified source code. In one example, the source control system 306 maintains older versions of each source file so that the user 320 may return to an older version of one or more of the source files to eliminate errors introduced into the application by a more recent modification to the source code 316 [saving, to a versioning database, each updated component object]”)…
deploying, on a server executing the package, each of the one or more updated component objects (Paragraph [0034], “In one example, the source control system 406 maintains older versions of each source file. As a result, the request for the source code 416 from the development environment 402 may include some indication as to the version of the source files to be retrieved, such as the checkpoint identifier CPI for the current project revision [deploying, on a server executing the package, each of the one or more updated component objects]”) [Examiner’s remarks: The deployed object (requested object) may be deployed with updated components (current project revision).]
Somani does not explicitly disclose:
generating, by a data governance module operating on the server, a data governance object, wherein the data governance object comprises data lineage of the project, and where in the data lineage defines an association between the one or more target data objects, the one or more source data objects and the one or more updated component objects:
… each source data object, each target data object and the generated data governance object;
However, Gioachin discloses:
…
generating, by a data governance module operating on the server, a data governance object, wherein the data governance object comprises data lineage of the project, and where in the data lineage defines an association between the one or more target data objects, the one or more source data objects and the one or more updated component objects (Pages 234-235, “At the lower level, the key point is the separation between Images (or snapshots) of the software and Transitions between these images. Both entities are explicitly represented in the system as first class objects, and are linked together to form the history graph. - An Image is defined as a filesystem tree structure containing a snapshot of a project at a certain point in time. Images are unique in the system, in the sense that if two images represent the same snapshot, then they are represented by the same object in Protego. Images are the vertices of the history graph. - A Transition is defined as a directed link between two images, thus they form the edges of the history graph. Different transitions can begin or end at any given image, for example transitions α and β in Figure 2(b) begin from the same image…”; Page 235, “In the figure, another edge appears between A and I, named ω. This edge represents the fact that the development of the software between A and I is the implementation of a new feature”) [Examiner’s remarks: Gioachin discloses a system in Protego, which generates data lineage of a project by associating target data objects (later snapshot of a project), source data object (earlier version of a source data object), and updated component object (edges which denote changed features/code).]:
… each source data object, each target data object and the generated data governance object (Abstract, “Moreover, the cloud computational power can be leveraged to provide a higher degree of automation. In this paper, we describe Protego, a cloud-based version control system targeting flexibility and automation”; Page 233, “The main advantages of our schema are 1) the possibility to maintain different histories of a project within the same repository, 2) a new access control engine integrated with the revision data, and 3) the possibility for multiple users to work on the same repository simultaneously”; Pages 234-235, “At the lower level, the key point is the separation between Images (or snapshots) of the software and Transitions between these images. Both entities are explicitly represented in the system as first class objects, and are linked together to form the history graph. - An Image is defined as a filesystem tree structure containing a snapshot of a project at a certain point in time. Images are unique in the system, in the sense that if two images represent the same snapshot, then they are represented by the same object in Protego. Images are the vertices of the history graph. - A Transition is defined as a directed link between two images, thus they form the edges of the history graph. Different transitions can begin or end at any given image, for example transitions α and β in Figure 2(b) begin from the same image…”) [Examiner’s remarks: The data governance object, containing source and target data objects are saved to the versioning database. One of ordinary skill in the art may combine the database of Somani and the database of Gioachin to maintain all the claimed information.];
…
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Gioachin into the teachings of Somani to include “generating, by a data governance module operating on the server, a data governance object, wherein the data governance object comprises data lineage of the project, and where in the data lineage defines an association between the one or more target data objects, the one or more source data objects and the one or more updated component objects” and “each source data object, each target data object and the generated data governance object”. As stated in Gioachin, Protego provides “New schema to record projects’ history graphs; Collaborative environment with reduced need for explicit synchronization; In-memory storage of all the relevant information for higher performance” (Page 234). Introducing the saving of version data including data lineage of a project allows for better collaboration when a project is used by multiple people. Therefore, it would be obvious to one or ordinary skill in the art to combine saving various data lineage information with component updates.
Regarding claim 2, the rejection of claim 1 is incorporated; and Somani further discloses:
- wherein one or more of the one or more updated component objects are consumed by one or more other packages (Fig. 6; Paragraph [0040], “In reference to the example of FIGS. 5A and 5B, the validation environment 410 has published the new library A′ associated with the new checkpoint CP2 to the repository 404, with the new library A′ residing in the repository 404 with the previous version of the library A corresponding to the (previous checkpoint CP1. Thus, depending upon which checkpoint is being requested, the development environment 402 may download the older library A (if checkpoint CP1 is desired), or the most recent library A′ (if the new checkpoint CP2 is being requested) [wherein one or more of the one or more updated component objects are consumed by one or more other packages]”) [Examiner’s remarks: The updated component (most recent library) is consumed by the checkpoint as part of a project.]; and
- wherein each of the one or more other packages consume an older component version of the updated component objects (Fig. 6; Paragraph [0040], “In reference to the example of FIGS. 5A and 5B, the validation environment 410 has published the new library A′ associated with the new checkpoint CP2 to the repository 404, with the new library A′ residing in the repository 404 with the previous version of the library A corresponding to the (previous checkpoint CP1. Thus, depending upon which checkpoint is being requested, the development environment 402 may download the older library A (if checkpoint CP1 is desired), or the most recent library A′ (if the new checkpoint CP2 is being requested) [wherein each of the one or more other packages consume an older component version of the updated component objects]”) [Examiner’s remarks: The older component (older library) may be consumed by the checkpoint as part of a project.].
Regarding claim 3, the rejection of claim 2 is incorporated; and Somani further discloses:
- wherein one or more of the one or more other packages are updated to select, for consumption, the new component version of the one or more updated component objects (Paragraph [0037], “In one embodiment, the validation environment 410 may perform a build for each of multiple projects if the modified source code A1.src (MOD), A2.src (MOD) affects multiple projects, as indicated by the dependency metadata 418”; Paragraph [0041], “Since multiple projects or applications may be serviced via the same binary repository 404, at least some of the libraries 414 of the repository 404 may be employed in more than one project [wherein one or more of the one or more other packages are updated to select, for consumption, the new component version of the one or more updated component objects]”) [Examiner’s remarks: Other packages (projects) may be updated and tested on the modified version of an existing object.].
Regarding claim 4, the rejection of claim 3 is incorporated; and Somani further discloses:
- wherein the new versions of the one or more updated component objects have not been validated against one or more of the one or more other packages (Paragraph [0037], “The validation environment 410 may then build the project by compiling the modified source files A1.src (MOD), A2.src (MOD) and linking them with the binary libraries B, C associated with the checkpoint CP1 (operation 508)…In one embodiment, the validation environment 410 may perform a build for each of multiple projects if the modified source code A1.src (MOD), A2.src (MOD) affects multiple projects, as indicated by the dependency metadata 418 [wherein the new versions of the one or more updated component objects have not been validated against one or more of the one or more other packages]”) [Examiner’s remarks: The new version of the component may be compared to the other packages included, but the validation does not have to run for those packages. In this case, the new version would not be tested against the other packages.].
Regarding claim 5, the rejection of claim 1 is incorporated; and Somani further discloses:
- wherein, a usage metric is tracked for each of the one or more component objects, wherein the usage metric comprises usage information for each of the one or more component versions of the corresponding component object (Paragraph [0023], “Communicatively coupled with the development environment 302 is a dependency metadata system 308 configured to maintain dependency metadata 318, or to at least provide access thereto. 111 one embodiment, the dependency metadata 318 includes information that determines which code elements, such as source files and binary libraries, are to be included for a particular project or application, which source files are to be compiled before linking, and the like [wherein, a usage metric is tracked for each of the one or more component objects, wherein the usage metric comprises usage information for each of the one or more component versions of the corresponding component object]”) [Examiner’s remarks: Information regarding code elements, source code, and linking information is tracked, which is usage information as it describes how a component is used.].
Regarding claim 6, the rejection of claim 1 is incorporated; and Somani further discloses:
- wherein the new component version of one or more of the updated component objects is executed by the requesting user (Paragraph [0017], “Each library 114 is a compiled binary representation of some portion of the source code 116, wherein each library 114 may be linked with other libraries 114 and/or other binary code to form an executable software image that may be loaded onto a computer or other processing system for execution”; Paragraph [0018], “Upon receiving the modified source code (operation 210), the development environment 102 (or another system not specifically shown in FIG. 1) may compile the modified source code to produce compiled modified code (operation 212) and build a revised version of the software project using the compiled modified code and the plurality of libraries 114 (operation 214)”; Paragraph [0022], “The writing or modification may be based on instructions received from a user 320, such as a software developer. The source code may then be compiled to generate one or more binary files that may be linked or combined with other binary files to produce or build a desired application or program [wherein the new component version of one or more of the updated component objects is executed by the requesting user]”) [Examiner’s remarks: The user that requests and performs the modification may then run the modified software after the update is completed.].
Claims 10 and 14-17 are rejected under 35 U.S.C. 103 as being unpatentable over US 20120324417 A1 (hereinafter “Somani”), in view of “Protego: In-Memory Version Control System in the Cloud” by Gioachin et. al (hereinafter “Gioachin”), further in view of US 20090083268 A1 (hereinafter “Coqueret”).
Regarding claim 10, the rejection of claim 6 is incorporated; and the combination of Somani and Gioachin does not explicitly disclose:
wherein, for any data bucket run by the user, the user selects a source data object to be run, and wherein the selection comprises:
- selecting, through a user interface, an interface element corresponding to the source data object to be run; or specifying, via code, the source data object to be run.
However, Coqueret discloses:
wherein, for any data bucket run by the user, the user selects a source data object to be run, and wherein the selection comprises (Paragraph [0096], “In some embodiments the developer can select a variant by using a graphical user interface tool, an editor or a wizard, as illustrated by block 352 [wherein, for any data bucket run by the user, the user selects a source data object to be run, and wherein the selection comprises]”):
- selecting, through a user interface, an interface element corresponding to the source data object to be run; or specifying, via code, the source data object to be run (Paragraph [0096], “In some embodiments the developer can select a variant by using a graphical user interface tool, an editor or a wizard, as illustrated by block 352. The developer can request and view keywords, functional definitions and possibly a code snippet in a tree format based on the display contents described above. The developer can then choose a variant and indicate that the developer wants to proceed to plug the variant into a particular variability point [selecting, through a user interface, an interface element corresponding to the source data object to be run; or specifying, via code, the source data object to be run]”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Coqueret into the combined teachings of Somani and Gioachin to include “wherein, for any data bucket run by the user, the user selects a source data object to be run, and wherein the selection comprises” and “selecting, through a user interface, an interface element corresponding to the source data object to be run; or specifying, via code, the source data object to be run”. As stated in Coqueret, “Variants are very useful. For example, a variant can be implemented merely to make a system compliant to a technical standard. In other examples, a variant can be a very efficient implementation of a process that runs on a specific platform and another variant can be a very efficient implementation but on another specialized platform” (paragraph [0008]). Allowing for easy ways to access a variant for use allows for better collaboration, code reuse, and code adaptability to new systems. Therefore, it would be obvious to one or ordinary skill in the art to combine a versioning database for code objects with the ability to select variants using a GUI or code.
Regarding claim 14, Somani discloses:
A system for comprehensively tracking and versioning code and data in a collaborative development environment, the system comprising (Fig. 7):
a server, comprising a processing unit, memory and a non-transitory computer readable medium, wherein the memory and non-transitory computer readable medium store instructions, executed by the processing unit, for performing steps of a method, the method comprising (Fig. 7):
- generating, one or more code objects, wherein each code object comprises one or more code versions (Paragraph [0026], “Generally, the source control system 306 tracks and controls changes to the source code 316 made by multiple users 320. In some embodiments, the source control system 306 may be referred to as aversion control system (VCS) or a revision control system (RCS)…In one example, the source control system 306 maintains older versions of each source file so that the user 320 may return to an older version of one or more of the source files to eliminate errors introduced into the application by a more recent modification to the source code 316 [generating, one or more code objects, wherein each code object comprises one or more code versions]”) [Examiner’s remarks: One or more code objects are created by one of multiple users and maintained by a VCS.];
…
storing, in a versioning database, the generated one or more code objects (Paragraph [0026], “After the desired modifications are made, the user 320 may then “check in” the modified source code to allow other users to access the modified source code. In one example, the source control system 306 maintains older versions of each source file so that the user 320 may return to an older version of one or more of the source files to eliminate errors introduced into the application by a more recent modification to the source code 316 [saving, to a versioning database, each updated component object]”)…
executing, on the server, the collaborative development environment, wherein the collaborative development environment is configured for (Paragraph [0004], “To allow the software developers to generate their specific portions of the project concurrently, each member of the development team often possesses access to an integrated development environment (IDE) to facilitate the development and testing tasks”; Paragraph [0057], “FIG. 7 is a block diagram of a machine in the example form of a computer system 700 within which instructions for causing the machine to perform any one or more of the methodologies discussed herein may be executed. In alternative embodiments, the machine operates as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine may operate in the capacity of a server or a client machine in a server-client network environment [executing, on the server, the collaborative development environment, wherein the collaborative development environment is configured for]”):
…
Somani does not explicitly disclose:
…
generating, one or more data buckets, wherein each data bucket comprises one or more source data objects and one or more target data objects, wherein each target data object comprises a data lineage and a dependency tree, and wherein the data lineage and the dependency tree of each target data object comprises information corresponding to a code version of each code object and each source data object used to generate each respective target data object;
… and the one or more data buckets; and
receiving, from a user, a selection of two or more source data objects;
…
identifying, between the two or more selected target data objects, a magnitude of impact for each selected target data object; and
generating, in a user interface displayed to the user, a visual representation of the identified changes and the identified magnitude of impact.
However, Gioachin discloses:
- generating, one or more data buckets, wherein each data bucket comprises one or more source data objects and one or more target data objects, wherein each target data object comprises a data lineage and a dependency tree, and wherein the data lineage and the dependency tree of each target data object comprises information corresponding to a code version of each code object and each source data object used to generate each respective target data object (Pages 234-235, “At the lower level, the key point is the separation between Images (or snapshots) of the software and Transitions between these images. Both entities are explicitly represented in the system as first class objects, and are linked together to form the history graph. - An Image is defined as a filesystem tree structure containing a snapshot of a project at a certain point in time. Images are unique in the system, in the sense that if two images represent the same snapshot, then they are represented by the same object in Protego. Images are the vertices of the history graph. - A Transition is defined as a directed link between two images, thus they form the edges of the history graph. Different transitions can begin or end at any given image, for example transitions α and β in Figure 2(b) begin from the same image…”; Page 235, “In the figure, another edge appears between A and I, named ω. This edge represents the fact that the development of the software between A and I is the implementation of a new feature”) [Examiner’s remarks: Each history graph contains images (data objects) which represent the filesystem tree structure of a data object. Each data objects represents a different code version (i.e. before or after a new feature is added) and contains information about how each object was generated via the transitions.];
… and the one or more data buckets (Abstract, “Moreover, the cloud computational power can be leveraged to provide a higher degree of automation. In this paper, we describe Protego, a cloud-based version control system targeting flexibility and automation”; Page 234, “The main advantages of our schema are 1) the possibility to maintain different histories of a project within the same repository, 2) a new access control engine integrated with the revision data, and 3) the possibility for multiple users to work on the same repository simultaneously”; Pages 234-235, “At the lower level, the key point is the separation between Images (or snapshots) of the software and Transitions between these images. Both entities are explicitly represented in the system as first class objects, and are linked together to form the history graph. - An Image is defined as a filesystem tree structure containing a snapshot of a project at a certain point in time. Images are unique in the system, in the sense that if two images represent the same snapshot, then they are represented by the same object in Protego. Images are the vertices of the history graph. - A Transition is defined as a directed link between two images, thus they form the edges of the history graph. Different transitions can begin or end at any given image, for example transitions α and β in Figure 2(b) begin from the same image…”) [Examiner’s remarks: each of the data objects are saved to a VCS system.]; and
…
identifying, between the two or more selected target data objects, changes to the one or more code objects used to generate said selected target data objects and changes to the one or more target data objects (Pages 234-235, “At the lower level, the key point is the separation between Images (or snapshots) of the software and Transitions between these images. Both entities are explicitly represented in the system as first class objects, and are linked together to form the history graph. - An Image is defined as a filesystem tree structure containing a snapshot of a project at a certain point in time. Images are unique in the system, in the sense that if two images represent the same snapshot, then they are represented by the same object in Protego. Images are the vertices of the history graph. - A Transition is defined as a directed link between two images, thus they form the edges of the history graph. Different transitions can begin or end at any given image, for example transitions α and β in Figure 2(b) begin from the same image…”; Page 235, “In the figure, another edge appears between A and I, named ω. This edge represents the fact that the development of the software between A and I is the implementation of a new feature”) [Examiner’s remarks: The difference between two selected data objects may be found through the transitions of the graph, which describe changes to the source code generating the data object (e.g. an implementation of a new function.];
…
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Gioachin into the teachings of Somani to include “generating, one or more data buckets, wherein each data bucket comprises one or more source data objects and one or more target data objects, wherein each target data object comprises a data lineage and a dependency tree, and wherein the data lineage and the dependency tree of each target data object comprises information corresponding to a code version of each code object and each source data object used to generate each respective target data object”, “… and the one or more data buckets”, and “identifying, between the two or more selected target data objects, changes to the one or more code objects used to generate said selected target data objects and changes to the one or more target data objects”. As stated in Gioachin, Protego provides “New schema to record projects’ history graphs; Collaborative environment with reduced need for explicit synchronization; In-memory storage of all the relevant information for higher performance” (Page 234). Introducing the saving of version data including data lineage of a project allows for better collaboration when a project is used by multiple people. Therefore, it would be obvious to one or ordinary skill in the art to combine saving various data lineage information with component updates.
Gioachin discloses storage and of changes between two data objects (Pages 234-235, “At the lower level, the key point is the separation between Images (or snapshots) of the software and Transitions between these images. Both entities are explicitly represented in the system as first class objects, and are linked together to form the history graph. - An Image is defined as a filesystem tree structure containing a snapshot of a project at a certain point in time. Images are unique in the system, in the sense that if two images represent the same snapshot, then they are represented by the same object in Protego. Images are the vertices of the history graph. - A Transition is defined as a directed link between two images, thus they form the edges of the history graph. Different transitions can begin or end at any given image, for example transitions α and β in Figure 2(b) begin from the same image…”; Page 235, “In the figure, another edge appears between A and I, named ω. This edge represents the fact that the development of the software between A and I is the implementation of a new feature”). The combination of Somani and Gioachin does not explicitly disclose:
receiving, from a user, a selection of two or more source data objects;
…
identifying, between the two or more selected target data objects, a magnitude of impact for each selected target data object; and
generating, in a user interface displayed to the user, a visual representation of the identified changes and the identified magnitude of impact.
However, Coqueret discloses:
receiving, from a user, a selection of two or more source [file] (Paragraph [0060], “It can be appreciated that the developer can manipulate file content with a traditional editor, a graphical user interface or a domain user interface before submitting the modification to the version control system 120 in the branch with block 115.”; Paragraph [0056], “The first variant revision of the versioned file may have no variant content, and the second variant revision may have variant content. In such a configuration, the variant content can be defined as the difference between the two file versions or variant revisions of the versioned file contents. It can be appreciated that a developer can view, select and compare any number of revisions of a versioned file and determine the differences and index and/or codify the changes” [receiving, from a user, a selection of two or more source [file]]) [Examiner’s remarks: The user may select, using a GUI, two or more versions of a file (compare any number of revisions) of a given code or data object. One of ordinary skill in the art understands that a generic file may be replaced with a data object file as taught by Gioachin to achieve the selection as described by the claims.];
…
identifying, between the two or more selected target [file], a magnitude of impact for each selected target [file] (Paragraph [0056], “The first variant revision of the versioned file may have no variant content, and the second variant revision may have variant content. In such a configuration, the variant content can be defined as the difference between the two file versions or variant revisions of the versioned file contents. It can be appreciated that a developer can view, select and compare any number of revisions of a versioned file and determine the differences and index and/or codify the changes. When there are more than two revisions to compare (and to codify variants), the variant content can have more than one difference [identifying, between the two or more selected data versions or the two or more selected code versions]”; Paragraph [0094], “A code snippet illustrating a point of difference, or specific functionality could also be displayed to a developer to illuminate a specific variant trait [identifying, between the two or more selected target [file], a magnitude of impact for each selected target [file]]”) [Examiner’s remarks: For each file variant, the magnitude of impact (code snippet illustrating a point of difference) is identified. One of ordinary skill in the art understands that a generic file may be replaced with a data object file as taught by Gioachin to achieve the impact analysis as described by the claims.]; and
generating, in a user interface displayed to the user, a visual representation of the identified changes and the identified magnitude of impact (Paragraph [0056], “The first variant revision of the versioned file may have no variant content, and the second variant revision may have variant content. In such a configuration, the variant content can be defined as the difference between the two file versions or variant revisions of the versioned file contents. It can be appreciated that a developer can view, select and compare any number of revisions of a versioned file and determine the differences and index and/or codify the changes. When there are more than two revisions to compare (and to codify variants), the variant content can have more than one”; Paragraph [0094], “The changes can be displayed via the development tool, an editor or a wizard, possibly in a tree configuration, as illustrated by block 348. A code snippet illustrating a point of difference, or specific functionality could also be displayed to a developer to illuminate a specific variant trait”) [Examiner’s remarks: Identified changes and impact are displayed to user.].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Coqueret into the combined teachings of Somani and Gioachin to include “receiving, from a user, a selection of two or more source data objects”, “identifying, between the two or more selected target data objects, a magnitude of impact for each selected target data object”, and “generating, in a user interface displayed to the user, a visual representation of the identified changes and the identified magnitude of impact.”. As stated in Coqueret, “Variants are very useful. For example, a variant can be implemented merely to make a system compliant to a technical standard. In other examples, a variant can be a very efficient implementation of a process that runs on a specific platform and another variant can be a very efficient implementation but on another specialized platform” (paragraph [0008]). Having a method of tracking differences and functions of existing variants, as well as categorizing new ones, allows for better collaboration, code reuse, and code adaptability to new systems. Therefore, it would be obvious to one or ordinary skill in the art to combine a versioning database for code objects with the ability to automatically evaluate variant differences.
Regarding claim 15, the rejection of claim 14 is incorporated; and Somani further discloses:
- wherein, a usage metric is tracked for each of the one or more data buckets, wherein the usage metric comprises usage information for each of the one or more source data versions of the corresponding data bucket (Paragraph [0023], “Communicatively coupled with the development environment 302 is a dependency metadata system 308 configured to maintain dependency metadata 318, or to at least provide access thereto. 111 one embodiment, the dependency metadata 318 includes information that determines which code elements, such as source files and binary libraries, are to be included for a particular project or application, which source files are to be compiled before linking, and the like [wherein, a usage metric is tracked for each of the one or more data buckets, wherein the usage metric comprises usage information for each of the one or more source data versions of the corresponding data bucket]”) [Examiner’s remarks: Data is tracked for usage information of each data object, including the files and libraries needed to use the object.].
Regarding claim 16, the rejection of claim 15 is incorporated; and the combination of Somani and Gioachin does not explicitly disclose:
- wherein, for any data bucket run by the user, the user selects a source data object to be run, and wherein the selection comprises: selecting, through the user interface, an interface element corresponding to the source data object to be run; or specifying, via code, the source data object to be run.
However, Coqueret discloses:
- wherein, for any data bucket run by the user, the user selects a source data object to be run, and wherein the selection comprises: selecting, through the user interface, an interface element corresponding to the source data object to be run; or specifying, via code, the source data object to be run (Paragraph [0096], “In some embodiments the developer can select a variant by using a graphical user interface tool, an editor or a wizard, as illustrated by block 352. The developer can request and view keywords, functional definitions and possibly a code snippet in a tree format based on the display contents described above. The developer can then choose a variant and indicate that the developer wants to proceed to plug the variant into a particular variability point [wherein, for any data bucket run by the user, the user selects a source data object to be run, and wherein the selection comprises: selecting, through the user interface, an interface element corresponding to the source data object to be run; or specifying, via code, the source data object to be run]”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Coqueret into the combined teachings of Somani and Gioachin to include “wherein, for any data bucket run by the user, the user selects a source data object to be run, and wherein the selection comprises: selecting, through the user interface, an interface element corresponding to the source data object to be run; or specifying, via code, the source data object to be run”. As stated in Coqueret, “Variants are very useful. For example, a variant can be implemented merely to make a system compliant to a technical standard. In other examples, a variant can be a very efficient implementation of a process that runs on a specific platform and another variant can be a very efficient implementation but on another specialized platform” (paragraph [0008]). Allowing for easy ways to access a variant for use allows for better collaboration, code reuse, and code adaptability to new systems. Therefore, it would be obvious to one or ordinary skill in the art to combine a versioning database for code objects with the ability to select variants using a GUI or code.
Regarding claim 17, the rejection of claim 16 is incorporated; and Somani discloses:
- wherein, when a new source data object of a data bucket or a new code object is selected by the user, one or more pieces of code are identified as needing to be re-run based on a dependency tree of a new target data object (Paragraph [0023], “111 one embodiment, the dependency metadata 318 includes information that determines which code elements, such as source files and binary libraries, are to be included for a particular project or application, which source files are to be compiled before linking, and the like. In another example, the dependent metadata 318 may also include information regarding which versions of each library or source file should be included in a build to form a particular version of the application”; Paragraph [0024], “In one embodiment, the dependency metadata 318 may include information useful for “pre-build” activities (such as, for example, checking for the presence of all libraries and source files to be included for the build, verifying the correct versions of such files, converting source files from one language to another before compilation, and checking for a sufficient amount of data storage space in which to perform the build), and “post-build” activities (for example, checking of the resulting application to ensure that the correct version was built, and running of one or more verification tests on the application)”; Paragraph [0039], “Also, the validation environment 410 may also publish new dependency metadata 418 and the new checkpoint CP2 to the dependency metadata system 408. In one example, the validation environment 410 may also inform the developer via the development environment 402 that the tests were successful, and that the new checkpoint CP2 was generated.” [wherein, when a new source data object of a data bucket or a new code object is selected by the user, one or more pieces of code are identified as needing to be re-run based on a dependency tree of a new target data object]) [Examiner’s remarks: Somani discloses using the metadata which includes dependencies to check that all the necessary libraries for build are present, and re-running or changing files that are not in the correct state. The metadata storage contains information about the necessary files to run a new version, and upon selection of a new version, the relevant dependent files may be re-run.].
The combination of Somani and Gioachin does not explicitly disclose:
- wherein, each source data object of a data bucket and each code version of a code object is selectable, by the user, for consumption; and
However, Coqueret discloses:
- wherein, each source data object of a data bucket and each code version of a code object is selectable, by the user, for consumption (Paragraph [0096]“The variants can be displayed in a file tree format organized by one or more variability points. The system can display a portion of code portion that is associated with the variant in response to a developer selecting a variant via a tree format [wherein, each source data object of a data bucket and each code version of a code object is selectable, by the user, for consumption]”); and
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Coqueret into the combined teachings of Somani and Gioachin to include “wherein, each source data object of a data bucket and each code version of a code object is selectable, by the user, for consumption”. As stated in Coqueret, “Variants are very useful. For example, a variant can be implemented merely to make a system compliant to a technical standard. In other examples, a variant can be a very efficient implementation of a process that runs on a specific platform and another variant can be a very efficient implementation but on another specialized platform” (paragraph [0008]). Allowing for easy ways to access a variant for use allows for better collaboration, code reuse, and code adaptability to new systems. Therefore, it would be obvious to one or ordinary skill in the art to combine a versioning database for code with the ability to select said code for consumption.
Claims 13 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over US 20120324417 A1 (hereinafter “Somani”), in view of “Protego: In-Memory Version Control System in the Cloud” by Gioachin et. al (hereinafter “Gioachin”), further in view of US 20090083268 A1 (hereinafter “Coqueret”), further in view of US 20190042231 A1 (hereinafter “Kolhe”).
Regarding claim 13, the rejection of claim 10 is incorporated; and the combination of Somani, Gioachin, and Coqueret does not explicitly disclose:
- statistics including an identity of one or more consuming users;
- frequency of consumption;
- acceptance or rejection by users; and
- notes corresponding to the acceptance or rejection by users.
However, Kolhe discloses:
- statistics including an identity of one or more consuming users (Paragraph [0061], “The notification may be sent to user(s) who own or are otherwise associated with the application, and may be sent using any suitable communications channel [statistics including an identity of one or more consuming users]”) [Examiner’s remarks: A notification is sent out to users who are associated and use the application, which means statistics regarding who uses the component are tracked.];
- frequency of consumption (Paragraph [0034], “For example, the platform may collect statistics regarding how often component(s) have been used in applications (e.g., adoption frequency), information regarding performance and/or issues with the component(s), and so forth [frequency of consumption]”);
- acceptance/rejection by users (Paragraph [0045], “The versioning engine manages the component versions, and also maintains usage statistics for the various versions of the components (e.g., usage frequency, adoption frequency, etc.). In some instances, the versioning engine also manages the receipt and recording of issues (e.g., bugs) reported for various versions of the various components [acceptance or rejection by users]”); and
- notes corresponding to the acceptance/rejection by users (Paragraph [0045], “The versioning engine manages the component versions, and also maintains usage statistics for the various versions of the components (e.g., usage frequency, adoption frequency, etc.). In some instances, the versioning engine also manages the receipt and recording of issues (e.g., bugs) reported for various versions of the various components [notes corresponding to the acceptance or rejection by users]”) [Examiner’s remarks: Notes may include bug reports.].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Kolhe into the combined teachings of Somani, Gioachin, and Coqueret to include “statistics including an identity of one or more consuming users”, “frequency of consumption”, “acceptance or rejection by users”, and “notes corresponding to the acceptance or rejection by users”. As stated in Kolhe, “implementations of the present disclosure are directed to a platform that provides software components that can be incorporated into applications, receives updated versions of the components, and manages the evolution of component versions to facilitate rapid development of quality-controlled applications that include the managed components” (paragraph [0003]). Statistics regarding users and user feedback allows for more efficient sharing of information regarding code, which can lead to fewer compatibility issues and more code sharing. Therefore, it would be obvious to one or ordinary skill in the art to combine versioning databases with tracking component statistics.
Regarding claim 18, the rejection of claim 17 is incorporated; and the combination of Somani, Gioachin, and Coqueret does not explicitly disclose:
- statistics including an identity of one or more consuming users;
- frequency of consumption;
- acceptance or rejection by users; and
- notes corresponding to the acceptance or rejection by users.
However, Kolhe discloses:
- statistics including an identity of one or more consuming users (Paragraph [0061], “The notification may be sent to user(s) who own or are otherwise associated with the application, and may be sent using any suitable communications channel [statistics including an identity of one or more consuming users]”) [Examiner’s remarks: A notification is sent out to users who are associated and use the application, which means statistics regarding who uses the component are tracked.];
- frequency of consumption (Paragraph [0034], “For example, the platform may collect statistics regarding how often component(s) have been used in applications (e.g., adoption frequency), information regarding performance and/or issues with the component(s), and so forth [frequency of consumption]”);
- acceptance or rejection by users (Paragraph [0045], “The versioning engine manages the component versions, and also maintains usage statistics for the various versions of the components (e.g., usage frequency, adoption frequency, etc.). In some instances, the versioning engine also manages the receipt and recording of issues (e.g., bugs) reported for various versions of the various components [acceptance/rejection by users]”); and
- notes corresponding to the acceptance or rejection by users (Paragraph [0045], “The versioning engine manages the component versions, and also maintains usage statistics for the various versions of the components (e.g., usage frequency, adoption frequency, etc.). In some instances, the versioning engine also manages the receipt and recording of issues (e.g., bugs) reported for various versions of the various components [notes corresponding to the acceptance/rejection by users]”) [Examiner’s remarks: Notes may include bug reports.].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Kolhe into the combined teachings of Somani, Gioachin, and Coqueret to include “statistics including an identity of one or more consuming users”, “frequency of consumption”, “acceptance or rejection by users”, and “notes corresponding to the acceptance or rejection by users”. As stated in Kolhe, “implementations of the present disclosure are directed to a platform that provides software components that can be incorporated into applications, receives updated versions of the components, and manages the evolution of component versions to facilitate rapid development of quality-controlled applications that include the managed components” (paragraph [0003]). Statistics regarding users and user feedback allows for more efficient sharing of information regarding code, which can lead to fewer compatibility issues and more code sharing. Therefore, it would be obvious to one or ordinary skill in the art to combine versioning databases with tracking component statistics.
Response to Arguments
Applicant’s arguments with respect to claims 1-6, 10, and 13-18 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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 nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VIVIAN WEIJIA DUAN whose telephone number is (703)756-5442. The examiner can normally be reached Monday-Friday 8:30AM-5PM.
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, Wei Y Mui can be reached at (571) 272-3708. 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.
/V.W.D./Examiner, Art Unit 2191 /WEI Y MUI/Supervisory Patent Examiner, Art Unit 2191