Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 04/25/2024 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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.
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 including one or more pieces of the change information based on the synchronous element information between the plurality of changed source codes;
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.
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 changed source code and synchronous element information indicating a synchronous element related between the changed source code and another changed source code;
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 source code includes at least one of the source code, information indicating a content of change of the source code, and information indicating an access destination of either the 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 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 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 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-17 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 changed source code and synchronous element information indicating a synchronous element related between the changed source code and another 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 including one or more pieces of the change information based on the synchronous element information between the plurality of changed source codes ([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
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.")
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 source code includes at least one of the source code, information indicating a content of change of the source code, and information indicating an access destination of either the 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 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 builds of a plurality of source codes defined by the overall build pattern and one or more source codes defined by 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 the 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 build patterns, for which the builds are successfully executed, of the partial build patterns, 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 the 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 computer program product including programmed instructions embodied in and stored on a non-transitory computer readable medium, wherein the instructions, 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.
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 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 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 builds of a plurality of source codes defined by the overall build pattern and one or more source codes defined by 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 the 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 build patterns, for which the builds are successfully executed, of the partial build patterns, 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 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.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Hofsetz et al. (US20160350104A1): discloses build management techniques.
Melseki et al. (US20100262948A1): discloses versioning registry entries in a distributed program build.
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 2187
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199
Prosecution Insights