DETAILED ACTION
This communication is a Non-Final Office Action rejection on the merits. Claims 1, 3-8, and 10-14 are currently pending and have been addressed below.
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 .
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Information Disclosure Statement (IDS)
The information disclosure statement(s) filed on 09/13/2024 comply with the provisions 37 CFR 1.97, 1.98, and MPEP 609 and is considered by the Examiner.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
The term "ideal time-series data" in claims 3-4, 7, 10-11, and 14 is a relative term which renders the claim indefinite. The term " ideal time-series data" is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. For examination purposes the term “ideal” has been construed to be a pattern (e.g., effort over time) used for a specific phase and/or milestone of the project.
Response to Arguments
Applicant's arguments filed on 06/16/2026 (related to the 103 Rejection) have been fully considered but are moot in view of new grounds of rejection. Applicant's amendments necessitated the new ground(s) of rejection presented in this Office action. Rejection based on a newly cited reference(s) follows.
Applicant's arguments filed on 06/16/2026 (related to the 101 Rejection) have been fully considered but they are not persuasive.
Applicant states, on pages 6-10, that these steps, taken individually and as an ordered combination, are simply not directed to mathematical calculations per se. Rather, especially when considering the claim as a whole, the claim recites a specific technological process that creates an interactive feedback loop between a human user and a machine-learning-based prediction system, where user input on a graphical user interface triggers the system to re-classify, re-retrieve, and re-predict, thereby iteratively refining the analysis result. None of the individual steps, nor the ordered combination, reduces to a mathematical calculation in isolation. See MPEP 2106.04(a)(2). Accordingly, the claims do not recite an abstract idea under Prong I and thus are not directed to a judicial exception.
Also, the claims recite a specific, real-time human-machine interaction where input via the graphical user interface directly triggers a re-execution of the entire analytical pipeline, e.g., shape-pattern classification, domain-filtered retrieval, and model-based prediction, to produce iteratively updated results displayed via the same graphical user interface. This constitutes an improvement in the functioning of the prediction system itself, as explained at least at paragraph [0005] of the specification, which identifies a technical aspect not performed by conventional systems, and at paragraphs [0028]-[0029], which describe the iterative GUI-driven simulation.
Examiner respectfully disagrees with Applicant. These claim elements are still considered to be abstract ideas because they are directed to “mathematical concepts” which include “mathematical calculations.” In this case, “predicting at least one of a total man-hour effort and a quality metric based on the performance data of the at least one past project” recites mathematical calculations (see MPEP 2106.04(a)(2)). If a claim limitation, under its broadest reasonable interpretation, covers mathematical calculations, then it falls within the “mathematical concepts” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
The main functions of the additional elements recited in claim 1 are merely used to: collect data (e.g. updated man-hour input plan); analyze the data (e.g. retrieve at least one past project from the past projects based on a match and predict at least one of a total man-hour effort and a quality metric for the project associated with the man-hour input plan); and display the data (e.g., generate an updated analysis report). Those are functions that the courts have described as merely indicating a field of use or technological environment in which to apply a judicial exception (see MPEP 2106.05(h)).
The mere nominal recitation of generic computer components does not take the claim out of the methods of mathematical calculations. The prediction model is merely used to predict to predict the future total man-hour effort (Paragraph 0035). The graphical user interface (GUI) is merely used to edit the original man-hour input plan (Paragraph 0013). Merely stating that the step is performed by a computer component results in “apply it” on a computer (MPEP 2106.05f). These elements of “prediction model” and “GUI” are recited at a high level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer element. Also, the functions of “updating the man-hour input plan” and “re-executing retrieval and prediction of the man-hour effort” are considered conventional computer functions of “receiving or transmitting data over a network” and “performing repetitive calculations” (MPEP 2106.05d).
Lastly, the claim fails to recite any improvements to another technology or technical field, improvements to the functioning of the computer itself, use of a particular machine, effecting a transformation or reduction of a particular article to a different state or thing, adding unconventional steps that confine the claim to a particular useful application, and/or meaningful limitations beyond generally linking the use of an abstract idea to a particular environment. See 84 Fed. Reg. 55. Viewed individually or as a whole, these additional claim element(s) do not provide meaningful limitation(s) to transform the abstract idea into a patent eligible application of the abstract idea such that the claim(s) amounts to significantly more than the abstract idea itself. Thus, the claim is not patent eligible.
Independent claim 8 recites similar features and therefore is rejected for the same reasons as independent claim 1. Claims 3-7 and 10-14 are rejected for having the same deficiencies as those set forth with respect to the claims that they depend from, independent claims 1 and 8.
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, 3-8, and 10-14 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., an abstract idea) without reciting significantly more.
Independent Claim 1
Step One - First, pursuant to step 1 in the January 2019 Revised Patent Subject Matter Eligibility Guidance (“2019 PEG”) on 84 Fed. Reg. 53, the claim 1 is directed to an apparatus which is a statutory category.
Step 2A, Prong One - Claim 1 recites: A system comprising to: store predefined shape patterns representing distributions of man-hour input over time for respective man-hour input plans and past projects, each of the predefined shape patterns is associated with a shape pattern for a corresponding man-hour input plan and performance data; receive a man-hour input plan directed to a project, the man-hour input plan comprising time-series data associating a man-hour input amount with a corresponding time period; collate the time-series data with the predefined shape patterns to classify the time-series data into a shape corresponding to one of the predefined shape patterns; retrieve at least one past project from the past projects based on a match between the shape pattern of the at least one past project and the shape classified for the time-series data, the at least one past project being further classified into a same domain as a domain of the project; predict, generated from characteristics data and based on the performance data of the at least one past project, at least one of a total man-hour effort and a quality metric for the project associated with the man-hour input plan; update the man-hour input plan to generate a simulated man-hour input plan; and in response to generating the simulated man-hour input plan, re-execute collation of the time-series data, retrieval of the at least one past project, and prediction of the at least one of the total man-hour effort and the quality metric using the simulated man-hour input plan to generate an updated analysis result. These claim elements are considered to be abstract ideas because they are directed to “mathematical concepts” which include “mathematical calculations.” In this case, the limitations of “identifying man-hour input pattern from among past projects” and “predicting at least one of a total man-hour effort and a quality of the man-hour input plan on a basis of performance of the extracted past project” recite mathematical calculations. If a claim limitation, under its broadest reasonable interpretation, covers mathematical calculations, then it falls within the “mathematical concepts” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Step 2A Prong 2 - The judicial exception is not integrated into a practical application. Claim 1 includes additional elements: a processor; a storage device; a prediction model; and an input from a user via a graphical user interface.
The processor is merely used to implement the project total man-hour effort/quality prediction simulation system (Paragraph 0030). The storage device is merely used to store programs and data used when the programs are executed (Paragraph 0015). The prediction model is merely used to predict to predict the future total man-hour effort (Paragraph 0035). The graphical user interface (GUI) is merely used to edit the original man-hour input plan (Paragraph 0013). Merely stating that the step is performed by a computer component results in “apply it” on a computer (MPEP 2106.05f). These elements of “processor,” “storage device,” “prediction model,” and “GUI,” are recited at a high level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer element. Also, the GUI and is considered “field of use” since it’s just used to receive and store input information for an analysis, but the technology is not improved (MPEP 2106.05h). Accordingly, alone and in combination, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. Therefore, the claim is directed to an abstract idea.
Step 2B - The claim does not include additional elements that are sufficient to amount significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the claims describe how to generally “apply” the concept of predicting, based on the performance data of the at least one past project, at least one of a total man-hour effort and a quality metric for the project associated with the man-hour input plan. The specification shows that the processor is merely used to implement the project total man-hour effort/quality prediction simulation system (Paragraph 0030). The storage device is merely used to store programs and data used when the programs are executed (Paragraph 0015). The prediction model is merely used to predict to predict the future total man-hour effort (Paragraph 0035). The graphical user interface (GUI) is merely used to edit the original man-hour input plan (Paragraph 0013). Also, the functions of “updating the man-hour input plan” and “re-executing retrieval and prediction of the man-hour effort” are considered conventional computer functions of “receiving or transmitting data over a network” and “performing repetitive calculations” (MPEP 2106.05d). Thus, nothing in the claim adds significantly more to the abstract idea. The claim is ineligible.
Independent claim 8 is directed to a method at step 1, which is a statutory category. Claim 8 recites similar limitations as claim 1 and is rejected for the same reasons at step 2a, prong one; step 2a, prong 2; and step 2b. Thus, the claim is ineligible.
Dependent claims 3-4, 6, 10-11, and 13 are not directed to any additional claim elements. Rather, these claims offer further descriptive limitations of elements found in the independent claims and addressed above - including: to generate ideal time-series based on the characteristic data; and generate the ideal time-series data based on the milestone data in the at least one past project. At Step 2A, Prong 2 - this is still considered “field of use” since it’s just used to receive additional data for an analysis, but the technology is not improved (MPEP 2106.05h). At Step 2B – this is considered a conventional computer function of “receiving and transmitting over a network” and “performing repetitive calculations” (MPEP 2106.05d). Thus, nothing in the claim adds significantly more to the abstract idea. The claim is ineligible.
Dependent claims 5, 7, 12, and 14 are directed to an additional functions of the GUI. The GUI is merely used to edit the original plan and edit the simulated man-hour input plan by the user (Paragraphs 0013-0014). The GUI is still considered “field of use” (MPEP 2106.05h) at step 2A, Prong 2; as it’s just used to receive an adjustment of the man-hour plan by a user, but the GUI is not improved (MPEP 2106.05h). At step 2B, instructions to display and/or arrange information in a graphical user interface may not be sufficient to show an improvement in computer-functionality (MPEP 2106.05a). Thus, nothing in the claim adds significantly more to the abstract idea. The claim is ineligible.
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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 3-8, and 10-14 are rejected under 35 U.S.C. 103 as being unpatentable over Cantor et al. (US 2013/0325763 A1), in view of Bakir (Bakır, A., Turhan, B. and Bener, A., 2011. A comparative study for estimating software development effort intervals. Software Quality Journal, 19(3), pp.537-552).
Regarding claim 1 (Currently Amended), Cantor et al. discloses a system comprising: at least one processor to (Paragraph 0209, The components of computer system may include, but are not limited to, one or more processors or processing units 12, a system memory 16, and a bus 14 that couples various system components including system memory 16 to processor 12):
store, in a storage device, predefined shape patterns representing distributions of man-hour input over time for respective man-hour input plans and past projects, each of the predefined shape patterns is associated with a shape pattern for a corresponding man-hour input plan and performance data (Paragraph 0038, The task estimator 108 determining a probability distribution of the estimated effort (e.g., person-hours) for each of the as-yet incomplete tasks belonging to the project; Paragraph 0088, As the project proceeds and progresses, the methodology of the present disclosure in one embodiment gains information about tasks and can begin to overcome the problems with user estimates using machine learning techniques. Machine learning can be deployed to predict task effort from the evidence that is obtained from already-completed similar tasks. An aspect of learning is determining what similar tasks are. The machine learner uses a training set of examples of completed tasks with their attributes including their actual completion times to build a prediction model. The prediction model discriminates the completed training tasks using a variety of task attributes (such as owner, type, or priority). Once the model is available, the machine learner can apply it to a new task to obtain a task effort prediction by matching the new task to the most similar training tasks; Paragraph 0093, Both team velocity (the amount of work a team completes in a given period of time) and the nature of tasks may change over time on a given project. Thus, the machine learning is an ongoing process. Newly completed tasks increase the size of the training sets, and the machine learner continuously builds new models out of the new training sets. As a result, task effort prediction is adaptive and reflects changes and trends that may occur during a project's evolution; Paragraph 0151, The following illustrates example patterns that may be identified in the present disclosure for diagnoses, for instance, as issues that threaten on-time delivery. Pattern increased velocity: The rate at which work is being completed has increased. Example variants: improved efficiency, more time spent, overestimated work; Paragraph 0209, item 18, storage device; Examiner interprets the task effort during a project’s evolution as the predefined shape patterns representing distributions of man-hour input over time. In this case, the system predicts task effort (e.g., man-hour) by analyzing trends/patterns of similar projects);
receive a man-hour input plan directed to a project, the man-hour input plan comprising time-series data associating a man-hour input amount with a corresponding time period (Paragraph 0038, The task estimator 108 determining a probability distribution of the estimated effort (e.g., person-hours) for each of the as-yet incomplete tasks belonging to the project; Paragraph 0093, Both team velocity (the amount of work a team completes in a given period of time) and the nature of tasks may change over time on a given project. Thus, the machine learning is an ongoing process. Newly completed tasks increase the size of the training sets, and the machine learner continuously builds new models out of the new training sets. As a result, task effort prediction is adaptive and reflects changes and trends that may occur during a project's evolution; Paragraph 0096, The machine learner, as described so far, does not require explicit user input; it can learn solely from actual development data (the specification of completed tasks and their actual completion effort). However, the machine learner may utilize user estimates. For example, there might be an initial learning delay, during which training sets are collected and machine learning models are built; Examiner notes that the user estimates include a man-hour input plan directed to a project);
collate the time-series data with the predefined shape patterns to … the time-series data into a shape corresponding to one of the predefined shape patterns (Paragraph 0088, As the project proceeds and progresses, the methodology of the present disclosure in one embodiment gains information about tasks and can begin to overcome the problems with user estimates using machine learning techniques. Machine learning can be deployed to predict task effort from the evidence that is obtained from already-completed similar tasks. An aspect of learning is determining what similar tasks are. The machine learner uses a training set of examples of completed tasks with their attributes including their actual completion times to build a prediction model. The prediction model discriminates the completed training tasks using a variety of task attributes (such as owner, type, or priority). Once the model is available, the machine learner can apply it to a new task to obtain a task effort prediction by matching the new task to the most similar training tasks; Paragraph 0093, Both team velocity (the amount of work a team completes in a given period of time) and the nature of tasks may change over time on a given project. Thus, the machine learning is an ongoing process. Newly completed tasks increase the size of the training sets, and the machine learner continuously builds new models out of the new training sets. As a result, task effort prediction is adaptive and reflects changes and trends that may occur during a project's evolution; Paragraph 0151, The following illustrates example patterns that may be identified in the present disclosure for diagnoses, for instance, as issues that threaten on-time delivery. Pattern increased velocity: The rate at which work is being completed has increased. Example variants: improved efficiency, more time spent, overestimated work; Paragraph 0209, item 18, storage device; Examiner interprets the patterns/trends as the predefined shape patterns representing distributions of man-hour input over time. In this case, the system predicts task effort (e.g., man-hour) by analyzing trends/patterns of similar projects);
retrieve at least one past project from the past projects based on a match between the shape pattern of the at least one past project and the shape … for the time-series data, the at least one past project being further classified into a same domain as a domain of the project (Paragraph 0088, As the project proceeds and progresses, the methodology of the present disclosure in one embodiment gains information about tasks and can begin to overcome the problems with user estimates using machine learning techniques. Machine learning can be deployed to predict task effort from the evidence that is obtained from already-completed similar tasks. An aspect of learning is determining what similar tasks are. The machine learner uses a training set of examples of completed tasks with their attributes including their actual completion times to build a prediction model. The prediction model discriminates the completed training tasks using a variety of task attributes (such as owner, type, or priority). Once the model is available, the machine learner can apply it to a new task to obtain a task effort prediction by matching the new task to the most similar training tasks; Examiner interprets “most similar training tasks” as the “at least one past project being further classified into a same domain as a domain of the project”);
predict, using a prediction model generated from characteristics data and based on the performance data of the at least one past project, at least one of a total man-hour effort and a quality metric for the project associated with the man-hour input plan (Paragraph 0014, FIG. 5 illustrates estimating or predicting effort associated with a task in one embodiment of the present disclosure, for instance by a machine learning technique; Paragraph 0034, FIG. 1 is a diagram illustrating a project estimation predictor in one embodiment of the present disclosure. In one embodiment, a probability distribution of completion times for a project may be predicted based on estimating a probability distribution of effort for the tasks in the project. Here "effort" refers to the total work time required for completing a task. Effort is usually measured in man-hours and is different from duration, which may include time during which nobody is working on the task; Paragraph 0038, The task estimator 108 determining a probability distribution of the estimated effort (e.g., person-hours) for each of the as-yet incomplete tasks belonging to the project; It can be noted that the claim language is written in alternative form. The limitation taught by Cantor et al. is based on a predicted total man-hour effort);
update the man-hour input plan based on an input from a user via a graphical user interface to generate a simulated man-hour input plan (Paragraph 0015, FIG. 6 illustrates a flow of an overall algorithm that combines a machine learning based task effort prediction with a Monte Carlo simulation to predict completion time distribution in one embodiment of the present disclosure; Paragraph 0096, The machine learner, as described so far, does not require explicit user input; it can learn solely from actual development data (the specification of completed tasks and their actual completion effort). However, the machine learner may utilize user estimates. For example, there might be an initial learning delay, during which training sets are collected and machine learning models are built; Paragraph 0107, The above-described methodology may predict the probability that a development project will complete on time. Other aspects of the present disclosure may provide for problem diagnosis, what-if-analysis, expert assessment, and a graphical user interface for allowing a user to interact in discovering the probability, diagnosis, what-if-analysis, and expert assessment; Paragraph 0162, As an example, the program manager can choose to put additional personnel onto this project to help it get back on schedule. The manager may then figure out how the addition of those people is going to affect the team's velocity);
and in response to generating the simulated man-hour input plan, re-execute collation of the time-series data, retrieval of the at least one past project (Paragraph 0078, The methodology in one embodiment of the present disclosure may utilize a work schedule simulation for predicting project completion (e.g., at 110 in FIG. 1). Tasks may have dependencies on other tasks, and they may have a number of task attributes, such as an owner, a priority/severity value, a due date, a type, and an effort estimate; Paragraph 0088, As the project proceeds and progresses, the methodology of the present disclosure in one embodiment gains information about tasks and can begin to overcome the problems with user estimates using machine learning techniques. Machine learning can be deployed to predict task effort from the evidence that is obtained from already-completed similar tasks. An aspect of learning is determining what similar tasks are. The machine learner uses a training set of examples of completed tasks with their attributes including their actual completion times to build a prediction model. The prediction model discriminates the completed training tasks using a variety of task attributes (such as owner, type, or priority). Once the model is available, the machine learner can apply it to a new task to obtain a task effort prediction by matching the new task to the most similar training tasks; Paragraph 0093, Both team velocity (the amount of work a team completes in a given period of time) and the nature of tasks may change over time on a given project. Thus, the machine learning is an ongoing process. Newly completed tasks increase the size of the training sets, and the machine learner continuously builds new models out of the new training sets. As a result, task effort prediction is adaptive and reflects changes and trends that may occur during a project's evolution; Paragraph 0151, The following illustrates example patterns that may be identified in the present disclosure for diagnoses, for instance, as issues that threaten on-time delivery. Pattern increased velocity: The rate at which work is being completed has increased. Example variants: improved efficiency, more time spent, overestimated work; Paragraph 0209, item 18, storage device), and prediction of the at least one of the total man-hour effort and the quality metric using the simulated man-hour input plan to generate an updated analysis result for display via the graphical user interface (Paragraph 0015, FIG. 6 illustrates a flow of an overall algorithm that combines a machine learning based task effort prediction with a Monte Carlo simulation to predict completion time distribution in one embodiment of the present disclosure; Paragraph 0034, FIG. 1 is a diagram illustrating a project estimation predictor in one embodiment of the present disclosure. In one embodiment, a probability distribution of completion times for a project may be predicted based on estimating a probability distribution of effort for the tasks in the project. Here "effort" refers to the total work time required for completing a task. Effort is usually measured in man-hours and is different from duration, which may include time during which nobody is working on the task; Paragraph 0038, The task estimator 108 determining a probability distribution of the estimated effort (e.g., person-hours) for each of the as-yet incomplete tasks belonging to the project; Claim 16, a graphical user interface operable to provide graphical presentations associated with the probability distribution of an estimated effort needed to complete each of the unfinished tasks and the probability distribution of complete time for the project, the graphical user interface further operable to allow a user to interact with the problem diagnoses module, the what-if analysis module, and the expert assessment module; It can be noted that the claim language is written in alternative form. The limitation taught by Cantor et al. is based on a predicted total man-hour effort).
Although Cantor et al. discloses all the limitations above and a machine learning used to predict a total man-hour effort based on predefined shape patterns (e.g. historical patterns/trends of effort over a period of time), Canto et al. does not specifically disclose how the historical effort is classified into a shape corresponding to one of the predefined shape patterns.
However, Bakir discloses collate the time-series data with the predefined shape patterns to classify the time-series data into a shape corresponding to one of the predefined shape patterns (Page 540, 3 The approach, There are three main steps in our approach: (1) grouping similar projects together by cluster analysis; (2) determining the effort intervals for each cluster and specifying the effort classes; and (3) classifying new projects into one of the effort classes. The assumption behind applying cluster analysis to effort data is that similar projects have similar development effort. The class-labeled clusters then become the input data for the classification algorithm, which converts cost estimation into a classification process; Pages 544-543, The main purpose of PCA is to reduce the dimensions of the dataset so that it can still be efficiently represented without losing much information. Specifically, PCA seeks dimensions in which the variances are maximized by applying PCA to each cluster after clustering, the model shown in Fig.2 is developed. Our aim in applying PCA separately to each cluster is to extract separate features for each cluster so that we can obtain better results for both classification and point estimation. The dataset given in Table 1 is used as an example in Fig. 2 to show how our cost data are processed. In Fig. 2, the projects in the cost dataset are illustrated as P1…P14. After the dataset is normalized, projects are shown as P10…P140. The four clusters generated are named as C1, C2, C3 and C4, which correspond to effort interval classes; Page 546, 4.5 Scope and limitations, Our datasets contain a wide diversity of projects in terms of their sources, their domains and the time period during which they were developed. Datasets composed of software development projects from different organizations around the world are used to generalize our results; Examiner interprets “each cluster” as the “classification of the time-series data into a shape” since each cluster includes a different effort needed over time);
retrieve at least one past project from the past projects based on a match between the shape pattern of the at least one past project and the shape classified for the time-series data, the at least one past project being further classified into a same domain as a domain of the project (Page 540, 3 The approach, There are three main steps in our approach: (1) grouping similar projects together by cluster analysis; (2) determining the effort intervals for each cluster and specifying the effort classes; and (3) classifying new projects into one of the effort classes. The assumption behind applying cluster analysis to effort data is that similar projects have similar development effort. The class-labeled clusters then become the input data for the classification algorithm, which converts cost estimation into a classification process; Examiner interprets “specifying the effort classes & classifying new projects into one or the effort classes” as the “match between the shape pattern of the at least one past project and the shape classified for the time-series data”);
predict, using a prediction model generated from characteristics data and based on the performance data of the at least one past project, at least one of a total man-hour effort and a quality metric for the project associated with the man-hour input plan (Page 546, 4.5 Scope and limitations, In this paper, we address the cost estimation problem as a classification problem and propose an approach that integrates classification methods with cluster analysis. This approach uses historical cost data and different machine learning techniques in order to make predictions. Although our main aim is to predict effort intervals, we also demonstrate that point estimates can be achieved through our approach as well. Therefore, the scope of our work is relevant for practitioners who employ cost estimation practices).
It would have been obvious to one ordinary skill in the art before the effective filing date to modify the system used for predicting a total man-hour effort of a project (e.g., based on similar historical trends/patterns of effort over a period of time) of the invention of Cantor et al. to further specify how the historical data is classified into different shape patterns (e.g., effort classes) of the invention of Bakir because doing so would allow the system to classify new projects into one of the effort classes (see Bakir, Page 540, 3 The approach). Further, the claimed invention is merely a combination of old elements, and in combination each element would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Regarding claim 8 (Currently Amended), Cantor et al. discloses a method comprising (Paragraph 0006, A method for predicting a probability distribution of completion times for a project, in one aspect, may comprise receiving a set of unfinished tasks belonging to the project and attributes associated with the unfinished tasks. The method may also comprise obtaining a probability distribution of an estimated effort needed to complete each of the unfinished tasks. The method may further comprise determining the probability distribution of completion time for the project based on the probability distribution of an estimated effort needed to complete each of the unfinished tasks):
storing, by at least one processor, in a storage device, predefined shape patterns representing distributions of man-hour input over time for respective man-hour input plans and past projects, each of the predefined shape patterns is associated with a shape pattern for a corresponding man-hour input plan and performance data (Paragraph 0038, The task estimator 108 determining a probability distribution of the estimated effort (e.g., person-hours) for each of the as-yet incomplete tasks belonging to the project; Paragraph 0088, As the project proceeds and progresses, the methodology of the present disclosure in one embodiment gains information about tasks and can begin to overcome the problems with user estimates using machine learning techniques. Machine learning can be deployed to predict task effort from the evidence that is obtained from already-completed similar tasks. An aspect of learning is determining what similar tasks are. The machine learner uses a training set of examples of completed tasks with their attributes including their actual completion times to build a prediction model. The prediction model discriminates the completed training tasks using a variety of task attributes (such as owner, type, or priority). Once the model is available, the machine learner can apply it to a new task to obtain a task effort prediction by matching the new task to the most similar training tasks; Paragraph 0093, Both team velocity (the amount of work a team completes in a given period of time) and the nature of tasks may change over time on a given project. Thus, the machine learning is an ongoing process. Newly completed tasks increase the size of the training sets, and the machine learner continuously builds new models out of the new training sets. As a result, task effort prediction is adaptive and reflects changes and trends that may occur during a project's evolution; Paragraph 0151, The following illustrates example patterns that may be identified in the present disclosure for diagnoses, for instance, as issues that threaten on-time delivery. Pattern increased velocity: The rate at which work is being completed has increased. Example variants: improved efficiency, more time spent, overestimated work; Paragraph 0209, item 12, processor; Paragraph 0209, item 18, storage device; Examiner interprets the task effort during a project’s evolution as the predefined shape patterns representing distributions of man-hour input over time. In this case, the system predicts task effort (e.g., man-hour) by analyzing trends/patterns of similar projects);
receiving, by at least one processor, a man-hour input plan directed to a project, the man-hour input plan comprising time-series data associating a man-hour input amount with a corresponding time period (Paragraph 0038, The task estimator 108 determining a probability distribution of the estimated effort (e.g., person-hours) for each of the as-yet incomplete tasks belonging to the project; Paragraph 0093, Both team velocity (the amount of work a team completes in a given period of time) and the nature of tasks may change over time on a given project. Thus, the machine learning is an ongoing process. Newly completed tasks increase the size of the training sets, and the machine learner continuously builds new models out of the new training sets. As a result, task effort prediction is adaptive and reflects changes and trends that may occur during a project's evolution; Paragraph 0096, The machine learner, as described so far, does not require explicit user input; it can learn solely from actual development data (the specification of completed tasks and their actual completion effort). However, the machine learner may utilize user estimates. For example, there might be an initial learning delay, during which training sets are collected and machine learning models are built; Paragraph 0209, item 12, processor; Examiner notes that the user estimates include a man-hour input plan directed to a project);
collating, by at least one processor, the time-series data with the predefined shape patterns to … the time-series data into a shape corresponding to one of the predefined shape patterns (Paragraph 0088, As the project proceeds and progresses, the methodology of the present disclosure in one embodiment gains information about tasks and can begin to overcome the problems with user estimates using machine learning techniques. Machine learning can be deployed to predict task effort from the evidence that is obtained from already-completed similar tasks. An aspect of learning is determining what similar tasks are. The machine learner uses a training set of examples of completed tasks with their attributes including their actual completion times to build a prediction model. The prediction model discriminates the completed training tasks using a variety of task attributes (such as owner, type, or priority). Once the model is available, the machine learner can apply it to a new task to obtain a task effort prediction by matching the new task to the most similar training tasks; Paragraph 0093, Both team velocity (the amount of work a team completes in a given period of time) and the nature of tasks may change over time on a given project. Thus, the machine learning is an ongoing process. Newly completed tasks increase the size of the training sets, and the machine learner continuously builds new models out of the new training sets. As a result, task effort prediction is adaptive and reflects changes and trends that may occur during a project's evolution; Paragraph 0151, The following illustrates example patterns that may be identified in the present disclosure for diagnoses, for instance, as issues that threaten on-time delivery. Pattern increased velocity: The rate at which work is being completed has increased. Example variants: improved efficiency, more time spent, overestimated work; Paragraph 0209, item 18, storage device; Paragraph 0209, item 12, processor; Examiner interprets the patterns/trends as the predefined shape patterns representing distributions of man-hour input over time. In this case, the system predicts task effort (e.g., man-hour) by analyzing trends/patterns of similar projects);
retrieving, by at least one processor, at least one past project from the past projects based on a match between the shape pattern of the at least one past project and the shape … for the time-series data, the at least one past project being further classified into a same domain as a domain of the project (Paragraph 0088, As the project proceeds and progresses, the methodology of the present disclosure in one embodiment gains information about tasks and can begin to overcome the problems with user estimates using machine learning techniques. Machine learning can be deployed to predict task effort from the evidence that is obtained from already-completed similar tasks. An aspect of learning is determining what similar tasks are. The machine learner uses a training set of examples of completed tasks with their attributes including their actual completion times to build a prediction model. The prediction model discriminates the completed training tasks using a variety of task attributes (such as owner, type, or priority). Once the model is available, the machine learner can apply it to a new task to obtain a task effort prediction by matching the new task to the most similar training tasks; Paragraph 0209, item 12, processor; Examiner interprets “most similar training tasks” as the “at least one past project being further classified into a same domain as a domain of the project”);
predicting, by at least one processor, using a prediction model generated from characteristics data and based on the performance data of the at least one past project, at least one of a total man-hour effort and a quality metric for the project associated with the man-hour input plan (Paragraph 0014, FIG. 5 illustrates estimating or predicting effort associated with a task in one embodiment of the present disclosure, for instance by a machine learning technique; Paragraph 0034, FIG. 1 is a diagram illustrating a project estimation predictor in one embodiment of the present disclosure. In one embodiment, a probability distribution of completion times for a project may be predicted based on estimating a probability distribution of effort for the tasks in the project. Here "effort" refers to the total work time required for completing a task. Effort is usually measured in man-hours and is different from duration, which may include time during which nobody is working on the task; Paragraph 0038, The task estimator 108 determining a probability distribution of the estimated effort (e.g., person-hours) for each of the as-yet incomplete tasks belonging to the project; It can be noted that the claim language is written in alternative form. The limitation taught by Cantor et al. is based on a predicted total man-hour effort);
updating, by the at least one processor, the man-hour input plan based on an input from a user via a graphical user interface for generating a simulated man-hour input plan (Paragraph 0015, FIG. 6 illustrates a flow of an overall algorithm that combines a machine learning based task effort prediction with a Monte Carlo simulation to predict completion time distribution in one embodiment of the present disclosure; Paragraph 0096, The machine learner, as described so far, does not require explicit user input; it can learn solely from actual development data (the specification of completed tasks and their actual completion effort). However, the machine learner may utilize user estimates. For example, there might be an initial learning delay, during which training sets are collected and machine learning models are built; Paragraph 0107, The above-described methodology may predict the probability that a development project will complete on time. Other aspects of the present disclosure may provide for problem diagnosis, what-if-analysis, expert assessment, and a graphical user interface for allowing a user to interact in discovering the probability, diagnosis, what-if-analysis, and expert assessment; Paragraph 0162, As an example, the program manager can choose to put additional personnel onto this project to help it get back on schedule. The manager may then figure out how the addition of those people is going to affect the team's velocity; Paragraph 0209, item 12, processor);
and in response to generating the simulated man-hour input plan, re-executing, by the at least one processor, collation of the time-series data, retrieval of the at least one past project (Paragraph 0078, The methodology in one embodiment of the present disclosure may utilize a work schedule simulation for predicting project completion (e.g., at 110 in FIG. 1). Tasks may have dependencies on other tasks, and they may have a number of task attributes, such as an owner, a priority/severity value, a due date, a type, and an effort estimate; Paragraph 0088, As the project proceeds and progresses, the methodology of the present disclosure in one embodiment gains information about tasks and can begin to overcome the problems with user estimates using machine learning techniques. Machine learning can be deployed to predict task effort from the evidence that is obtained from already-completed similar tasks. An aspect of learning is determining what similar tasks are. The machine learner uses a training set of examples of completed tasks with their attributes including their actual completion times to build a prediction model. The prediction model discriminates the completed training tasks using a variety of task attributes (such as owner, type, or priority). Once the model is available, the machine learner can apply it to a new task to obtain a task effort prediction by matching the new task to the most similar training tasks; Paragraph 0093, Both team velocity (the amount of work a team completes in a given period of time) and the nature of tasks may change over time on a given project. Thus, the machine learning is an ongoing process. Newly completed tasks increase the size of the training sets, and the machine learner continuously builds new models out of the new training sets. As a result, task effort prediction is adaptive and reflects changes and trends that may occur during a project's evolution; Paragraph 0151, The following illustrates example patterns that may be identified in the present disclosure for diagnoses, for instance, as issues that threaten on-time delivery. Pattern increased velocity: The rate at which work is being completed has increased. Example variants: improved efficiency, more time spent, overestimated work; Paragraph 0209, item 18, storage device; Paragraph 0209, item 12, processor), and prediction of the at least one of the total man-hour effort and the quality metric using the simulated man-hour input plan for generating an updated analysis result for display via the graphical user interface (Paragraph 0015, FIG. 6 illustrates a flow of an overall algorithm that combines a machine learning based task effort prediction with a Monte Carlo simulation to predict completion time distribution in one embodiment of the present disclosure; Paragraph 0034, FIG. 1 is a diagram illustrating a project estimation predictor in one embodiment of the present disclosure. In one embodiment, a probability distribution of completion times for a project may be predicted based on estimating a probability distribution of effort for the tasks in the project. Here "effort" refers to the total work time required for completing a task. Effort is usually measured in man-hours and is different from duration, which may include time during which nobody is working on the task; Paragraph 0038, The task estimator 108 determining a probability distribution of the estimated effort (e.g., person-hours) for each of the as-yet incomplete tasks belonging to the project; Claim 16, a graphical user interface operable to provide graphical presentations associated with the probability distribution of an estimated effort needed to complete each of the unfinished tasks and the probability distribution of complete time for the project, the graphical user interface further operable to allow a user to interact with the problem diagnoses module, the what-if analysis module, and the expert assessment module; It can be noted that the claim language is written in alternative form. The limitation taught by Cantor et al. is based on a predicted total man-hour effort).
Although Cantor et al. discloses all the limitations above and a machine learning used for predicting a total man-hour effort based on predefined shape patterns (e.g. historical patterns/trends of effort over a period of time), Canto et al. does not specifically disclose how the historical effort is classified into a shape corresponding to one of the predefined shape patterns.
However, Bakir discloses collating, by the at least one processor, the time-series data with the predefined shape patterns to classify the time-series data into a shape corresponding to one of the predefined shape patterns (Page 540, 3 The approach, There are three main steps in our approach: (1) grouping similar projects together by cluster analysis; (2) determining the effort intervals for each cluster and specifying the effort classes; and (3) classifying new projects into one of the effort classes. The assumption behind applying cluster analysis to effort data is that similar projects have similar development effort. The class-labeled clusters then become the input data for the classification algorithm, which converts cost estimation into a classification process; Pages 544-543, The main purpose of PCA is to reduce the dimensions of the dataset so that it can still be efficiently represented without losing much information. Specifically, PCA seeks dimensions in which the variances are maximized by applying PCA to each cluster after clustering, the model shown in Fig.2 is developed. Our aim in applying PCA separately to each cluster is to extract separate features for each cluster so that we can obtain better results for both classification and point estimation. The dataset given in Table 1 is used as an example in Fig. 2 to show how our cost data are processed. In Fig. 2, the projects in the cost dataset are illustrated as P1…P14. After the dataset is normalized, projects are shown as P10…P140. The four clusters generated are named as C1, C2, C3 and C4, which correspond to effort interval classes; Page 546, 4.5 Scope and limitations, Our datasets contain a wide diversity of projects in terms of their sources, their domains and the time period during which they were developed. Datasets composed of software development projects from different organizations around the world are used to generalize our results; Examiner interprets “each cluster” as the “classification of the time-series data into a shape” since each cluster includes a different effort needed over time);
retrieving, by the at least one processor, at least one past project from the past projects based on a match between the shape pattern of the at least one past project and the shape classified for the time-series data, the at least one past project being further classified into a same domain as a domain of the project (Page 540, 3 The approach, There are three main steps in our approach: (1) grouping similar projects together by cluster analysis; (2) determining the effort intervals for each cluster and specifying the effort classes; and (3) classifying new projects into one of the effort classes. The assumption behind applying cluster analysis to effort data is that similar projects have similar development effort. The class-labeled clusters then become the input data for the classification algorithm, which converts cost estimation into a classification process; Examiner interprets “specifying the effort classes & classifying new projects into one or the effort classes” as the “match between the shape pattern of the at least one past project and the shape classified for the time-series data”);
predicting, by the at least one processor, using a prediction model generated from characteristics data and based on the performance data of the at least one past project, at least one of a total man-hour effort and a quality metric for the project associated with the man-hour input plan (Page 546, 4.5 Scope and limitations, In this paper, we address the cost estimation problem as a classification problem and propose an approach that integrates classification methods with cluster analysis. This approach uses historical cost data and different machine learning techniques in order to make predictions. Although our main aim is to predict effort intervals, we also demonstrate that point estimates can be achieved through our approach as well. Therefore, the scope of our work is relevant for practitioners who employ cost estimation practices).
It would have been obvious to one ordinary skill in the art before the effective filing date to modify the system used for predicting a total man-hour effort of a project (e.g., based on similar historical trends/patterns of effort over a period of time) of the invention of Cantor et al. to further specify how the historical data is classified into different shape patterns (e.g., effort classes) of the invention of Bakir because doing so would allow the system to classify new projects into one of the effort classes (see Bakir, Page 540, 3 The approach). Further, the claimed invention is merely a combination of old elements, and in combination each element would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Regarding claims 3 and 10 (Previously Presented), which are dependent of claims 1 and 8, the combination of Cantor et al. and Bakir discloses all the limitations in claims 1 and 8. Cantor et al. further discloses wherein the at least one processor is to: receive characteristic data relating to the project; and generate ideal time-series data based on the characteristic data (Paragraph 0034, FIG. 1 is a diagram illustrating a project estimation predictor in one embodiment of the present disclosure. In one embodiment, a probability distribution of completion times for a project may be predicted based on estimating a probability distribution of effort for the tasks in the project. Here "effort" refers to the total work time required for completing a task. Effort is usually measured in man-hours and is different from duration, which may include time during which nobody is working on the task. Referring to FIG. 1, an input for project estimation prediction may include a representation of a set of completed tasks 102, if any, belonging to the project to be estimated and a set of attributes associated to those tasks. Another input may include a set of as-yet incomplete tasks (also referred to as unfinished tasks) 104 belonging to the project to be estimated and a set of attributes associated to those tasks. An unfinished task 104, for example, may have attributes (shown at 106) such as the type, the owner, an initial estimate for completion, a due date, a priority status, and other such characteristics; Paragraph 0045, The learning algorithm operates on the input completed tasks and their attributes, for example, as follows. The learning algorithm may comprise selecting one or more subsets of the tasks. For each subset of tasks, the learning algorithm may select a subset of the attributes of the included tasks. For each subset of tasks, and for each associated subset of attributes of those tasks, the learning algorithm may use the attribute values to make an estimate of the effort of the tasks which have those attribute values. The above steps may be repeated for various subsets of tasks and various subsets of attributes of those tasks).
Regarding claims 4 and 11 (Previously Presented), which are dependent of claims 3 and 10, the combination of Cantor et al. and Bakir discloses all the limitations in claims 3 and 10. Cantor et al. further discloses wherein the at least one processor is to: receive milestone data relating to the project; and generate the ideal time-series data based on the milestone data in the at least one past project (Paragraph 0034, FIG. 1 is a diagram illustrating a project estimation predictor in one embodiment of the present disclosure. In one embodiment, a probability distribution of completion times for a project may be predicted based on estimating a probability distribution of effort for the tasks in the project. Here "effort" refers to the total work time required for completing a task. Effort is usually measured in man-hours and is different from duration, which may include time during which nobody is working on the task; Paragraph 0045, The learning algorithm operates on the input completed tasks and their attributes, for example, as follows. The learning algorithm may comprise selecting one or more subsets of the tasks. For each subset of tasks, the learning algorithm may select a subset of the attributes of the included tasks. For each subset of tasks, and for each associated subset of attributes of those tasks, the learning algorithm may use the attribute values to make an estimate of the effort of the tasks which have those attribute values. The above steps may be repeated for various subsets of tasks and various subsets of attributes of those tasks; Paragraph 0075, The task estimator 108 of the present disclosure may consider other kinds of information in addition to task attributes. Such other information may be received as input. For instance, the information input to the methodology of the present disclosure and considered in the learning may include information derived or computed from one or more task attributes. The information input to the method and considered in learning may also include information about the history of the task, including the history of changes to the values of task attributes, further including the absolute and relative sequence, timing, frequency, and other measures, properties, and/or patterns of the history of changes to these attribute values; Paragraph 0152, The above example patterns are not exclusive, for example, two or more can apply at the same time. Combinations of more basic patterns may be used to define composite patterns, e.g., repeatedly rescheduled item and rescheduled blocking item together give a repeatedly rescheduled blocking item. Some of the "patterns" may refer to single events. An issue affecting patterns generally is the scope over which they apply, e.g., release cycle, milestone, or iteration).
Regarding claims 5 and 12 (Currently Amended), which are dependent of claims 1 and 8, the combination of Cantor et al. and Bakir discloses all the limitations in claims 1 and 8. Cantor et al. further discloses wherein the at least one processor is to: output at least one of the total man-hour effort or the quality metric as an analysis result of the man-hour input plan (Paragraph 0034, FIG. 1 is a diagram illustrating a project estimation predictor in one embodiment of the present disclosure. In one embodiment, a probability distribution of completion times for a project may be predicted based on estimating a probability distribution of effort for the tasks in the project. Here "effort" refers to the total work time required for completing a task. Effort is usually measured in man-hours and is different from duration, which may include time during which nobody is working on the task; Paragraph 0042, The task estimator 108 in one embodiment may use a learning algorithm over attributes of the input completed tasks to discover which task attributes, of those available, are significant in the estimation of task effort. In one embodiment of the present disclosure, a task estimation model 114 may comprise the output of such a learning algorithm. Using the learned information, the task estimator 108 may determine and output a probability distribution of effort for the input as-yet incomplete tasks. Optionally, a categorization of tasks based on the similarity of the effort or time required to complete them may be produced as output; Paragraph 0044, The learning algorithm of the present disclosure in this embodiment may discover (learn) significant attributes and relationships. The learning algorithm provides a different methodology from methods that rely on a fixed set of attributes and with respect to methods that rely on fixed relationships of attributes to effort. The methodology of the present disclosure need not have dependence on any specific attributes; Paragraph 0045, The learning algorithm operates on the input completed tasks and their attributes, for example, as follows. The learning algorithm may comprise selecting one or more subsets of the tasks. For each subset of tasks, the learning algorithm may select a subset of the attributes of the included tasks. For each subset of tasks, and for each associated subset of attributes of those tasks, the learning algorithm may use the attribute values to make an estimate of the effort of the tasks which have those attribute values. The above steps may be repeated for various subsets of tasks and various subsets of attributes of those tasks; Paragraph 0075, The task estimator 108 of the present disclosure may consider other kinds of information in addition to task attributes. Such other information may be received as input. For instance, the information input to the methodology of the present disclosure and considered in the learning may include information derived or computed from one or more task attributes. The information input to the method and considered in learning may also include information about the history of the task, including the history of changes to the values of task attributes, further including the absolute and relative sequence, timing, frequency, and other measures, properties, and/or patterns of the history of changes to these attribute values; Paragraph 0151, The following illustrates example patterns that may be identified in the present disclosure for diagnoses, for instance, as issues that threaten on-time delivery: feature burn-up; repeatedly rescheduled (blocking) feature; scope creep; repeatedly rescheduled item; schedule delayed; schedule advanced; seasonal event; and/or shifted capacity, work effort has shifted from one area to another (e.g., from development to support or vice versa); Examiner notes that the initial estimated effort (e.g., man-hour effort) can be adjusted based on detected changes/patterns similar to historical patterns. It can be noted that the claim language is written in alternative form. The limitation taught by Cantor et al. is based on a predicted total man-hour effort) in response to an adjustment to the man-hour input plan by the user (Paragraph 0107, The above-described methodology may predict the probability that a development project will complete on time. Other aspects of the present disclosure may provide for problem diagnosis, what-if-analysis, expert assessment, and a graphical user interface for allowing a user to interact in discovering the probability, diagnosis, what-if-analysis, and expert assessment; Paragraph 0162, As an example, the program manager can choose to put additional personnel onto this project to help it get back on schedule. The manager may then figure out how the addition of those people is going to affect the team's velocity).
Regarding claims 6 and 13 (Previously Presented), which are dependent of claims 1 and 8, the combination of Cantor et al. and Bakir discloses all the limitations in claims 1 and 8. Cantor et al. further discloses wherein the at least one processor is to: receive milestone data relating to the project; and predict at least one of the total man-hour effort or the quality metric based on the milestone data in the at least one past project (Paragraph 0034, FIG. 1 is a diagram illustrating a project estimation predictor in one embodiment of the present disclosure. In one embodiment, a probability distribution of completion times for a project may be predicted based on estimating a probability distribution of effort for the tasks in the project. Here "effort" refers to the total work time required for completing a task. Effort is usually measured in man-hours and is different from duration, which may include time during which nobody is working on the task; Paragraph 0045, The learning algorithm operates on the input completed tasks and their attributes, for example, as follows. The learning algorithm may comprise selecting one or more subsets of the tasks. For each subset of tasks, the learning algorithm may select a subset of the attributes of the included tasks. For each subset of tasks, and for each associated subset of attributes of those tasks, the learning algorithm may use the attribute values to make an estimate of the effort of the tasks which have those attribute values. The above steps may be repeated for various subsets of tasks and various subsets of attributes of those tasks; Paragraph 0075, The task estimator 108 of the present disclosure may consider other kinds of information in addition to task attributes. Such other information may be received as input. For instance, the information input to the methodology of the present disclosure and considered in the learning may include information derived or computed from one or more task attributes. The information input to the method and considered in learning may also include information about the history of the task, including the history of changes to the values of task attributes, further including the absolute and relative sequence, timing, frequency, and other measures, properties, and/or patterns of the history of changes to these attribute values Paragraph 0152, The above example patterns are not exclusive, for example, two or more can apply at the same time. Combinations of more basic patterns may be used to define composite patterns, e.g., repeatedly rescheduled item and rescheduled blocking item together give a repeatedly rescheduled blocking item. Some of the "patterns" may refer to single events. An issue affecting patterns generally is the scope over which they apply, e.g., release cycle, milestone, or iteration).
Regarding claims 7 and 14 (Currently Amended), which are dependent of claims 1 and 8, the combination of Cantor et al. and Bakir discloses all the limitations in claims 1 and 8. Cantor et al. further discloses wherein the at least one processor is to: provide, via the graphical user interface, an interface which allows the user to change ideal time-series data, thereby generating the man-hour input plan (Paragraph 0034, FIG. 1 is a diagram illustrating a project estimation predictor in one embodiment of the present disclosure. In one embodiment, a probability distribution of completion times for a project may be predicted based on estimating a probability distribution of effort for the tasks in the project. Here "effort" refers to the total work time required for completing a task. Effort is usually measured in man-hours and is different from duration, which may include time during which nobody is working on the task; Paragraph 0107, The above-described methodology may predict the probability that a development project will complete on time. Other aspects of the present disclosure may provide for problem diagnosis, what-if-analysis, expert assessment, and a graphical user interface for allowing a user to interact in discovering the probability, diagnosis, what-if-analysis, and expert assessment; Paragraph 0162, As an example, the program manager can choose to put additional personnel onto this project to help it get back on schedule. The manager may then figure out how the addition of those people is going to affect the team's velocity).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
Amit (US 2022/0122025 A1) – discloses effort estimation is the process used to predict the amount of effort (e.g., developer hours) needed to develop a software application. The predicted amount of effort can then be used as basis for predicting project costs and for determining an optimal allocation of software developer time. An estimate for a new project can be typically derived by considering characteristics of the new project as well as characteristics of previous similar projects (see at least Paragraph 0002).
Jagannathan et al. (US 2016/0224908 A1) – discloses receiving a change requirement for a software implementation project (block 810). For example, host server 220 may receive a change requirement for a software implementation project. A change requirement may refer to a requirement received during completion of a software implementation project that alters one or more requirements of the software implementation project. In some implementations, host server 220 may receive the change requirement based on providing a user interface for the user to input the change requirement (see at least Paragraph 0073).
Torgerson et al. (US 20060041855 A1) – discloses an "Overridden Estimate" area 460 indicates an estimate that has been overridden by the user. The user may enter an estimate that overrides the overridden estimate when an estimate is calculated in a "New Override" field 464. A "Use Override?" checkbox 468 may be used to indicate whether the override or calculated estimate is to be used; Paragraph 0042, When the link 478 is activated, an "Update Team Base Hours" screen 500 may be displayed as shown in FIG. 9. A user may change an hours estimate for any of a plurality of stages of software development for the specified component type 458 (see at least Paragraph 0040).
Jiang (Jiang, Z. and Naude, P., 2007. An examination of the factors influencing software development effort. International Journal of Computer Information and Systems Science and Engineering, 1(3), pp.182-191) - discloses some guide as to the possible factors significant to development effort, including project size, average team size, development language and so on (see at least Page 933, Table 1).
Mori Keiji (JP 2010224889) - discloses each record of the Gantt chart includes a project member (hereinafter, also simply referred to as “person in charge”) that should execute the task, and the man-hours that are assumed as the amount of work that the person in charge must perform before the task is completed. (Hereinafter referred to as “scheduled man-hour” as appropriate) and the progress rate of the scheduled man-hour are recorded in association with each other. The unit of the planned man-hour in the present embodiment is “person day” indicating the work amount for one day by one person in charge (see at least Page 2).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MARJORIE PUJOLS-CRUZ whose telephone number is (571)272-4668. The examiner can normally be reached Mon-Thru 7:30 AM - 5:00 PM.
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, Patricia H Munson can be reached at (571)270-5396. 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.
/MARJORIE PUJOLS-CRUZ/Examiner, Art Unit 3624
Prosecution Insights