DETAILED ACTION
Claims 1-18 are presented for examination.
Claims 1, 2, 4-6, and 8-17 have been amended.
Claims 18 have been added.
This office action is in response to the amendment submitted on 06-JUL-2026.
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 .
Examiner’s Note (EN)
The prior art rejections below cite particular paragraphs, columns, and/or line numbers in the references for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art.
Response to Arguments – 35 USC 101
On pgs. 10-12 of the Applicant/Arguments Remarks, Applicant argues the amended claims have overcome the rejection under 35 USC 101. Examiner respectfully disagrees.
On pg. 10, the applicant argues the invention is integrated into a practical application.
The examiner disagrees. The invention as recited in the claims amounts to nothing more than what a human can do with the aid of a pen and paper except it is being done with the aid of a computer.
Limitations that invoke a computer as a tool to perform an abstract idea fall within the “apply it” category. See MPEP 2106.04(d) referencing MPEP 2106.05(f)(2) — example (i) A commonplace business method or mathematical algorithm being applied on a general purpose computer. Similar to applying a mathematical algorithm on a general purpose computer, performing specific mathematical calculations or mental processes on a general purpose computer is using a computer as a tool to perform an abstract idea. As noted in the cases referenced by MPEP 2106.05(f), when the additional elements are mere instructions to apply the abstract idea on a general purpose computer, the additional elements do not integrate the judicial exception into a practical application. If the claim as a whole integrates the recited judicial exception into a practical application, then it would be patent eligible. Here, the claim is generally linked to the technology generating source code based build packages, but, as drafted, the claim only refers the general act of identifying and combining dependencies, which is generally linking the use of the judicial exception to a particular field of use. See MPEP 2106.04(d) referencing 2106.05(h).
Additionally as recited in the MPEP 2106.05(f): Another consideration when determining whether a claim integrates a judicial exception into a practical application in Step 2A Prong Two or recites significantly more than a judicial exception in Step 2B is whether the additional elements amount to more than a recitation of the words "apply it" (or an equivalent) or are more than mere instructions to implement an abstract idea or other exception on a computer. As explained by the Supreme Court, in order to make a claim directed to a judicial exception patent-eligible, the additional element or combination of elements must do "‘more than simply stat[e] the [judicial exception] while adding the words ‘apply it’". Alice Corp. v. CLS Bank, 573 U.S. 208, 221, 110 USPQ2d 1976, 1982-83 (2014) (quoting Mayo Collaborative Servs. V. Prometheus Labs., Inc., 566 U.S. 66, 72, 101 USPQ2d 1961, 1965). Thus, for example, claims that amount to nothing more than an instruction to apply the abstract idea using a generic computer do not render an abstract idea eligible. Alice Corp., 573 U.S. at 223, 110 USPQ2d at 1983. See also 573 U.S. at 224, 110 USPQ2d at 1984 (warning against a § 101 analysis that turns on "the draftsman’s art").
On pg. 11, the applicant argues that generating the two more packages can’t be performed by the human mind.
The examiner disagrees. The human mind is capable of mentally evaluating dependencies between code sources and deciding which to package together, ‘generate package’. The instant specification does not define the package generation in any way that precludes the human mind from performing the generation. See instant specification paragraphs [0033-0035].
Additionally, the applicant argues the invention is an improvement to the technology or technical field.
Examiner disagrees that the improvement is to a technological improvement. A proper statement of the rule as given by Enfish: For that reason, the first step in the Alice inquiry in this case asks whether the focus of the claims is on the specific asserted improvement in computer capabilities or, instead, on a process that qualifies as an "abstract idea" for which computers are invoked merely as a tool. (see Enfish, LLC v. Microsoft Corp., 822 F.3d 1327, 1336 (Fed. Cir. 2016)).
The Court’s analysis of the claim hinged on the “self-referential table” limitation being an improvement over the conventional technology and not invoking the computer as a tool.
In our instant application, the limitations are directed to gathering data about source code changes, evaluating dependencies, deciding on build patterns and generating packages. Without a technical definition of ‘generating’ the packages that preclude the act from being performed in the human mind, under BRI this can all be performed mentally by a human. The claimed improvement is an improvement on the mental process, but invokes a computer as a tool to perform the mental process. It is important to note, the judicial exception alone cannot provide the improvement (see MPEP 2106.05(a) paragraph 6).
MPEP 2106.05(a) further states: To show that the involvement of a computer assists in improving the technology, the claims must recite the details regarding how a computer aids the method, the extent to which the computer aids the method, or the significance of a computer to the performance of the method. Merely adding generic computer components to perform the method is not sufficient. Thus, the claim must include more than mere instructions to perform the method on a generic component or machinery to qualify as an improvement to an existing technology. See MPEP § 2106.05(f) for more information about mere instructions to apply an exception.
Response to Arguments – 35 USC 103
Applicant’s arguments with respect to the 103 rejections have been considered, but are not persuasive.
The applicant argues the newly amended limitations overcome the teachings of Iwanir in view of Lin in so far that they operates on code changes instead of buildable units, it groups the pieces of change information linked by the synchronous element and it’s done before the execution of the build.
The new limitations are mapped below in the 35 USC 103 rejection. Primarily, Lin does teach that buildable units are comprised of source code files, that dependencies between the source code files are established, and subsequently combined and tested before the actual build. Please see the mappings below [0022-0024], [0027] showing the code source comprising the buildable unit, as well as Lin’s abstract, “At the computer device, dependent buildable units are identified that have a dependency relationship with the buildable unit for execution. The authored source code of the buildable unit is then validated to determine that the buildable unit executes with the dependent buildable units for error-free execution before the buildable unit is subsequently provided to a software build service that compiles the multiple buildable units to generate the software build project.”
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-7 and 17 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claim 1
Step 1: Statutory class – method.
Step 2A Prong One: Does the claim recite an abstract idea, law of nature or natural phenomenon?
Yes
“3) Mental processes – concepts performed in the human mind (including an observation, evaluation, judgment, opinion) (see MPEP § 2106.04(a)(2), subsection III).” MPEP § 2106.04(a).
The claims are directed to an abstract idea of data processing and analysis. The claim recites:
generating two or more packages each including one or more pieces of the change information by grouping the pieces of the change information linked by the synchronous element
generating prior to executing a build of the plurality of changed source codes, an overall build pattern including all of the two or more packages and partial build patterns including some of the two or more packages
The generating limitations are limitations of mental processes of evaluation, judgement and organization. By way of example, one can mentally evaluate which code sources are related/synchronous and based on the relationship generate a build pattern that includes the source codes.
Step 2A Prong Two: Does the claim recite additional elements that integrate the judicial exception into a practical application?
No.
The additional elements are:
acquiring, for each of a plurality of changed source codes, change information including information indicating a first changed source code and synchronous element information indicating a synchronous element related between the first changed source code and a second changed source code the synchronous element indicating a change of the second changed source code upon which the first changed source code depends;
The acquiring is mere data collection. MPEP 2106.05(g)
Step 2B: Does the claim recite additional elements that amount to significantly more than judicial exception?
No, as discussed with respect to Step 2A, the additional limitation is mere data gathering. See MPEP 2106.05(d). MPEP 2106.05(f) provides the following considerations for determining whether a claim simply recites a judicial exception with the words “apply it” (or an equivalent), such as mere instructions to implement an abstract idea on a computer.
Additionally, the limitations do not impose any meaningful limits on practicing the abstract idea and therefore the claim does not provide an inventive concept in Step 2B. Further, in regards to step 2B and as cited above in step 2A, MPEP 2106.05(g) “Obtaining information about transactions using the Internet to verify credit card transactions, CyberSource v. Retail Decisions, Inc., 654 F.3d 1366, 1375, 99 USPQ2d 1690, 1694 (Fed. Cir.2011)” is merely data gathering. The additional elements have been considered both individually and as an ordered combination in the significantly more consideration. This claim is ineligible.
Claim 2 recites the information indicating the first changed source code includes at least one of the first changed source code, information indicating a content of change of the first changed source code, or information indicating an access destination of one of the first changed source code or the information indicating the content of the change, which is further specification to mere data collection, MPEP 2106.05(g) under Step 2A Prong Two and 2B.
The additional abstract idea and identified elements whether considered individually or in a
combination with the parent claims further do not amount to significantly more than the judicial
exception because the elements merely apply the abstract idea to be implemented on a generic
computer and therefore the identified claim does not amount to significantly more. See MPEP
2106.05(f). Therefore, the claim is considered ineligible under 35 USC 101. Therefore, the claim is
considered ineligible under 35 USC 101.
Claim 3 recites the change information includes synchronous element information defined by a user, which is further specification to mere data collection, MPEP 2106.05(g) under Step 2A Prong Two and 2B.
The additional abstract idea and identified elements whether considered individually or in a combination with the parent claims further do not amount to significantly more than the judicial exception because the elements merely apply the abstract idea to be implemented on a generic computer and therefore the identified claim does not amount to significantly more. See MPEP 2106.05(f). Therefore, the claim is considered ineligible under 35 USC 101. Therefore, the claim is considered ineligible under 35 USC 101.
Claim 4 recites t defining the synchronous element based on a reference destination to the second changed source code, which is further specification to mere data collection, MPEP 2106.05(g) under Step 2A Prong Two and 2B.
The additional abstract idea and identified elements whether considered individually or in a combination with the parent claims further do not amount to significantly more than the judicial exception because the elements merely apply the abstract idea to be implemented on a generic computer and therefore the identified claim does not amount to significantly more. See MPEP 2106.05(f). Therefore, the claim is considered ineligible under 35 USC 101. Therefore, the claim is considered ineligible under 35 USC 101.
Claim 5 recites the change information includes information indicating a development ticket giving an instruction on change of the first changed source code, and the method further comprises defining the synchronous element based on the information indicating the development ticket, which is further specification to mere data collection, MPEP 2106.05(g) under Step 2A Prong Two and 2B.
The additional abstract idea and identified elements whether considered individually or in a combination with the parent claims further do not amount to significantly more than the judicial exception because the elements merely apply the abstract idea to be implemented on a generic computer and therefore the identified claim does not amount to significantly more. See MPEP 2106.05(f). Therefore, the claim is considered ineligible under 35 USC 101. Therefore, the claim is considered ineligible under 35 USC 101.
Claim 6 recites the change information includes information indicating a development ticket giving an instruction on change of the first changed source code, and the method further comprises generating the partial build patterns based a build priority defined by the development ticket, which is further specification to mere data collection, MPEP 2106.05(g) under Step 2A Prong Two and 2B.
The additional abstract idea and identified elements whether considered individually or in a combination with the parent claims further do not amount to significantly more than the judicial exception because the elements merely apply the abstract idea to be implemented on a generic computer and therefore the identified claim does not amount to significantly more. See MPEP 2106.05(f). Therefore, the claim is considered ineligible under 35 USC 101. Therefore, the claim is considered ineligible under 35 USC 101.
Claim 7 recites the change information includes error information upon a past build, and the method further comprises generating the partial build patterns including two or more of the packages having caused an error in the past build, which is further specification to mere data collection, MPEP 2106.05(g) under Step 2A Prong Two and 2B.
The additional abstract idea and identified elements whether considered individually or in a combination with the parent claims further do not amount to significantly more than the judicial exception because the elements merely apply the abstract idea to be implemented on a generic computer and therefore the identified claim does not amount to significantly more. See MPEP 2106.05(f). Therefore, the claim is considered ineligible under 35 USC 101. Therefore, the claim is considered ineligible under 35 USC 101.
Claim 17 recites A computer program product including programmed instructions: (statutory category – product)
embodied in and stored on a non-transitory computer readable medium, wherein the instructions, when executed by a computer, cause the computer to perform, which is mere instructions to apply an exception on a generic computer under Step 2A Prong Two and 2B.
The remaining limitations are similar to claim 1 and are rejected under the same rationale. Therefore, the claim is considered ineligible under 35 USC 101.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-4, 7-11, 14, and 16-18 are rejected under 35 U.S.C. 103 as being unpatentable over Iwanir et al. (US20200264871A1) in view of Lin et al. (US20110239195A1)
Regarding Claim 1, Iwanir teaches a multi-pattern build evaluation method comprising: acquiring, for each of a plurality of changed source codes, change information including information indicating a first changed source code and synchronous element information indicating a synchronous element related between the first changed source code and a second changed source code ([0063] "For example, the first build request and the second build request of step 304 may be received by build queue 400. In the context of build queue 400 as illustrated in FIG. 4, the first build request may correspond to build request 404, and the second build request may correspond to build request 406, each of which are shown as pending in build queue 400. Queue optimizer logic 210 is configured to provide information associated with the received build requests, e.g., responsive to the criteria noted above, to risk factor logic 214 at step 504 of flow diagram 500 in FIG. 5. The provided information associated with a given, received build request may include, without limitation: an ID, a status, a developer name, a priority, a base commit of the change for a project, changed file types and/or the files themselves, an amount of code churn of the change for a project (e.g., how much is being changed or added), properties of changed or added content within a project (e.g., a directory or project portion in which the change is located), and/or the like." EN: a build request is generated after source codes are changed, [0005] " In one example, a computer-implemented method includes receiving a first build request for a build of a first code revision and a second build request for a build of a second code revision in a build queue associated with a code repository").
generating two or more packages each including one or more pieces of the change information ([0089-0090] "In step 808, the first code revision and the second code revision are committed to the code repository based on determining the build for the third build request completed successfully. For instance, as noted above in step 304 of flowchart 300 in FIG. 3, a first build request (i.e., build request 204) for a build of a first code revision and a second build request (i.e., build request 206) for a build of a second code revision are received in the build queue associated with code repository 220. In the context of request set 702, if it is determined that the build for request set 702, that includes build request 204 and build request 206, completes successfully, a build queue of build manager 208, e.g., build queue 400, build queue 700, and/or build queues 900, is configured to commit the revisions/additions in build request 204 and build request 206 to code repository 220, along with the revisions/additions in each other build request of request set 702. That is, if a build for a build request or a request set is completed successfully, project content associated with the build request or request set, e.g., source code, design code, media/multimedia, libraries, etc., is committed to code repository 220 by the build queues described herein, although other components of system 200 and/or build manager 208 may also, or alternatively, be configured to perform the commit of the revisions/additions to code repository 220.")
generating an overall build pattern including all of the two or more packages and partial build patterns including some of the two or more packages ([0102-0103] "In step 1102, the build requests in the request set are divided into approximately equal first and second groups, the first group comprising build requests with risk factor values that are less than risk factor values of build requests of the second group. In embodiments, subsequent to risk factor logic 214 dynamically updating risk factor values based on information from error handling logic 212, as described in step 1002, subset logic 216 is configured to recursively divide the request set, e.g., request set 702, into request subsets for subsequent processing until individual build requests remain. For request sets with an even number of build requests, the first and second groups may each have a number of build requests therein that is half of the number of build requests in the request set, while for request sets with an odd number of build requests, one of the first or second groups may include the remaining build request after two equal groups are generated.")
However Iwanir is not relied on for:
indicating a synchronous element
the synchronous element indicating a change of the second changed source code upon which the first changed source code depends;
by grouping the pieces of the change information linked by the synchronous element
prior to executing a build of the plurality of changed source codes,
Lin teaches indicating a synchronous element (Fig. 3, and [0005] "In other embodiments, source code metadata is generated at the computer devices that are local to each developer. The source code metadata identifies each instance of a file access as defined in the authored source code of a buildable unit. The source code metadata from each computer device is provided to the software build service that generates a relational graph of the buildable units that are associated based on the file accesses listed in the source code metadata. A dependency hierarchy can then be derived from the relational graph, and the dependency hierarchy identifies dependencies between the buildable units of the software build project." [0027] "A developer at the developer computer device 302 can author source code 312 as a buildable unit 314 of the software build project 308. The computer device 302 receives the authored source code 312 as inputs to the computer device, and the buildable unit 314 of the software build project 308 is developed. Dependent buildable units 316 are identified as buildable units that have a dependency relationship with the buildable unit 314 for execution. For example, the dependent buildable units 316 may be one or more child buildable units that are dependent on the buildable unit 314 for execution. Alternatively or in addition, the dependent buildable units 316 may be one or more parent buildable units from which the buildable unit 314 is dependent on for execution.")
the synchronous element indicating a change of the second changed source code upon which the first changed source code depends ([0028] “The developer computer device 302 may also include a dependence validation application 318 used to validate that the authored source code 312 of the buildable unit 314 executes with the dependent buildable units 316 for error-free execution before the buildable unit 314 is subsequently provided to the software build service 304 and compiled into the software build project 308. Timing breaks that may be caused by the buildable unit 314 can also be resolved locally at the computer device 302 when the authored source code 312 is validated before the buildable unit is provided to the software build service. Accordingly, a developer can author source code for a buildable unit, integrate only the dependent buildable units that are dependent on or depend from the buildable unit, and validate the source code and/or changes to the source code locally at the developer computer device 302 before the buildable unit is integrated with the software build project.”)
by grouping the pieces of the change information linked by the synchronous element ([0023-0024] “When the source code 220 is authored at the developer computer device 218, source code metadata 228 is also generated and can include file access metadata 230 that identifies each instance of a file access for the particular buildable unit 222. All of the file accesses developed in the authored source code 220 can be logged, such as in a trace file. The source code metadata 228 is then provided or uploaded from the developer computer device 218 to the software build service 202 and is saved as the file access metadata 214 when source code metadata is received from one or more of the developer computer devices 204. The software build service 202 can then generate a relational graph 232 of the buildable units 208 that are associated based on the file accesses listed in the file access metadata 214. The relational graph 232 is a representation of the software build project 206. Additionally, the software build service 202 can generate a dependency hierarchy 234 from the relational graph 232, and the dependency hierarchy 234 identifies dependencies between the buildable units 208 of the software build project. In various embodiments, the software build service 202 represents any techniques that may be implemented to support running a number ‘n’ invocations of the build project across a number ‘m’ build types and merging all of the ‘n:m’ permutations into a single large relational graph of the buildable units. The relational graph 232 from which the dependency hierarchy 234 is generated evolves as the multiple buildable units 208 are authored and received from the various developer computer devices 204, along with corresponding source code metadata for each buildable unit. The software build service 202 may also implement a build project compiler 236 to link and compile the software build project 206 based on the dependency hierarchy of the buildable units 208.”)
prior to executing a build of the plurality of changed source codes, ([0022] “The developer computer device 218 may also include a dependence validation application 226 used to validate that the authored source code 220 of the buildable unit 222 executes with the dependent buildable units 224 for error-free execution before the buildable unit 222 is subsequently provided or uploaded to the software build service 202 and compiled into the software build project 206. Timing breaks that may be caused by the buildable unit 222 can also be resolved locally at the computer device 218 when the authored source code 220 is validated before the buildable unit is provided to the software build service. Accordingly, a developer can author source code for a buildable unit, integrate only the dependent buildable units that are dependent on or depend from the buildable unit, and validate the source code and/or changes to the source code locally at the developer computer device 218 before the buildable unit is provided or uploaded for integration with the software build project.”)
Iwanir and Lin are analogous art because they are from the same field of endeavor in code execution profiling. Before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art, to combine Iwanir and Lin to incorporate Lin’s more explicit treatment of code dependencies into Iwanir’s build process with expected results. "The developers can face lengthy and complex challenges when compiling the thousands of source code files, particularly when changes are made to one source code file that may affect any number of other source code files and/or the dependencies. The impact of source code changes to other source code files is often difficult to determine and may cause unknown conditions and/or unexpected results and failures, such as timing breaks. The source code file dependencies typically dictate the sequence by which a large-scale software development project is built. However, these dependencies are not always apparent or even easily ascertainable, and are difficult to manage." (Lin, [0001] also see [0003])
Regarding Claim 2, Iwanir in view of Lin teaches the method of claim 1. Iwanir further teaches wherein the information indicating the first changed source code includes at least one of the first changed source code, information indicating a content of change of the first changed source code, or information indicating an access destination of one of the first changed source code or the information indicating the content of the change ([0063])
Regarding Claim 3, Iwanir in view of Lin teaches the method of claim 1. Lin further teaches wherein the change information includes synchronous element information defined by a user ([0005] “In other embodiments, source code metadata is generated at the computer devices that are local to each developer. The source code metadata identifies each instance of a file access as defined in the authored source code of a buildable unit. The source code metadata from each computer device is provided to the software build service that generates a relational graph of the buildable units that are associated based on the file accesses listed in the source code metadata. A dependency hierarchy can then be derived from the relational graph, and the dependency hierarchy identifies dependencies between the buildable units of the software build project.” EN: the source code metadata are defined by the user. Also see Iwanir [0040-0041] and [0082] )
Regarding Claim 4, Iwanir in view of Lin teaches the method of claim 1. Lin teaches further comprising defining the synchronous element based on a reference destination to the second changed source code ([0034-0035] "Conceptually, a build process to build a large-scale software project can be outlined as follows: a top level build processes starts; it reads and/or writes files; it generates a number of child processes; the child processes each read and/or write files, run other child processes, and then completes; and the top level build process finishes and is complete. The example architecture 400 includes a build tracer 406 that monitors the top level build processes as it executes. The build tracer 406 intercepts process and file system activities, and records them into a trace file….The example architecture 400 also includes a trace analyzer 408 that is implemented to obtain data from a build trace 410, such as the process tree rooted by the top level build process with an edge connecting a process to its parent process, and additional information about each process (e.g., PID, command line, directory) and file operations (e.g., file name, access mode, status). In an implementation, the build dependencies can be determined as follows: associate each process with the set of files it reads; associate each process with the set of files it writes to; and if a first process reads a file which is written by a second process, create a dependency edge to the second process. A first buildable unit is identified as depending on a second buildable unit if there is a child process associated with the first buildable unit which has a dependency edge to a child process associated with the second buildable unit.")
Regarding Claim 7, Iwanir in view of Lin teaches the method of claim 1. Iwanir teaches Wherein the change information includes error information upon a past build ([0150] "In an embodiment of the system, the risk factor instructions are configured to determine the risk factors based on values of one or more sub-factors including at least one of a build request priority, a base commit identifier for a code change, an identity of a code developer requestor for the first build request or the second build request, a file type of a changed file for the first build request or the second build request, an amount of code change in the first build request or the second build request, a frequency of change for code over a time period, a number of previously failed compilations associated with a code change, or a relationship between a changed file in the first build request and a changed file in the second build request." [0154] "In an embodiment of the system, the risk factor instructions are configured to dynamically update the risk factors associated with the build requests based on at least one of a number of pending build requests pending in the build queue, or optimizing information associated with an unsuccessful completion of a build for a request set determined by error handling instructions. In the embodiment, the subset instructions are configured to divide a request set into two request subsets with an approximately equal number of copies of build requests based at least on a dynamically updated risk factor and responsive to a build of the request set not successfully completing. In the embodiment, the queue optimizer instructions are further configured to insert the request subsets to the build queue.")
the method further comprises generating the partial build patterns including two or more of the packages having caused an error in the past build ([0148] "In an embodiment, the method further includes committing code revisions corresponding to the first request subset or the second request subset to the code repository based on determining a build for the first request subset or the second request subset, respectively, completed successfully, in the first request subset or the second request subset for which a build is not successfully completed, when a number of code revisions therein is more than one, dividing each of the first request subset or the second request subset into approximately equal sub-groups based on further updated risk factors of code revisions therein, and inserting the sub-groups at the head of the build queue." [0154] and [0157] "In an embodiment of the computer-readable storage medium, the one or more sub-factors comprise at least one of a build request priority, a base commit identifier for a code change, an identity of a requestor, a file type of a changed file, or an amount of code change, associated with a build request in the set, a frequency of change for code over a time period, a number of previously failed compilations associated with a code change, or a relationship between changed files in two build requests in the set.")
Regarding Claim 8, Iwanir in view of Lin teaches the method of claim 1. Iwanir teaches further comprising: executing the build of the plurality of changed source codes defined by the overall build pattern and the partial build patterns ([0145] "In an embodiment, the method further includes removing each of the number of build requests, that are pending, having a corresponding copy in the request set from the build queue based at least on said determining that the build for the separate build request completed successfully." EN: The build queue is cleared when it’s executed successfully)
adopting a build result of the overall build pattern when a build of the overall build pattern is successfully executed ([0145] EN: when the build request as a whole is successful it's removed from the queue. Otherwise, it's further broken down into sub requests)
adopting a build result from one or more partial build patterns, for which builds are successfully executed, when the build of the overall build pattern results in failure ([0146] "In an embodiment of the method, the copy of the one or more build requests includes at least two copies that are included in the request set, and each of the number of build requests remain in the build queue individually, and the method further includes determining a build for the separate build request was not completed successfully, removing the separate build request from the build queue, generating a first request subset including less than all copies of build requests in the request set based on an updated risk factor, generating a second request subset including any remaining copies of build requests in the request set that are not included in the first request subset, and providing the first request subset and the second request subset in the build queue ahead of the number of build requests that are pending in the build queue." also see [0147-0148] EN: the queue is iteratively broken down whenever there's a build failure. Each successful sub build request is removed from the queue, and the system continues down to isolate the problem. See [0139] also Fig. 5 and associated paragraphs [0074-0078, 0096, and 0106] for detailed logic of partial build subsetting, risk factors and execution.)
Claims 9-11 and 14 recite limitations similar to claim 8 and are rejected under the same rationale.
Regarding Claim 16, Iwanir in view of Lin teaches the method of claim 8. Iwanir teaches wherein the change information includes error information upon a past build ([0150] and [0154])
the method further comprises preferentially allocating a resource of a build destination to a partial build pattern having caused an error in a past build ([0139] "The embodiments and techniques described herein provide for improvements in operation of host servers and similar systems, such as those hosting gated check-in queue mechanisms. For instance, the described embodiments and techniques provide for increased efficiency in performing builds for projects at least in that multiple project changes for which a build completes successfully may be committed more quickly via the use of request sets and subsets as described herein. Additionally, determining root cause changes for build failures is also more efficiently performed using binary iteration for subset generation, as described herein. Furthermore, by utilizing the risk factors described herein for the selective generation of request sets and subsets, both times to commit for successful builds and root cause failure determination are improved in the systems. Accordingly, fewer processing cycles are required by the system in performing builds, and system memory is freed more quickly reducing the required memory footprint. Still further, project management is improved in such systems based on the efficiencies noted above which improve overall project progression times and reduce resource conflicts for developers to build and commit project changes.")
Regarding Claim 17. Iwanir teaches A non-transitory computer-readable medium including a computer program product, the computer program product including programmed instructions that, when executed by a computer, cause the computer to perform: ([0135] “Examples are also directed to computer program products comprising software stored on any computer useable medium. Such software, when executed in one or more data processing devices, causes a data processing device(s) to operate as described herein. Examples may employ any computer-useable or computer-readable medium, known now or in the future”)
The remaining limitations are similar to claim 1 and are rejected under the same rationale.
Regarding Claim 18, Iwanir in view of Lin teaches the method according to claim 17, wherein the computer program product, when executed by the computer, further causes the computer to perform: executing the build of the plurality of changed source codes defined by the overall build pattern and the partial build patterns ([0145])
Claims 5, 6, 12, 13, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Iwanir et al. (US20200264871A1) in view of Lin et al. (US20110239195A1) and further in view of Minium et al. (US20060236301A1)
Regarding Claim 5, Iwanir in view of Lin teaches the method of claim 1. Minium teaches wherein the change information includes information indicating a development ticket giving an instruction on change of the first changed source code ([0024] "An exemplary Ul for associating a work item with changes being submitted during a checkin operation is shown in FIG. 2. A channel selector 210 is provided, and the currently selected channel shown is the “Work Items” channel 220 (shown as “CH. 2”). By selecting the checkbox 230 on one or more work items 240, a relationship is established between source changes and the selected work items during the checkin process. This relationship is desirably persisted in the record of the source change and the work item record.")
the method further comprises defining the synchronous element based on the information indicating the development ticket ([0025] "Once this relationship is established, example scenarios may be enabled. One such example scenario is the automated generation of a list of work items completed in a new build. It is common for development organizations to create a list of work items that are addressed in a build and deliver this list to the team of testers so that they know what features and bug fixes should be tested in the build. This list is typically arduous to create as it requires somebody to collect this information from various sources and type up a document containing the details. However, by maintaining the relationship between source changes and work items, the list can be generated automatically.")
Iwanir, Lin and Minium are analogous art because they are from the same field of endeavor in code execution profiling. Before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art, to combine Iwanir, Lin and Minium to incorporate Minium’s ticket based system into Iwanir’s build method with expected results. A PHOSITA would be motivated to do so to streamline the development/build process. Developers typically use ticket system to keep track of bugs and development features. Integrating the ticket system into the builds would streamline the process for developers.
Regarding Claim 6, Iwanir in view of Lin teaches the method of claim 1. Minium teaches wherein the change information includes information indicating a development ticket giving an instruction on change of the first changed source code ( [0024])
Iwanir teaches the method further comprises generating the partial build patterns based a build priority defined by the development ticket ([0060] "For instance, build queue 400 exemplarily shows the following build requests included therein: a build request 402 having an identifier (ID) of 1, a status of “running” (i.e., build request 402 is being processed), a developer name “Dev1,” and a priority of “Normal”; a build request 404 having an ID of 2, a status of “pending,” a developer name “Dev2,” and a priority of “Normal”; a build request 406 having an ID of 3, a status of “pending,” a developer name “Dev3,” and a priority of “Low”; a build request 408 having an ID of 4, a status of “pending,” a developer name “Dev1,” and a priority of “Normal”; a build request 410 having an ID of 5, a status of “pending,” a developer name “Dev4,” and a priority of “Normal”; and a build request 412 having an ID of 6, a status of “pending,” a developer name “Dev1,” and a priority of “High.” As illustrated, the build request ID shown provides the order of submission of build requests, although other types of ID are contemplated herein. Because build request 402 is the oldest request (furthest ahead) of the pending requests shown in build queue 400 (i.e., is the first in), it is being processed (i.e., to be the first out), while the remaining build requests are pending." [0150] "In an embodiment of the system, the risk factor instructions are configured to determine the risk factors based on values of one or more sub-factors including at least one of a build request priority, a base commit identifier for a code change, an identity of a code developer requestor for the first build request or the second build request, a file type of a changed file for the first build request or the second build request, an amount of code change in the first build request or the second build request, a frequency of change for code over a time period, a number of previously failed compilations associated with a code change, or a relationship between a changed file in the first build request and a changed file in the second build request" and [0154] "In the embodiment, the subset instructions are configured to divide a request set into two request subsets with an approximately equal number of copies of build requests based at least on a dynamically updated risk factor and responsive to a build of the request set not successfully completing. In the embodiment, the queue optimizer instructions are further configured to insert the request subsets to the build queue." [0149] "The program instructions include risk factor instructions configured to determine risk factors of the build requests that are received by the system, and subset instructions configured to generate request sets, each including respective copies of one or more build requests pending in the build queue that are included to form the request sets, based at least on the risk factors and a build request option. The program instructions also include queue optimizer instructions configured to insert the request sets into the build queue as additional pending build requests." EN: the risk factors include priority which directly influences the decision to split the main build into partial builds.)
For motivation to combine see claim 5.
Claims 12 and 13, Iwanir teaches further comprising: executing the build of the plurality of changed source codes defined by the overall build pattern and the partial build patterns ([0145] "In an embodiment, the method further includes removing each of the number of build requests, that are pending, having a corresponding copy in the request set from the build queue based at least on said determining that the build for the separate build request completed successfully.")
adopting a build result of the overall build pattern when a build of the overall build pattern is successfully executed ([0145] EN: when the build request as a whole is successful it's removed from the queue. Otherwise, it's further broken down into sub requests)
adopting a build result from one or more partial build patterns, for which builds are successfully executed, when the build of the overall build pattern results in failure ([0146] "In an embodiment of the method, the copy of the one or more build requests includes at least two copies that are included in the request set, and each of the number of build requests remain in the build queue individually, and the method further includes determining a build for the separate build request was not completed successfully, removing the separate build request from the build queue, generating a first request subset including less than all copies of build requests in the request set based on an updated risk factor, generating a second request subset including any remaining copies of build requests in the request set that are not included in the first request subset, and providing the first request subset and the second request subset in the build queue ahead of the number of build requests that are pending in the build queue." also see [0147-0148] EN: the queue is iteratively broken down whenever there's a build failure. Each successful sub build request is removed from the queue, and the system continues down to isolate the problem. See [0139] also Fig. 5 and associated paragraphs [0074-0078, 0096, and 0106] for detailed logic of partial build subsetting, risk factors and execution.)
Regarding Claim 15, Iwanir in view of Lin teaches the method of claim 8. Minium teaches wherein the change information includes information indicating a development ticket giving an instruction on change of the first changed source code ([0024])
Iwanir teaches the method further comprises allocating resources of build destinations to the partial build patterns in descending order, sequentially from a partial build pattern including the change information having a higher build priority defined by the development ticket, subsequent to the overall build pattern ([0050] "Risk factor logic 106 is configured to determine risk factors associated with build requests from client device 102 a and/or client device 102 b, as well as risk factors associated with request sets and request subsets as described in further detail below. Queue optimizer logic 108 is configured to monitor a build queue and manage the generation and scheduling of merged queue items based, at least in part, on determined risk factors for build requests from risk factor logic 106. Host server 104 is configured to utilize risk factor logic 106 and queue optimizer logic 108 for intelligent and automatic merging of source control queue items." [0059] "As noted above, developers may submit their build requests that include their project changes to build queue 400, which may typically operate as a FIFO queue. While a first build request in the build queue is being built, i.e., being processed, subsequently submitted build requests are left pending in build queue 400 and must wait for completion of build requests that are further ahead in build queue 400 before being processed. This waiting time may be significant in cases with many project developers and/or build requests" [0108-0109] "if it is determined that request set 702 did not complete successfully (e.g., as in step 804 of flowchart 800 in FIG. 8), and subsequent to the preceding steps of flowchart 1000 described above, the first request subset (i.e., request subset 1202) and the second request subset (i.e., request subset 1204), are provided in build queue 1200, as pending, ahead of the build requests included in the first and second request subsets. It should also be noted that the build requests included in the first and second request subsets also remain pending in build queue 1200 in their original, relative locations. In step 1010, the build for the first request subset is processed. For example, build manager 208 may be configured to cause execution, e.g., on processor 204, of the build for request subset 1202 which is pending highest in build queue 1200, while request subset 1204 remains pending below request subset 1202, and the status of request subset 1202 will be changed to ‘running’ in build queue 1200." [0150] "the risk factor instructions are configured to determine the risk factors based on values of one or more sub-factors including at least one of a build request priority, a base commit identifier for a code change, an identity of a code developer requestor for the first build request or the second build request, a file type of a changed file for the first build request or the second build request, an amount of code change in the first build request or the second build request, a frequency of change for code over a time period, a number of previously failed compilations associated with a code change, or a relationship between a changed file in the first build request and a changed file in the second build request." [0074] "Referring again to flowchart 300, in step 308, a request set comprising one or more of the first build request and the second build request is generated based on the risk factor. For instance, subset logic 216 is configured to generate request sets that include one or more build requests based on risk factors determined by risk factor logic 214, as described above" EN: Refer to fig. 3, step 308 generates the request based on the risk factor, which as per [0150] depends on priority. Step 310 then places the request ahead of other requests based on its risk factor score.)
For motivation to combine see Claim 5.
18. (New) The non-transitory computer-readable medium according to claim 17, wherein the computer program product, when executed by the computer, further causes the computer to perform: executing the build of the plurality of changed source codes defined by the overall build pattern and the partial build patterns.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Zuul : discloses partial builds, various build patterns, parallel builds, tagged dependencies, and test before build workflows to ensure only error free builds are executed.
Hofsetz et al. (US20160350104A1): discloses build management techniques.
Melseki et al. (US20100262948A1): discloses versioning registry entries in a distributed program build.
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 AMIR DARWISH whose telephone number is (571)272-4779. The examiner can normally be reached 7:30-5:30 M-Thurs.
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, Lewis Bullock can be reached on 571-272-3759. 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.
/A.E.D./Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199
Prosecution Insights