DETAILED ACTION
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 .
The following FINAL Office Action is in response to Applicant’s communication filed 04/06/2026 regarding Application 19/126,562
Status of Claim(s)
Claim(s) 1-4, 14, and 16-20 is/are currently pending and are rejected as follows.
Response to Arguments – 101 Rejection
Applicant’s arguments in regards to the previously applied 101 rejection have been fully considered but are not deemed persuasive.
Applicant argues that the amended claims provide sufficient integration of a specific technological implementation such as to no longer be directed towards an abstract idea and is not merely a mathematical comparison of plan and performance data.
Examiner as the claims as they have been amended are still directed towards an abstract idea, specifically that of Organizing Human Activity and Mental Process for the following reasons. First the claims were determined to be directed to at least one of the four statutory categories of invention. Then the claims were analyzed to see if they recite an abstract idea. The independent claims recited limitations that detailed the actions of acquiring progress plan and progress level of a step and execution timing corresponding to the step for a project, calculating a performance period and a plan period from a reference time point with the same progress levels, calculating a progress evaluation index for the project, and predicting progress performance after the predetermined time point. The prediction includes prediction of a completion data and the prediction method includes changing settings for resources necessary for execution of the step after the predetermined time point when the completion date exceeds a preset reference completion date, completing a corrected evaluation index for use in predictions, and determining necessary resources based on a learned relationship between resources inputted into a step in a past project and work period of the step after the resources are inputted. These actions as they are recited describe actions that include observations, evaluations and opinions with the aid of pen and paper as well as the managing behaviors of individuals as the resources being changed are not limited to the assignment of human resources or personnel as recited by Applicant in paragraph [0076] (“In a case where the calculated productivity is 1 (or its approximation), the progress prediction unit 24 determines that it is required to add necessary resources to the project to increase the SPI value. In the case of a construction project, the resources include, for example, the number of workers, the number of construction machines, etc. On the other hand, in a case where the calculated productivity is less than 1, the progress prediction unit 24 determines that it is necessary to consider revision of the progress plan (including change of the construction method). The progress prediction unit 24 can transmit the determination result of whether there is a delay occurring in the project and the value of the calculated productivity to the user terminal 3. Thereby, the user an recognize that addition of resources and revision of the progress plan are necessary.”). The claims were then analyzed with respect to additional elements to see if the claims when considered as a whole provided a meaningful integration of the abstract idea in such a way as to render it as significantly more than the recited exception. The additional elements of the independent claims of a second and third machine learning model, and processor were all deemed to be no more than mere instructions to implement the abstract idea (“apply it”), or in the case of the processor, insignificant extra-solution activity specifically that of mere data gathering, neither of which renders an abstract idea eligible. Therefore the claims remain rejected under 35 U.S.C. 101. Further elaboration regarding this determination is given in the amended 101 rejection below.
Response to Arguments – 102/103 Rejection
Applicant’s arguments with regards to the previously applied 102 and 103 rejections are rendered moot in view of the amended prior art rejection below.
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.
Claim(s) 1-4, 14, and 16-20 is/are rejected under 35 U.S.C. 101 because the claimed invention is/are directed towards a judicial exception (i.e. law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Claim(s) 1-4, 14, and 16-20 are directed towards an invention for the acquiring of a progress plan and progress level of a step and execution timing corresponding to the step for a project, calculating a performance period and a plan period from a reference time point with the same progress levels, calculating a progress evaluation index for the project, and predicting progress performance after the predetermined time point, wherein the prediction includes prediction of a completion data and the prediction method includes changing settings for resources necessary for execution of the step after the predetermined time point when the completion date exceeds a preset reference completion date, completing a corrected evaluation index for use in predictions, and determining necessary resources based on a learned relationship between resources inputted into a step in a past project and work period of the step after the resources are inputted. These actions fall under a subject matter grouping which the courts have considered ineligible (Organizing Human Activity, and Mental Process). These claims do not integrate the abstract idea into a practical application, and do not include additional elements that provide an inventive concept (are sufficient to amount to significantly more than the abstract idea).
Under Step 1 of the Alice/Mayo framework it must be considered whether the claims are directed to one of the four statutory categories of invention. Claim(s) 1-4 are directed towards a method comprising at least one step. Claim(s) 14 is directed towards a product. Claim(s) 16-20 are directed towards a method comprising at least one step. Accordingly, the claims fall within the four statutory categories of invention, (method and product) and will be further analyzed under Step 2 of the Alice/Mayo framework.
Under Step 2, Prong One, of the Alice/Mayo framework it must be considered whether the claims recite any abstract ideas.
Independent claim(s) 1 recites for the acquiring of a progress plan and progress level of a step and execution timing corresponding to the step for a project, calculating a performance period and a plan period from a reference time point with the same progress levels, calculating a progress evaluation index for the project, and predicting progress performance after the predetermined time point, wherein the prediction includes prediction of a completion data and the prediction method includes changing settings for resources necessary for execution of the step after the predetermined time point when the completion date exceeds a preset reference completion date, completing a corrected evaluation index for use in predictions, and determining necessary resources based on a learned relationship between resources inputted into a step in a past project and work period of the step after the resources are inputted which recites the abstract ideas of Organizing Human Activity, and a Mental Process in the following limitations:
acquiring data of a progress plan including a progress level of the step and an execution timing corresponding thereto;
acquiring data of progress performance including a progress level of a completed part of the progress plan and an execution timing corresponding thereto;
calculating, based on the data of the progress performance, a performance period from a reference time point of the step to a predetermined time point at which a predetermined progress level was achieved;
calculating, based on the data of the progress plan, a plan period from the reference time point of the step to a time point at which a progress level same as the predetermined progress level is achieved;
calculating, based on the performance period and the plan period, a progress evaluation index regarding progress of the step;
predicting, based on the progress evaluation index, data of the progress performance after the predetermined time point,
wherein prediction of the data of the progress performance includes prediction of a completion date of the project;
the progress prediction method further comprising: changing settings of resources necessary for execution of the step after the predetermined time point in a case where the completion date of the project exceeds a preset reference completion date; and
calculating a corrected evaluation index which is obtained by correcting the progress evaluation index based on the changed resources,
wherein the prediction of the data of the progress performance is performed based on the corrected evaluation index,
wherein the resources necessary for execution of the step are determined by a second…model, and
the second…model is a model that has learned a relationship between resources inputted into a step in a past project and a work period of the step after the resources are inputted.
Independent claim(s) 14 recites for the acquiring of a progress plan and progress level of a step and execution timing corresponding to the step for a project, calculating a performance period and a plan period from a reference time point with the same progress levels, calculating a progress evaluation index for the project, and predicting progress performance after the predetermined time point, wherein the prediction includes prediction of a completion data and the prediction method includes changing settings for resources necessary for execution of the step after the predetermined time point when the completion date exceeds a preset reference completion date, completing a corrected evaluation index for use in predictions, and determining necessary resources based on a learned relationship between resources inputted into a step in a past project and work period of the step after the resources are inputted which recites the abstract ideas of Organizing Human Activity, and a Mental Process in the following limitations:
acquire data of progress plan including a progress level of the step and an execution timing corresponding thereto;
acquire data of a progress performance including a progress level of a completed part of the progress plan and an execution timing corresponding thereto;
calculate, based on the data of the progress performance, a performance period from a reference time point of the step to a predetermined time point at which a predetermined progress level was achieved;
calculate, based on the data of the progress plan, a plan period from the reference time point of the step to a time point at which a progress level same as the predetermined progress level is achieved;
calculate, based on the performance period and the plan period, a progress evaluation index regarding progress of the step; and
predict, based on the progress evaluation index, data of the progress performance after the predetermined time point
wherein the project includes, as the at least one step, a preceding first step and a subsequent second step,
wherein the step is the second step,
acquire information of at least one first milestone in the first step and information of a second milestone corresponding to each first milestone in terms of timing in the second step;
accumulate the data of the progress performance of each of multiple completed projects;
acquire an influence evaluation model that represents influence of relationship between data regarding each first milestone in the data of the progress performance of the first step and data regarding the corresponding second milestone in the data of the progress performance of the second step on the progress evaluation index of the second step, wherein the influence evaluation model is determined based on the data of the progress performance that has been accumulated, and wherein the influence evaluation model is a third…model that has learned a relationship between the data of the progress performance that has been accumulated and the progress evaluation index of the second step;
calculate a corrected evaluation index which is obtained by correcting the progress evaluation index of the second step based on the influence evaluation model at the predetermined time point; and
in prediction of the data of the progress performance regarding the second step, predict, based on the corrected evaluation index, the data of the progress performance after the predetermined time point in the second step.
Independent claim(s) 16 recites for the acquiring of a progress plan and progress level of a step and execution timing corresponding to the step for a project, calculating a performance period and a plan period from a reference time point with the same progress levels, calculating a progress evaluation index for the project, and predicting progress performance after the predetermined time point, wherein the prediction includes prediction of a completion data and the prediction method includes changing settings for resources necessary for execution of the step after the predetermined time point when the completion date exceeds a preset reference completion date, completing a corrected evaluation index for use in predictions, and determining necessary resources based on a learned relationship between resources inputted into a step in a past project and work period of the step after the resources are inputted which recites the abstract ideas of Organizing Human Activity, and a Mental Process in the following limitations:
acquiring data of a progress plan including a progress level of the step and an execution timing corresponding thereto;
acquiring data of progress performance including a progress level of a completed part of the progress plan and an execution timing corresponding thereto;
calculating, based on the data of the progress performance, a performance period from a reference time point of the step to a predetermined time point at which a predetermined progress level was achieved;
calculating, based on the data of the progress plan, a plan period from the reference time point of the step to a time point at which a progress level same as the predetermined progress level is achieved;
calculating, based on the performance period and the plan period, a progress evaluation index regarding progress of the step; and
predicting, based on the progress evaluation index, data of the progress performance after the predetermined time point,
wherein the project includes, as the at least one step, a preceding first step and a subsequent second step,
wherein the step is the second step,
acquiring information of at least one first milestone in the first step and information of a second milestone corresponding to each first milestone in terms of timing in the second step;
accumulating the data of the progress performance of each of multiple completed projects;
acquiring an influence evaluation model that represents influence of relationship between data regarding each first milestone in the data of the progress performance of the first step and data regarding the corresponding second milestone in the data of the progress performance of the second step on the progress evaluation index of the second step, wherein the influence evaluation model is determined based on the data of the progress performance that has been accumulated, and
wherein the influence evaluation model is a third…model that has learned a relationship between the data of the progress performance that has been accumulated and the progress evaluation index of the second step;
calculating a corrected evaluation index which is obtained by correcting the progress evaluation index of the second step based on the influence evaluation model at the predetermined time point; and
in prediction of the data of the progress performance regarding the second step, predicting, based on the corrected evaluation index, the data of the progress performance after the predetermined time point in the second step.
Dependent claim(s) 2-4 and 17-20 merely further limit the abstract idea and are subject to the same rationale expressed above.
Under Step 2A, Prong Two, any additional elements are recited.
Independent claim(s) 1, 14, and 16 recites:
a processor
a second machine learning model
a third machine learning model
Dependent claim 4 recites:
a first machine learning model
These additional elements, considered both individually and as an ordered pair do no more than represent mere instructions to implement the abstract idea ("apply it" compute (See MPEP 2106.05(f)). Additionally, the claims represent insignificant extra solution activity (See MPEP 2106.05(g)). These elements are recited with a high degree of generality, and the specification sets forth the general purpose nature of the technologies required to implement the invention ( emphasis added).
Support for this determination can be found in Paragraph(s) [0079]-[0083], and [0102][0104] of Applicant's specification.
Under Step 2B eligibility analysis evaluates whether the claims as a whole amounts to significantly more than the recited exception, i.e. whether any additional element, or combination of elements, adds an inventive concept to the claims (MPEP 2106.05). As explained with respect to Step 2A, Prong Two, there are several additional elements. The processor, and first, second, and third machine learning models are all, at best, the equivalent of merely adding the words "apply it" to the abstract idea. Mere instructions to apply an exception cannot provide an inventive concept (See MPEP 2106.05(±). Further the processor represents insignificant extra solution activity (See MPEP 2106.05(g)), specifically that of mere data gathering which is known to be well-understood, routine, or conventional within the art (See MPEP 2106.05(d)(II)). Insignificant extra solution activity, especially that which is well-understood, routine, or conventional in the art does not provide an inventive concept. Even when considered in combination, these additional elements to are not deemed to be sufficient enough to provide an inventive concept onto the abstract idea, therefore, they are not eligible. (Alice Corp., 134 S. Ct. at 2358 USPQ2d at 1983. See also 134 S. Ct. at 2389, 110 USPQ2d at 1984 (warning against a §101 that turns on "the draftsman's art")).
Dependent claim(s) 2-3, and 17-20 do not recite any further additional elements and are thus rejected for the same reasons enumerated above.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries 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-4, 14, and 16-20 are rejected under 35 U.S.C. 103 as being unpatentable over Prieto (US 2014/0052489 A1) in view of Davies (US 2020/0327467 A1)
Claim 1 –
Prieto discloses the following limitations:
acquiring data of a progress plan including a progress level of the step and an execution timing corresponding thereto; (Prieto: Paragraph 28, "In FIG. 1, program management system 100 comprises of a project database 110, a project analysis engine 120 operatively coupled to the project database 110, and an output device 130. The project database 110, the project analysis engine 120, and the output device 130 can be operatively connected to each other by a network 115. Network 115 can either be a wired or a wireless network and can comprise a WAN, LAN, VPN, the Internet, cellular telephone network, or other types of network. The project database 110, alternatively also referred to as program database 110 hereinafter, can be configured to store one or more project or program metrics 112A, 112B ... 112N, which define, present, or objectify the progress or characteristics of a project or program. The project metrics 112A ... 112N, collectively referred to as project metrics 112 hereinafter, can be associated with a program, or one or more projects related to a program, and can include manpower utilized, cost incurred, resources used, logistics, schedule, test, inspection, completion percentage, personnel usage, man-hour usage, among other such program related metrics."; Paragraph 31, "Further, a higher order time derivative such as a fourth order time derivative of a project metric can indicate the level of efficiency or inefficiency in a program, i.e. the fourth order time derivative can indicate when a program shows sudden or consistent improvement or inefficiency over a period of time. A fourth order time derivative represents the change in third order time derivative and therefore is configured to represent the noise or disruptions caused or detected in the third order time derivative. Thus, the fourth order time derivative can be considered representative of a level of efficiency or inefficiency in the program. The fourth order time derivative can also be used to detect efficiencies in behavior of project metrics over a period of time that are not detected as disruptions by the third order derivative calculations, thereby increasing the sensitivity to change in project metrics over a given time instant. Furthermore, as each project metric represents a different view of the program progress, one metric might not necessarily reflect efficient application of a resource in a project with respect to a particular point of view, whereas other metrics might appear to represent efficient application of different resources. For example, consider cost and man-hours as two project metrics in a project over a small period of time, T. The project could be executed such that, when looked from the perspective of cost as the project metric through analysis of the third order time derivative of cost, it appears to be running smoothly or as planned without any disruptions. Furthermore, it can also be possible that the fourth order time derivative of the cost project metric shows that the metric lacks efficiency and has multiple small duration negative changes in disruptions. In such a case, it can also be possible that when a fourth order time derivative of man-hours is computed for the same time period, the time derivative depicts a strong efficiency with respect to man-hours spent during a portion of time period T with some number of man-hours saved during the portion. Therefore, multiple project metrics or even higher order derivatives of a single metric can yield different views of behavior or impact of the project metric 112 on the program, and as a result, metrics 112 can be treated individually or in combination."; Paragraph 41, "An achievement curve 132 can be obtained based on one or more project metrics 112 and can represent actual or planned progress or achievement of the project or program. Disruption metric 122, which is presented through one or more disruption indices, can be displayed on an output device 130 with respect to the achievement curve 132 to portray the duration, timestamp, location, severity of disruption or jerk, or other disruptive attributes of the project. As each disruption index is derived from a third order or higher time derivative of the project metric, it represents the change in rate of change (second order time derivative) of the project metric and therefore indicates the actual reason for the disruption or jerk in a project instead of merely indicating the rate of progress of project. Understanding the actual reason behind the jerk can, as a result, help the people and activities responsible for the jerk and assist in taking necessary measures to overcome the inefficiencies. The output device 130 can be a web browser, a cell phone, a tablet, a printer, a computer device or other type of suitable device.")
acquiring data of progress performance including a progress level of a completed part of the progress plan and an execution timing corresponding thereto (Prieto: Paragraph 34, "Project metrics 112 can be stored in such a manner that the data relating to these metrics 112 can easily be categorized and retrieved to analyze the project with respect to their progress, resource utilization, among other attributes. For example, a project metric 112 can represent the "percentage of work completed in the project". Although this and other forthcoming embodiments of the present disclosure are explained with respect of this project metric, it would be well appreciated that project metrics can include any parameter that can define or be associated with a project or program. Various other project metrics 112 can, individually or in combination with other, be analyzed to derive their respective third order and fourth order time derivatives to identify disruptions or efficiencies in the project. It has been appreciated by the applicant that a project metric 112 can be presented in a time-series model to explain the change in values of project metric 112 over a defined period of time. Before the project analysis engine 120 processes the project metric 112, the time-series fitted model can also be refined to determine if the model is stationery or presents some seasonality or periodicity in behavior."; Paragraph 35, "In an embodiment, project analysis engine 120, alternatively also referred to as program analysis engine 120 hereinafter, can be implemented in a server such as a HTTP server or as a web service, PaaS, Iaas, SaaS, cloud or the like. Analysis engine 120 can be configured to access project database 110 to select at least one project metric 112 of a project and calculate a disruption metric 122 as a function of at least a third order time derivative of the project metric. Third order time derivative of a project metric 112, as described above, can be computed by calculating the change in ramp rate or acceleration (second order time derivative) of the concerned project metric 112 with respect to time. Ramp rate represents the change in rate of change of a particular project metric with respect to time. For example, in case the project metric 112 represents % of work completed, change in percentage of work with respect to time, say from 5% to 9% in 5 days ( 4% per 5 days) and 9% to 11 % in the next 5 days (2% per 5 days) represent velocities of the project metric 112 calculated at five day intervals. A ramp rate of change of the project metric 112, on the other hand, represents the acceleration, i.e. the acceleration represents rate of change the velocities (-2% per 5 days) with respect to work completion in 5 days, wherein such acceleration can be computed on a daily basis or according to other desired time interval. Third order time derivative, on the other hand, further evaluates the change in project metric over a period of time and focuses on instantaneous changes in acceleration, which is also commonly referred to as "jerk" in physics. Therefore, increases in acceleration of project metric 112 result in positive values of the third the third order time derivative of project metric 112. Such deviations of actual project metrics from planned values can lead to higher jerks or disruptions, which can be monitored, identified, or evaluated by the third order time derivatives.")
calculating, based on the data of the progress performance, a performance period from a reference time point of the step to a predetermined time point at which a predetermined progress level was achieved; (Prieto: Paragraph 56, "An actual work completed achievement curve 215 is drawn on graph 200 to represent actual percentage of work completed during the time period T. As has earlier been mentioned, "percentage of work completed" is merely an exemplary project metric 112 and any other project metric such as resource utilized or cost incurred, can be used independently or in combination with other project metrics. In an embodiment, curve 215, can also be referred to as achievement curve 132 interchangeably, whereas in an alternate embodiment, the curve 215 can be different from achievement curve 132 in terms of the manner in which their respective project metrics are processed, evaluated, or analyzed. As can be seen from curve 215, even though projected work to be completed after the first 10 days was 10%, the actual work completed was 9%, leading to a lag of 1 %. Similarly, even though the projected work to be completed after the first 30 days was 30%, the actual work completed was 32%, leading to a delta of 2% over the projected schedule. As can be seen, the actual work completed curve 215 merely depicts whether the project metric 112 is ahead of or behind the planned projected curve 210 but does not explain or give any details of the reasons, location, timestamp, or activity giving rise to such a lag or leap. Although this document references "derivatives", one should appreciate that such values can be calculated based on difference in discrete values at points in time."; Paragraph 57, "Project analysis engine 120 can access project database 110 and fetch data related to "percentage of work completed" as the project metric 112 and compute third order time derivative of the project metric 112. The engine 120 can then generate a disruption metric 122 as a function of the third order time derivative, wherein the disruption metric 122 comprises of a disruption index that is derived from the third order time derivative and represents a jerk or disruption in the project due to the selected project metric 112. The disruption metric 122 can also comprise an efficiency index that is derived from fourth order time derivative of the project metric 112 and represents a snap or jounce or efficiency in the project when seen with respect to the selected project metric 112."; Paragraph 60, "In the present exemplary embodiment, FIGS. 2A and 2B are shown with respect to each other and map in terms of time vs. project metric behavior. To identify jerk and snap clearly, jerk is represented through a dotted line and snap is represented through a continuous line. As was noticed in FIG. 2A, after the first time period of 10 days, the actual project work completed was 9%, which was a lag of 1 % over the projected completion of 10%. FIG. 2B can, for this first time period (i.e., per day), through the disruption and efficiency indices stored in the disruption metric 122, identify and present the reason, location, and severity of the jerk or snap though the magnitude of unit of jerk or snap. For example, it can be noticed from representation 250 that there was a jerk or disruption of 2 units on the 7'th day of the project and a snap or efficiency of 3 units on 9'th day of the project, which lead to an overall percentage of work completion as 9%. A project manager or other stakeholder can, based on the representation 250, point to the event responsible, location, duration, and severity of the jerk (on 7'th day) and snap (on 9'th day) so as to understand the rationale behind the overall behavior of the project metric 112 and take a more informed decision on the project or program including allowing project teams to take necessary steps to improve the identified reasons for jerks. Reasons for disruption and efficiency can be measured and evaluated based on the details of the activities undertaken during the days or time of jerk or snap. In an embodiment, multiple project metrics can be evaluated simultaneously to assess and evaluate one or a combination of parameters that affect the project.")
calculating, based on the data of the progress plan, a plan period from the reference time point of the step to a time point at which a progress level same as the predetermined progress level is achieved; (Prieto: Paragraph 13, "The inventive subject matter is considered to include a project management system comprising a project database and a project analysis engine operatively coupled with the project database. The project database can be configured to store project metrics with respect to time, wherein the project metrics are associated with a program, or projects related to a program, and can include cost incurred, resources utilized, schedule, completion percentage, personnel usage, man-hour usage, or such parameters that define or characterize attributes of the program. The project analysis engine can be configured to access the project database to select at least one of the project metrics of the project and calculate a disruption metric as a function of at least a third order time derivative of the project metric. The disruption metric can include a disruption index, which is defined to be derived specifically from the third order time derivative of the project metric and which represents jerk or disruption changes in the project metric in the project. A project achievement curve (e.g., planned loading curve, estimated progress curve, etc.), can be obtained based on the project metric and can be displayed on an output device with respect to the disruption metric to portray the duration, timestamp, location, severity of disruption or jerk, or other disruptive aspect of the program. Further, the distribution metric can include an efficiency index, which is defined to be derived specifically from the fourth order time derivative of the program metric and represents a snap or jounce associated with changes in the project metric.”; Paragraph 33, “Further, apart from conventional project metrics, a number of new or customized project metrics can be defined where analysis of one or a combination such introduced project metrics can throw deeper insights into the execution, planning, or implementation of a program. Certain exemplary project metrics can include email communications of program or project teams, text messages, employee retention, recruitment pattern, inputs from multiple project management tools, quality reviews and number of defects, extent of rework, stakeholder involvement, impact on management, change in scope, cost-performance indicator, schedule performance index (SPI), sensor outputs, response times, an index indicating comparison between planned value (PV), actual cost (AC) and Earned Value (EV), or other such measures that are directly or indirectly indicative of the above.”; Paragraph 39, “As has been described above, project metrics 112 can also include multiple user defined metrics, third order time derivatives of which can be used to flag abrupt or disruptive events. For example, change in rate of exchange of emails between two parties involved in a particular project can be an indicator of a disruption in the project, specifically in the activity defined in the subject line of the emails. Disruption index can therefore be derived based on the third order time derivative of email project metric and an appropriate action can be taken. Furthermore, it should be appreciated that a disruption can also exist or take place in case there is no jerk in a particular project metric over a defined period of time. For example, in case an activity was planned to be initiated on 15'th July, which was expected to raise the cost of the project by USD 500,000, the lack of change in the rate of change of the cost project metric till 18'th July could mean a disruption in the project and a possible suggestion of non-initiation of the activity. In this example, the farther the date of non-change in cost project metric is from 15'th July, the higher can be the value of the disruption index. In other words, a delay in a start date can be an indicator of future disruptions.”; Paragraph 42, “Achievement curve 132 can also be obtained based on planned values for project metrics 112 such as planned schedule, cost, expenditure rates, man-hours, installation rates, or earned value, before or after initiation of the project. Multiple achievement curves 132 can also be represented at the output device 130 for one or a combination of project metrics 112. In another instance, achievement curve 132 can also be modeled or simulated based on previous similar projects, projections of subject matter experts who can make objective assumptions around efficiency with which certain activities would be carried out and also efficiency with which transition between activities would take place (start:stop; ramp-up:ramp-down), or known simulation models such as Monte Carlo techniques. Therefore, achievement curve 132 could be built based on a statistical aggregation of model programs or projects from Monte Carlo simulations. Project metric data that is represented with respect to time by the achievement curve can be hereinafter referred to as baseline data.”)
calculating, based on the performance period and the plan period, a progress evaluation index regarding progress of the step; (Prieto: Paragraph 42, “Achievement curve 132 can also be obtained based on planned values for project metrics 112 such as planned schedule, cost, expenditure rates, man-hours, installation rates, or earned value, before or after initiation of the project. Multiple achievement curves 132 can also be represented at the output device 130 for one or a combination of project metrics 112. In another instance, achievement curve 132 can also be modeled or simulated based on previous similar projects, projections of subject matter experts who can make objective assumptions around efficiency with which certain activities would be carried out and also efficiency with which transition between activities would take place (start:stop; ramp-up:ramp-down), or known simulation models such as Monte Carlo techniques. Therefore, achievement curve 132 could be built based on a statistical aggregation of model programs or projects from Monte Carlo simulations. Project metric data that is represented with respect to time by the achievement curve can be hereinafter referred to as baseline data.”; Paragraph 43, “Achievement curve 132 can be represented as a mathematical equation (e.g., a curve, a fitted curve to actual data, fitted curve simulation data, hybrid data, etc.), which aims to represent utilization of resources over the proposed time of the project. The curve 132 can also be illustrated as a combination of two or more curves that help represent side by side comparisons of actual time and expenditure components (actual project metric values) vs. proposed time and costs allocations of specific resources (planned values for the project metrics).”; Paragraph 54, “FIGS. 2A and 2B illustrate exemplary graphs showing disruption or jerk or efficiency or snap or jounce in a project through analysis of a project metric 112 with respect to time. In the present disclosure, as an exemplary illustration, the graphs are drawn for "percentage of work completed" as the project metric 112. The graphs can help in understanding the disruptions or efficiencies that occur during a project. FIG. 2A illustrates a projected achievement curve 210 for a project metric 112 (percentage of work completed for example) with respect to time and also illustrates the actual obtained achievement curve 215 for the project metric 112 of the project, plotted over percentage of work completed against time period in two axis. FIG. 2B, on the other hand, through disruption metric 122 comprising one or more disruption and efficiency indices, illustrates the magnitude and location of jerk or snap in the project. FIG. 2A and FIG. 2B can be described in a better manner as below.”)
predicting, based on the progress evaluation index, data of the progress performance after the predetermined time point, (Prieto: Paragraph 55, “FIG. 2A illustrates a graph 200 for percentage of work completed over time period T. In the present exemplary embodiment, "percentage of work completed" depicts a project metric 112 and is expressed as work completion percentage taken along Y axis. Amount of time taken to finish the specified amount of work is illustrated on X axis as time period T of the project. For illustration and simplicity, percentage of work completed is divided into 10 divisions, wherein each division indicates 10% of project work completed. Time period T along X axis can be divided into number of days after which the work rate is to be calculated and in the present illustration, the defined time period interval is 10 days. Therefore, after every 10 days, the percentage work completed is calculated for the present illustration. A projected work completion achievement curve 210 presenting the expected progress of the project can be estimated and drawn on the graph 200. Curve 210 can be drawn and defined before the project is initiated. The projected work completion curve 210 represents the percentage of work expected to be completed at defined time period intervals. For example, in the present illustration of FIG. 2, 10% of work involved in the project is expected to be completed within first 10 days and 50% of the work is expected to be completed within 50 days from initiation of the project. This work rate, in the present illustration, would lead to 100% work completion after 100 days. Therefore, a project or program manager or a user can plan that the project will be completed in 100 days and that the project be monitored after every 10 days to understand the progress of the program.”; Paragraph 69, “Project analysis engine 120 can generate a disruption metric 122 comprising mean square derivative (MSD) value of fourth order time derivative of one or more project metrics 112 of a program, wherein mean square derivative (MSD) value is a sum of squares of periodic efficiency values or snaps observed over a number of time periods. MSD value can be computed by calculating fourth order time derivatives of a project metric at periodic time intervals (such as daily) of a defined duration of project execution (such as 1 month) and then calculating mean of the derivative values. MSD value can be stored in the disruption metric 122 along with disruption and efficiency indices. Efficiency index can also be configured to include an absolute value derived from the fourth order time derivative of one or more project metrics 112. Such absolute values have already been illustrated in FIG. 2B. In another implementation, efficiency index can include cumulative efficiency or inefficiency over a defined period of time, wherein the cumulative efficiency can include a sum of all absolute values derived from the fourth order time derivatives for the defined period.”; Paragraph 70, “FIG. 3A represent an S-curve 315 with respect to a project metric 112 such as man-hours and time. Any other suitable project metric based on output, cost, scope of work, procurement, logistics, risk, communication, human resource plan, quality, or number of activities can also be incorporated. S-curve 315 is an S-shaped graph produced by Sigmoid formula which calculates the cumulative expenditure of certain project metrics against time. S-curve 315 is typically used against estimates such as projections or budgets on such project metrics 112. The projected curve 310 represents the projections of total number of man-hours planned to be used over the period of 100 days of the project. For simplicity, the projected curve 310 has been shown with a slope of 1, with 10% of the work intended to be covered in 10 days and 100% of the work intended to be covered in 100 days. As can be seen, the S-curve 315 typically represents a slow start and a slow finish with varying acceleration in between, wherein the man-hours consumed are lower than projected in the first half and higher in the second half. For example, after 30 days the number of man-hours to be consumed is planned to be 30 and the actual consumption is 15. Similarly, after 90 days, the number of man-hours to be consumed is planned to be 90 and the actual consumption is 98.”; Paragraph 73, “As a can be seen, the efficiency index or snap can have actual values from negative to positive, wherein the negative values can indicate inefficiencies (such as undesirable disruptions or events leading to lag in projects) and positive values can indicate efficiencies such as on-time or before time start of new activities, email communications indicating no change in scope of an activity, reduction in man-hours, among others. Furthermore, magnitude of efficiency index, as shown on Y axis can indicate the level of efficiency, which can be compared with defined thresholds, so as to take necessary action for highlighting the event responsible, activities undertaken in the event, people responsible for those activities, duration of those activities, importance of each of those activities, and correct or continue the activities depending on efficiency or inefficiency. It should also be noted that, in the present illustration of FIG. 3C, the frequency of efficiency or inefficiency is more in the middle of the time duration of 10 days and highest around the 5'th day, whereas the frequency of variation is relatively lower in the beginning and in the end. However, such a representation is purely project or program specific and can vary.”)
wherein prediction of the data of the progress performance includes prediction of a completion date of the project; (Prieto: Paragraph 55, “FIG. 2A illustrates a graph 200 for percentage of work completed over time period T. In the present exemplary embodiment, "percentage of work completed" depicts a project metric 112 and is expressed as work completion percentage taken along Y axis. Amount of time taken to finish the specified amount of work is illustrated on X axis as time period T of the project. For illustration and simplicity, percentage of work completed is divided into 10 divisions, wherein each division indicates 10% of project work completed. Time period T along X axis can be divided into number of days after which the work rate is to be calculated and in the present illustration, the defined time period interval is 10 days. Therefore, after every 10 days, the percentage work completed is calculated for the present illustration. A projected work completion achievement curve 210 presenting the expected progress of the project can be estimated and drawn on the graph 200. Curve 210 can be drawn and defined before the project is initiated. The projected work completion curve 210 represents the percentage of work expected to be completed at defined time period intervals. For example, in the present illustration of FIG. 2, 10% of work involved in the project is expected to be completed within first 10 days and 50% of the work is expected to be completed within 50 days from initiation of the project. This work rate, in the present illustration, would lead to 100% work completion after 100 days. Therefore, a project or program manager or a user can plan that the project will be completed in 100 days and that the project be monitored after every 10 days to understand the progress of the program.”)
the progress prediction method further comprising: changing settings of resources necessary for execution of the step after the predetermined time point in a case where the completion date of the project exceeds a preset reference completion date; and (Prieto: Paragraph 34, “Project metrics 112 can be stored in such a manner that the data relating to these metrics 112 can easily be categorized and retrieved to analyze the project with respect to their progress, resource utilization, among other attributes. For example, a project metric 112 can represent the "percentage of work completed in the project". Although this and other forthcoming embodiments of the present disclosure are explained with respect of this project metric, it would be well appreciated that project metrics can include any parameter that can define or be associated with a project or program. Various other project metrics 112 can, individually or in combination with other, be analyzed to derive their respective third order and fourth order time derivatives to identify disruptions or efficiencies in the project. It has been appreciated by the applicant that a project metric 112 can be presented in a time-series model to explain the change in values of project metric 112 over a defined period of time. Before the project analysis engine 120 processes the project metric 112, the time-series fitted model can also be refined to determine if the model is stationery or presents some seasonality or periodicity in behavior.”; Paragraph 43, “Achievement curve 132 can be represented as a mathematical equation (e.g., a curve, a fitted curve to actual data, fitted curve simulation data, hybrid data, etc.), which aims to represent utilization of resources over the proposed time of the project. The curve 132 can also be illustrated as a combination of two or more curves that help represent side by side comparisons of actual time and expenditure components (actual project metric values) vs. proposed time and costs allocations of specific resources (planned values for the project metrics).”; Paragraph 44, “Presentation of disruption metric 122 with respect to the achievement curve 132 can help conclude which parameters or attributes of the program caused the disruption and notify the program team to take necessary action along with comprehensive suggestions retrieved based on the attributes of disruption. It should be noted that as the third order time derivative measures change in project metrics with respect to three degrees of time, a disruption index can be reported sooner or before an abnormal activity occurs. For example, an earlier disruption can be noticed through a man-hours project metric as well as through cost project metric. The disruption index could be determined to be above a defined threshold. In response, the program analysis engine 120 can send a message to the program team to allocate additional man-hours (resources) to a particular activity that caused the disruption to prevent further issues. The message can be sent through multiple formats such as an email, SMS, automatic voice, sensor activation, among others, wherein the message can indicate further information relating to what the additional resources are intended to do, what their respective targets would be, time when they need to be allocated, what would be the impact of such allocation of resources on other parallel activities, additional cost impact through allocation of resources, or other suggestions.”; Paragraph 71, “FIG. 3B represents a graphical representation 350 illustrating jerks or disruptions for a short time periods within the project shown in FIG. 3A. Representation 350 shows the third order derivatives of the man-hours project metric 112 with respect to the actual progress curve 315 and illustrates the values of third order time derivatives of the metric 112 for the first 10 days of the project. As a can be seen, the disruption index or jerk can have actual values from negative to positive, wherein the negative disruptions can indicate negative jerks (unanticipated or unexpected) and positive disruptions are expected jerks representing start of new activities, allocation of new man-hours, among others. Furthermore, magnitude of disruption index, as shown on Y axis can indicate the level of disruption, which can later be compared with defined thresholds, so as to take necessary action such as allocating additional man-hours to complete the activity at hand. For example, in case -1 to +1 is the defined threshold for third order time derivatives of man-hours project metric, disruption due to activities undertaken on Day 4 of the program is higher than the defined threshold and therefore such activities along with remedial measures can be reported to the project team on Day 4 itself. It should also be noted that, in the present illustration of FIG. 3B, the frequency of disruption is more in the middle of the time duration of 10 days and highest around the 5'th day, whereas the disruption is relatively lower in the beginning and in the end. However, such a representation is purely project or program specific and can vary.”)
calculating a corrected evaluation index which is obtained by correcting the progress evaluation index based on the changed resources, (Prieto: Paragraph 74, “The system 100 can further be configured to generate signatures based on certain trends, types, or magnitudes of disruptions, efficiencies, or inefficiencies and store such signatures in program database 110. Such signatures can be generated based on experience of subject matter experts on anticipated disruptions or efficiencies, previous signatures in same or other programs, or common types of jerks or snaps that are generated in a particular type of project. The signatures can either be stored in the database 110 in an encoded format or any other known format, which can help their efficient retrieval or processing by the program analysis engine 120. The signatures can also be updated or new signatures can be formed as the program proceeds over a period time, wherein such update or formation can be based on earlier disruptions detected in the same program, new learning from other parts of the program or from other projects in the same program. The signatures can be configured to store disruption or efficiency characteristics along with their possible reasons and resolutions. The database 110 can be configured to classify the signatures based on whether they relate to efficiencies or disruptions, type of program or project, project metrics involved, % of confidence in suggested resolution or other parameters.”; Paragraph 76, “FIG. 4 presents a method 400 for program management to identify disruptions or efficiencies in a program or project with respect to one or a combination of project metrics of the program. Step 410 can include providing access to a project database that stores project metric objects of one or more project metrics. The project metrics can include manpower; cost incurred; resources utilized; logistics; schedule; test; inspection work, project, program completion percentage; personnel usage; email communication; earned value; man-hour usage; or other program related metrics; wherein the project metric objects can include data related to the project metrics obtained at a particular time period.”; Paragraph 78, “Step 430 includes the analysis engine deriving a disruption metric based on at least a third order time derivative of a project metric that is stored in the project metric database. The selected project metric of the program can be analyzed by reading project metric data over a time period and calculating a third order time derivative of the project metric at one or more time points to assess whether a jerk has happened in the program at any of those time points. Each jerk can represent a disruption (desired or undesired) that occurs the program. The disruption metric can be generated as a function of the third order time derivative of the project metric, and can be represented as f(d.sup.3PM/dt.sup.3), where PM represents the selected project metric. It should be appreciated that although the disruption metric has been described in the present disclosure as a function of the third order time derivative of the project metric, which indicates an indirect computation of the metric from the project metric, the disruption metric can also be directly implemented as equal in value to the third order time derivative of the project metric rather than being a function thereof. Alternatively, based on the project metric involved and program characteristics, the disruption metric can also be computed as a third order time derivative including a constant or offset value. Furthermore, the disruption metric can also represent multiple third order time derivatives of the project metric across different time periods and store them together as part of the metric.”)
wherein the prediction of the data of the progress performance is performed based on the corrected evaluation index, (Prieto: Paragraph 74, “The system 100 can further be configured to generate signatures based on certain trends, types, or magnitudes of disruptions, efficiencies, or inefficiencies and store such signatures in program database 110. Such signatures can be generated based on experience of subject matter experts on anticipated disruptions or efficiencies, previous signatures in same or other programs, or common types of jerks or snaps that are generated in a particular type of project. The signatures can either be stored in the database 110 in an encoded format or any other known format, which can help their efficient retrieval or processing by the program analysis engine 120. The signatures can also be updated or new signatures can be formed as the program proceeds over a period time, wherein such update or formation can be based on earlier disruptions detected in the same program, new learning from other parts of the program or from other projects in the same program. The signatures can be configured to store disruption or efficiency characteristics along with their possible reasons and resolutions. The database 110 can be configured to classify the signatures based on whether they relate to efficiencies or disruptions, type of program or project, project metrics involved, % of confidence in suggested resolution or other parameters.”; Paragraph 76, “FIG. 4 presents a method 400 for program management to identify disruptions or efficiencies in a program or project with respect to one or a combination of project metrics of the program. Step 410 can include providing access to a project database that stores project metric objects of one or more project metrics. The project metrics can include manpower; cost incurred; resources utilized; logistics; schedule; test; inspection work, project, program completion percentage; personnel usage; email communication; earned value; man-hour usage; or other program related metrics; wherein the project metric objects can include data related to the project metrics obtained at a particular time period.”; Paragraph 78, “Step 430 includes the analysis engine deriving a disruption metric based on at least a third order time derivative of a project metric that is stored in the project metric database. The selected project metric of the program can be analyzed by reading project metric data over a time period and calculating a third order time derivative of the project metric at one or more time points to assess whether a jerk has happened in the program at any of those time points. Each jerk can represent a disruption (desired or undesired) that occurs the program. The disruption metric can be generated as a function of the third order time derivative of the project metric, and can be represented as f(d.sup.3PM/dt.sup.3), where PM represents the selected project metric. It should be appreciated that although the disruption metric has been described in the present disclosure as a function of the third order time derivative of the project metric, which indicates an indirect computation of the metric from the project metric, the disruption metric can also be directly implemented as equal in value to the third order time derivative of the project metric rather than being a function thereof. Alternatively, based on the project metric involved and program characteristics, the disruption metric can also be computed as a third order time derivative including a constant or offset value. Furthermore, the disruption metric can also represent multiple third order time derivatives of the project metric across different time periods and store them together as part of the metric.”)
Prieto does not explicitly disclose the following, however, in analogous art of project management, Davies teaches the limitations below:
wherein the resources necessary for execution of the step are determined by a second machine learning model, and (Davies: Paragraph 43, “In some embodiments the module 110 uses an understanding of the project type, client history and available resource(s) 105 to recommend a team with the highest likelihood of success. Potential combinations of resources are compared using output from the success forecasting service. The client 101 can influence the end selection by identifying preferred team members (i.e. those they would like to work on the project.) The other required resource(s) 105 can then be matched based on shared working history and previous outcomes to maximize the performance of the new project team.”; Paragraph 44, “Once the team setup has been completed and/or approved by the client 101, module 110 generates 208 a plan for the completion of the requested project. The plan establishes the project time line, the order of tasks, the milestones of the project, invoicing schedule, establishing the communication between the client 101 and resource(s) 105 as well as the resource(s) 105 and other resource(s) 105 in tasks which are related, and the other factors which the requested project is to be completed on/by. In some embodiments, the module 110 accesses a project history database 107 which provides previously completed projects of similarity to establish a plan that is realistic based on previously record data. To determine the time specific task may take, tentative fees or prices for the tasks (or project as a whole), and other variables about the project which are requested by the client 101, required by the module 110, or important to establish prior to beginning the project.”)
the second machine learning model is a model that has learned a relationship between resources inputted into a step in a past project and a work period of the step after the resources are inputted. (Davies: Paragraph 44, “Once the team setup has been completed and/or approved by the client 101, module 110 generates 208 a plan for the completion of the requested project. The plan establishes the project time line, the order of tasks, the milestones of the project, invoicing schedule, establishing the communication between the client 101 and resource(s) 105 as well as the resource(s) 105 and other resource(s) 105 in tasks which are related, and the other factors which the requested project is to be completed on/by. In some embodiments, the module 110 accesses a project history database 107 which provides previously completed projects of similarity to establish a plan that is realistic based on previously record data. To determine the time specific task may take, tentative fees or prices for the tasks (or project as a whole), and other variables about the project which are requested by the client 101, required by the module 110, or important to establish prior to beginning the project.”; Paragraph 45, “In some embodiments, the module 110 uses an understanding of project structure and usual tasks to develop a project plan 208 for the specific project. Projects are assessed based on their type and the required deliverables, historic matches (or near matches) are compared to identify core and secondary tasks. Historic Durations for specific tasks within the project type are compared and assessed using a mean and Std deviation. These slightly negatively biased durations are combined with the predicted task associations to establish the project timeline. A plan is then recommended to the client using the recommended Milestone structure and ordered core tasks with an expected timeline for delivery (based on the Hiring Managers stated Start Date).”; Paragraph 48, “The module 110 may, in some embodiments, request or receive feedback 218 from the resource(s) 105 and/or the client 101 based on the project. This may include how the resource(s) 105 worked together, how the resource(s) 105 worked with the client 101, how the client 101 felt about the resource(s) 105, the length of the project, and issues with the project, any comments (positive and/or negative) about the project, ways to improve upon the project, effectiveness of communication between the parties, and the like. The module 110, takes this information and processes the information to optimize 220 the overall process. This may include, but not limited to, adjusting project types/templates, identifying resource(s) 105 which work well together, adjusting timelines to a more realistic length, adjusting prices and fees, and the like.”; Paragraph 49, “Once the plan has been established, the module submits 110 the plan to the client 101 for their approval. If the client 101 approves, the module 110 launches 212 the project. If the client 101 does not approve, the process resets to the project assessment 102. When the project is launched 212, the module 110 completes the necessary requirements to begin the project. This may include submitting invoices to the client 101, formulating the contractual requirements with the resource(s) 105, and establishing the plan with all parties involved. In some embodiments, the module 110 generates the invoices and contracts. In additional embodiments, the module accesses a template invoice and contract. In some embodiments, the module 110 is able to make adjustments to template invoices or contracts based on the specifics of the resource(s) 105 and the task to be completed.”)
Prieto discloses a method of determining progress and predictions of a project based on various acquired data values. Davies discloses a method for managing the monitoring the workflow of a project.. At the time of Applicant’s filed invention, one of ordinary skill in the art would have deemed it obvious to combine the methods of Prieto with the teachings of Davies in order to improve the planning and execution of projects as disclosed by Davies (Davies: Paragraph 5, “Therefore, it is desired for a method, computer program, or computer system to create a central system to plan the project, connect the resources, establish a timeline and project deliverables, all while maintaining communication between parties and monitor task completions, and project adjustments.”)
Claim 2 –
Prieto and Davies disclose the limitations of claim 1
Prieto further discloses the following:
wherein the progress evaluation index is a ratio of the plan period to the performance period. (Prieto: Paragraph 28, “In FIG. 1, program management system 100 comprises of a project database 110, a project analysis engine 120 operatively coupled to the project database 110, and an output device 130. The project database 110, the project analysis engine 120, and the output device 130 can be operatively connected to each other by a network 115. Network 115 can either be a wired or a wireless network and can comprise a WAN, LAN, VPN, the Internet, cellular telephone network, or other types of network. The project database 110, alternatively also referred to as program database 110 hereinafter, can be configured to store one or more project or program metrics 112A, 112B . . . 112N, which define, present, or objectify the progress or characteristics of a project or program. The project metrics 112A . . . 112N, collectively referred to as project metrics 112 hereinafter, can be associated with a program, or one or more projects related to a program, and can include manpower utilized, cost incurred, resources used, logistics, schedule, test, inspection, completion percentage, personnel usage, man-hour usage, among other such program related metrics.”; Paragraph 35, “In an embodiment, project analysis engine 120, alternatively also referred to as program analysis engine 120 hereinafter, can be implemented in a server such as a HTTP server or as a web service, PaaS, Iaas, SaaS, cloud or the like. Analysis engine 120 can be configured to access project database 110 to select at least one project metric 112 of a project and calculate a disruption metric 122 as a function of at least a third order time derivative of the project metric. Third order time derivative of a project metric 112, as described above, can be computed by calculating the change in ramp rate or acceleration (second order time derivative) of the concerned project metric 112 with respect to time. Ramp rate represents the change in rate of change of a particular project metric with respect to time. For example, in case the project metric 112 represents % of work completed, change in percentage of work with respect to time, say from 5% to 9% in 5 days (4% per 5 days) and 9% to 11% in the next 5 days (2% per 5 days) represent velocities of the project metric 112 calculated at five day intervals. A ramp rate of change of the project metric 112, on the other hand, represents the acceleration, i.e. the acceleration represents rate of change the velocities (-2% per 5 days) with respect to work completion in 5 days, wherein such acceleration can be computed on a daily basis or according to other desired time interval. Third order time derivative, on the other hand, further evaluates the change in project metric over a period of time and focuses on instantaneous changes in acceleration, which is also commonly referred to as "jerk" in physics. Therefore, increases in acceleration of project metric 112 result in positive values of the third the third order time derivative of project metric 112. Such deviations of actual project metrics from planned values can lead to higher jerks or disruptions, which can be monitored, identified, or evaluated by the third order time derivatives.”; Paragraph 51, “Third order time derivative of a project metric 112 can be calculated by identifying change in ramp rate or change in second order time derivative i.e., by identifying changes that occur in rate of change of percentage of work completed in a project over a defined period of time. In the present example, assuming in three days the percentage of work completed increases from 3% to 6%, the rate of change in work completed is 1% per day and change in rate of change (second order time derivative) would give an indication of how fast or slow "the percentage of work completed" becomes in a day or over the period of time. The third order time derivative can therefore be computed as the rate of change of second order, which can, for much smaller time intervals, detect the change in acceleration of the percentage of work completed and yield areas where the change represents an instantaneous disruption or jerk. Similarly, fourth order time derivative (efficiency index) of a project metric 112 can be calculated by identifying changes that occur in the third order time derivative of one or more project metrics. Third order time derivative of the project metric 112 gives a disruption index of the project metric 112, which, when measured alongside time, can indicate event responsible, location, duration, timestamp, severity, or other attributes that led to disruption or jerk in the project during particular time period.”)
Claim 3 –
Prieto and Davies disclose the limitations of claims 1-2
Prieto further discloses the following:
wherein a constant value is used as the progress evaluation index. (Prieto: Paragraph 78, “Step 430 includes the analysis engine deriving a disruption metric based on at least a third order time derivative of a project metric that is stored in the project metric database. The selected project metric of the program can be analyzed by reading project metric data over a time period and calculating a third order time derivative of the project metric at one or more time points to assess whether a jerk has happened in the program at any of those time points. Each jerk can represent a disruption (desired or undesired) that occurs the program. The disruption metric can be generated as a function of the third order time derivative of the project metric, and can be represented as f(d.sup.3PM/dt.sup.3), where PM represents the selected project metric. It should be appreciated that although the disruption metric has been described in the present disclosure as a function of the third order time derivative of the project metric, which indicates an indirect computation of the metric from the project metric, the disruption metric can also be directly implemented as equal in value to the third order time derivative of the project metric rather than being a function thereof. Alternatively, based on the project metric involved and program characteristics, the disruption metric can also be computed as a third order time derivative including a constant or offset value. Furthermore, the disruption metric can also represent multiple third order time derivatives of the project metric across different time periods and store them together as part of the metric.”; Paragraph 73, “As a can be seen, the efficiency index or snap can have actual values from negative to positive, wherein the negative values can indicate inefficiencies (such as undesirable disruptions or events leading to lag in projects) and positive values can indicate efficiencies such as on-time or before time start of new activities, email communications indicating no change in scope of an activity, reduction in man-hours, among others. Furthermore, magnitude of efficiency index, as shown on Y axis can indicate the level of efficiency, which can be compared with defined thresholds, so as to take necessary action for highlighting the event responsible, activities undertaken in the event, people responsible for those activities, duration of those activities, importance of each of those activities, and correct or continue the activities depending on efficiency or inefficiency. It should also be noted that, in the present illustration of FIG. 3C, the frequency of efficiency or inefficiency is more in the middle of the time duration of 10 days and highest around the 5'th day, whereas the frequency of variation is relatively lower in the beginning and in the end. However, such a representation is purely project or program specific and can vary.”)
Claim 4 –
Prieto and Davies disclose the limitations of claim 1
Prieto does not explicitly disclose the following, however, in analogous art of project management, Davies discloses the following:
wherein the data of the progress plan is determined by a first machine learning model, and the first machine learning model is a model that has learned a relationship between a progress level of a step in a past project and progress performance including an execution timing corresponding thereto. (Davies: Paragraph 44, “Once the team setup has been completed and/or approved by the client 101, module 110 generates 208 a plan for the completion of the requested project. The plan establishes the project time line, the order of tasks, the milestones of the project, invoicing schedule, establishing the communication between the client 101 and resource(s) 105 as well as the resource(s) 105 and other resource(s) 105 in tasks which are related, and the other factors which the requested project is to be completed on/by. In some embodiments, the module 110 accesses a project history database 107 which provides previously completed projects of similarity to establish a plan that is realistic based on previously record data. To determine the time specific task may take, tentative fees or prices for the tasks (or project as a whole), and other variables about the project which are requested by the client 101, required by the module 110, or important to establish prior to beginning the project.”; Paragraph 47, “In additional embodiments, when a task is not completed 216 on time, the module 110 enables dynamic revision to a given project plan based on changes to a task due date that has dependencies cause downstream impact (Plan management) or initiated based on clients 101 demand. The module 110 analyzes the impacts and is able to assess to see any changes to end delivery date and recommend new target dates to following resource(s) 105 task delivery. Based on the resource(s) 105 responses to recommended changes, the plan can either be delivered to plan or delivered to the new date (requiring client change management.)”; Paragraph 61, “In an example where the activity/task can be completed internally, the module compiles 406, the data for the action. Executes 408 the steps, procedures, or processes which are necessary to complete the task. The module 110 then manages 410 the asset in relation to the parties and the project.”)
Prieto discloses a method of determining progress and predictions of a project based on various acquired data values. Davies discloses a method for managing the monitoring the workflow of a project.. At the time of Applicant’s filed invention, one of ordinary skill in the art would have deemed it obvious to combine the methods of Prieto with the teachings of Davies in order to improve the planning and execution of projects as disclosed by Davies (Davies: Paragraph 5, “Therefore, it is desired for a method, computer program, or computer system to create a central system to plan the project, connect the resources, establish a timeline and project deliverables, all while maintaining communication between parties and monitor task completions, and project adjustments.”)
Claim 14 –
Prieto discloses the following limitations:
wherein the project includes at least one step, step (Prieto: Paragraph 13, “The inventive subject matter is considered to include a project management system comprising a project database and a project analysis engine operatively coupled with the project database. The project database can be configured to store project metrics with respect to time, wherein the project metrics are associated with a program, or projects related to a program, and can include cost incurred, resources utilized, schedule, completion percentage, personnel usage, man-hour usage, or such parameters that define or characterize attributes of the program. The project analysis engine can be configured to access the project database to select at least one of the project metrics of the project and calculate a disruption metric as a function of at least a third order time derivative of the project metric. The disruption metric can include a disruption index, which is defined to be derived specifically from the third order time derivative of the project metric and which represents jerk or disruption changes in the project metric in the project. A project achievement curve (e.g., planned loading curve, estimated progress curve, etc.), can be obtained based on the project metric and can be displayed on an output device with respect to the disruption metric to portray the duration, timestamp, location, severity of disruption or jerk, or other disruptive aspect of the program. Further, the distribution metric can include an efficiency index, which is defined to be derived specifically from the fourth order time derivative of the program metric and represents a snap or jounce associated with changes in the project metric.”)
a processor (Prieto: Paragraph 24, “It should be noted that while the following description is drawn to time derivative-based program management systems and methods, various alternative configurations are also deemed suitable and may employ various computing devices including servers, interfaces, systems, databases, agents, peers, engines, controllers, or other types of computing devices operating individually or collectively. One should appreciate the computing devices comprise a processor configured to execute software instructions stored on a tangible, non-transitory computer readable storage medium (e.g., hard drive, solid state drive, RAM, flash, ROM, etc.). The software instructions preferably configure the computing device to provide the roles, responsibilities, or other functionality as discussed below with respect to the disclosed system. In especially preferred embodiments, the various servers, systems, databases, or interfaces exchange data using standardized protocols or algorithms, possibly based on HTTP, HTTPS, AES, public-private key exchanges, web service APIs, or other electronic information exchanging methods. Data exchanges preferably are conducted over a packet-switched network, the Internet, LAN, WAN, VPN, or other type of packet switched network.”)
acquire data of progress plan including a progress level of the step and an execution timing corresponding thereto; (Prieto: Paragraph 28, “In FIG. 1, program management system 100 comprises of a project database 110, a project analysis engine 120 operatively coupled to the project database 110, and an output device 130. The project database 110, the project analysis engine 120, and the output device 130 can be operatively connected to each other by a network 115. Network 115 can either be a wired or a wireless network and can comprise a WAN, LAN, VPN, the Internet, cellular telephone network, or other types of network. The project database 110, alternatively also referred to as program database 110 hereinafter, can be configured to store one or more project or program metrics 112A, 112B . . . 112N, which define, present, or objectify the progress or characteristics of a project or program. The project metrics 112A . . . 112N, collectively referred to as project metrics 112 hereinafter, can be associated with a program, or one or more projects related to a program, and can include manpower utilized, cost incurred, resources used, logistics, schedule, test, inspection, completion percentage, personnel usage, man-hour usage, among other such program related metrics.”; Paragraph 31, “Further, a higher order time derivative such as a fourth order time derivative of a project metric can indicate the level of efficiency or inefficiency in a program, i.e. the fourth order time derivative can indicate when a program shows sudden or consistent improvement or inefficiency over a period of time. A fourth order time derivative represents the change in third order time derivative and therefore is configured to represent the noise or disruptions caused or detected in the third order time derivative. Thus, the fourth order time derivative can be considered representative of a level of efficiency or inefficiency in the program. The fourth order time derivative can also be used to detect efficiencies in behavior of project metrics over a period of time that are not detected as disruptions by the third order derivative calculations, thereby increasing the sensitivity to change in project metrics over a given time instant. Furthermore, as each project metric represents a different view of the program progress, one metric might not necessarily reflect efficient application of a resource in a project with respect to a particular point of view, whereas other metrics might appear to represent efficient application of different resources. For example, consider cost and man-hours as two project metrics in a project over a small period of time, T. The project could be executed such that, when looked from the perspective of cost as the project metric through analysis of the third order time derivative of cost, it appears to be running smoothly or as planned without any disruptions. Furthermore, it can also be possible that the fourth order time derivative of the cost project metric shows that the metric lacks efficiency and has multiple small duration negative changes in disruptions. In such a case, it can also be possible that when a fourth order time derivative of man-hours is computed for the same time period, the time derivative depicts a strong efficiency with respect to man-hours spent during a portion of time period T with some number of man-hours saved during the portion. Therefore, multiple project metrics or even higher order derivatives of a single metric can yield different views of behavior or impact of the project metric 112 on the program, and as a result, metrics 112 can be treated individually or in combination.”; Paragraph 41, “An achievement curve 132 can be obtained based on one or more project metrics 112 and can represent actual or planned progress or achievement of the project or program. Disruption metric 122, which is presented through one or more disruption indices, can be displayed on an output device 130 with respect to the achievement curve 132 to portray the duration, timestamp, location, severity of disruption or jerk, or other disruptive attributes of the project. As each disruption index is derived from a third order or higher time derivative of the project metric, it represents the change in rate of change (second order time derivative) of the project metric and therefore indicates the actual reason for the disruption or jerk in a project instead of merely indicating the rate of progress of project. Understanding the actual reason behind the jerk can, as a result, help the people and activities responsible for the jerk and assist in taking necessary measures to overcome the inefficiencies. The output device 130 can be a web browser, a cell phone, a tablet, a printer, a computer device or other type of suitable device.”)
acquire data of a progress performance including a progress level of a completed part of the progress plan and an execution timing corresponding thereto; (Prieto: Paragraph 34, “Project metrics 112 can be stored in such a manner that the data relating to these metrics 112 can easily be categorized and retrieved to analyze the project with respect to their progress, resource utilization, among other attributes. For example, a project metric 112 can represent the "percentage of work completed in the project". Although this and other forthcoming embodiments of the present disclosure are explained with respect of this project metric, it would be well appreciated that project metrics can include any parameter that can define or be associated with a project or program. Various other project metrics 112 can, individually or in combination with other, be analyzed to derive their respective third order and fourth order time derivatives to identify disruptions or efficiencies in the project. It has been appreciated by the applicant that a project metric 112 can be presented in a time-series model to explain the change in values of project metric 112 over a defined period of time. Before the project analysis engine 120 processes the project metric 112, the time-series fitted model can also be refined to determine if the model is stationery or presents some seasonality or periodicity in behavior.”; Paragraph 35, “In an embodiment, project analysis engine 120, alternatively also referred to as program analysis engine 120 hereinafter, can be implemented in a server such as a HTTP server or as a web service, PaaS, Iaas, SaaS, cloud or the like. Analysis engine 120 can be configured to access project database 110 to select at least one project metric 112 of a project and calculate a disruption metric 122 as a function of at least a third order time derivative of the project metric. Third order time derivative of a project metric 112, as described above, can be computed by calculating the change in ramp rate or acceleration (second order time derivative) of the concerned project metric 112 with respect to time. Ramp rate represents the change in rate of change of a particular project metric with respect to time. For example, in case the project metric 112 represents % of work completed, change in percentage of work with respect to time, say from 5% to 9% in 5 days (4% per 5 days) and 9% to 11% in the next 5 days (2% per 5 days) represent velocities of the project metric 112 calculated at five day intervals. A ramp rate of change of the project metric 112, on the other hand, represents the acceleration, i.e. the acceleration represents rate of change the velocities (-2% per 5 days) with respect to work completion in 5 days, wherein such acceleration can be computed on a daily basis or according to other desired time interval. Third order time derivative, on the other hand, further evaluates the change in project metric over a period of time and focuses on instantaneous changes in acceleration, which is also commonly referred to as "jerk" in physics. Therefore, increases in acceleration of project metric 112 result in positive values of the third the third order time derivative of project metric 112. Such deviations of actual project metrics from planned values can lead to higher jerks or disruptions, which can be monitored, identified, or evaluated by the third order time derivatives.”)
calculate, based on the data of the progress performance, a performance period from a reference time point of the step to a predetermined time point at which a predetermined progress level was achieved; (Prieto: Paragraph 56, “An actual work completed achievement curve 215 is drawn on graph 200 to represent actual percentage of work completed during the time period T. As has earlier been mentioned, "percentage of work completed" is merely an exemplary project metric 112 and any other project metric such as resource utilized or cost incurred, can be used independently or in combination with other project metrics. In an embodiment, curve 215, can also be referred to as achievement curve 132 interchangeably, whereas in an alternate embodiment, the curve 215 can be different from achievement curve 132 in terms of the manner in which their respective project metrics are processed, evaluated, or analyzed. As can be seen from curve 215, even though projected work to be completed after the first 10 days was 10%, the actual work completed was 9%, leading to a lag of 1%. Similarly, even though the projected work to be completed after the first 30 days was 30%, the actual work completed was 32%, leading to a delta of 2% over the projected schedule. As can be seen, the actual work completed curve 215 merely depicts whether the project metric 112 is ahead of or behind the planned projected curve 210 but does not explain or give any details of the reasons, location, timestamp, or activity giving rise to such a lag or leap. Although this document references "derivatives", one should appreciate that such values can be calculated based on difference in discrete values at points in time.”; Paragraph 57, “Project analysis engine 120 can access project database 110 and fetch data related to "percentage of work completed" as the project metric 112 and compute third order time derivative of the project metric 112. The engine 120 can then generate a disruption metric 122 as a function of the third order time derivative, wherein the disruption metric 122 comprises of a disruption index that is derived from the third order time derivative and represents a jerk or disruption in the project due to the selected project metric 112. The disruption metric 122 can also comprise an efficiency index that is derived from fourth order time derivative of the project metric 112 and represents a snap or jounce or efficiency in the project when seen with respect to the selected project metric 112.”; Paragraph 60, “In the present exemplary embodiment, FIGS. 2A and 2B are shown with respect to each other and map in terms of time vs. project metric behavior. To identify jerk and snap clearly, jerk is represented through a dotted line and snap is represented through a continuous line. As was noticed in FIG. 2A, after the first time period of 10 days, the actual project work completed was 9%, which was a lag of 1% over the projected completion of 10%. FIG. 2B can, for this first time period (i.e., per day), through the disruption and efficiency indices stored in the disruption metric 122, identify and present the reason, location, and severity of the jerk or snap though the magnitude of unit of jerk or snap. For example, it can be noticed from representation 250 that there was a jerk or disruption of 2 units on the 7'th day of the project and a snap or efficiency of 3 units on 9'th day of the project, which lead to an overall percentage of work completion as 9%. A project manager or other stakeholder can, based on the representation 250, point to the event responsible, location, duration, and severity of the jerk (on 7'th day) and snap (on 9'th day) so as to understand the rationale behind the overall behavior of the project metric 112 and take a more informed decision on the project or program including allowing project teams to take necessary steps to improve the identified reasons for jerks. Reasons for disruption and efficiency can be measured and evaluated based on the details of the activities undertaken during the days or time of jerk or snap. In an embodiment, multiple project metrics can be evaluated simultaneously to assess and evaluate one or a combination of parameters that affect the project.”)
calculate, based on the data of the progress plan, a plan period from the reference time point of the step to a time point at which a progress level same as the predetermined progress level is achieved; (Prieto: Paragraph 13, “The inventive subject matter is considered to include a project management system comprising a project database and a project analysis engine operatively coupled with the project database. The project database can be configured to store project metrics with respect to time, wherein the project metrics are associated with a program, or projects related to a program, and can include cost incurred, resources utilized, schedule, completion percentage, personnel usage, man-hour usage, or such parameters that define or characterize attributes of the program. The project analysis engine can be configured to access the project database to select at least one of the project metrics of the project and calculate a disruption metric as a function of at least a third order time derivative of the project metric. The disruption metric can include a disruption index, which is defined to be derived specifically from the third order time derivative of the project metric and which represents jerk or disruption changes in the project metric in the project. A project achievement curve (e.g., planned loading curve, estimated progress curve, etc.), can be obtained based on the project metric and can be displayed on an output device with respect to the disruption metric to portray the duration, timestamp, location, severity of disruption or jerk, or other disruptive aspect of the program. Further, the distribution metric can include an efficiency index, which is defined to be derived specifically from the fourth order time derivative of the program metric and represents a snap or jounce associated with changes in the project metric.”; Paragraph 33, “Further, apart from conventional project metrics, a number of new or customized project metrics can be defined where analysis of one or a combination such introduced project metrics can throw deeper insights into the execution, planning, or implementation of a program. Certain exemplary project metrics can include email communications of program or project teams, text messages, employee retention, recruitment pattern, inputs from multiple project management tools, quality reviews and number of defects, extent of rework, stakeholder involvement, impact on management, change in scope, cost-performance indicator, schedule performance index (SPI), sensor outputs, response times, an index indicating comparison between planned value (PV), actual cost (AC) and Earned Value (EV), or other such measures that are directly or indirectly indicative of the above.”; Paragraph 39, “As has been described above, project metrics 112 can also include multiple user defined metrics, third order time derivatives of which can be used to flag abrupt or disruptive events. For example, change in rate of exchange of emails between two parties involved in a particular project can be an indicator of a disruption in the project, specifically in the activity defined in the subject line of the emails. Disruption index can therefore be derived based on the third order time derivative of email project metric and an appropriate action can be taken. Furthermore, it should be appreciated that a disruption can also exist or take place in case there is no jerk in a particular project metric over a defined period of time. For example, in case an activity was planned to be initiated on 15'th July, which was expected to raise the cost of the project by USD 500,000, the lack of change in the rate of change of the cost project metric till 18'th July could mean a disruption in the project and a possible suggestion of non-initiation of the activity. In this example, the farther the date of non-change in cost project metric is from 15'th July, the higher can be the value of the disruption index. In other words, a delay in a start date can be an indicator of future disruptions.”; Paragraph 42, “Achievement curve 132 can also be obtained based on planned values for project metrics 112 such as planned schedule, cost, expenditure rates, man-hours, installation rates, or earned value, before or after initiation of the project. Multiple achievement curves 132 can also be represented at the output device 130 for one or a combination of project metrics 112. In another instance, achievement curve 132 can also be modeled or simulated based on previous similar projects, projections of subject matter experts who can make objective assumptions around efficiency with which certain activities would be carried out and also efficiency with which transition between activities would take place (start:stop; ramp-up:ramp-down), or known simulation models such as Monte Carlo techniques. Therefore, achievement curve 132 could be built based on a statistical aggregation of model programs or projects from Monte Carlo simulations. Project metric data that is represented with respect to time by the achievement curve can be hereinafter referred to as baseline data.”)
calculate, based on the performance period and the plan period, a progress evaluation index regarding progress of the step; and (Prieto: Paragraph 42, “Achievement curve 132 can also be obtained based on planned values for project metrics 112 such as planned schedule, cost, expenditure rates, man-hours, installation rates, or earned value, before or after initiation of the project. Multiple achievement curves 132 can also be represented at the output device 130 for one or a combination of project metrics 112. In another instance, achievement curve 132 can also be modeled or simulated based on previous similar projects, projections of subject matter experts who can make objective assumptions around efficiency with which certain activities would be carried out and also efficiency with which transition between activities would take place (start:stop; ramp-up:ramp-down), or known simulation models such as Monte Carlo techniques. Therefore, achievement curve 132 could be built based on a statistical aggregation of model programs or projects from Monte Carlo simulations. Project metric data that is represented with respect to time by the achievement curve can be hereinafter referred to as baseline data.”; Paragraph 43, “Achievement curve 132 can be represented as a mathematical equation (e.g., a curve, a fitted curve to actual data, fitted curve simulation data, hybrid data, etc.), which aims to represent utilization of resources over the proposed time of the project. The curve 132 can also be illustrated as a combination of two or more curves that help represent side by side comparisons of actual time and expenditure components (actual project metric values) vs. proposed time and costs allocations of specific resources (planned values for the project metrics).”; Paragraph 54, “FIGS. 2A and 2B illustrate exemplary graphs showing disruption or jerk or efficiency or snap or jounce in a project through analysis of a project metric 112 with respect to time. In the present disclosure, as an exemplary illustration, the graphs are drawn for "percentage of work completed" as the project metric 112. The graphs can help in understanding the disruptions or efficiencies that occur during a project. FIG. 2A illustrates a projected achievement curve 210 for a project metric 112 (percentage of work completed for example) with respect to time and also illustrates the actual obtained achievement curve 215 for the project metric 112 of the project, plotted over percentage of work completed against time period in two axis. FIG. 2B, on the other hand, through disruption metric 122 comprising one or more disruption and efficiency indices, illustrates the magnitude and location of jerk or snap in the project. FIG. 2A and FIG. 2B can be described in a better manner as below.”)
predict, based on the progress evaluation index, data of the progress performance after the predetermined time point= wherein the project includes, as the at least one step, a preceding first step and a subsequent second step, (Prieto: Paragraph 55, “FIG. 2A illustrates a graph 200 for percentage of work completed over time period T. In the present exemplary embodiment, "percentage of work completed" depicts a project metric 112 and is expressed as work completion percentage taken along Y axis. Amount of time taken to finish the specified amount of work is illustrated on X axis as time period T of the project. For illustration and simplicity, percentage of work completed is divided into 10 divisions, wherein each division indicates 10% of project work completed. Time period T along X axis can be divided into number of days after which the work rate is to be calculated and in the present illustration, the defined time period interval is 10 days. Therefore, after every 10 days, the percentage work completed is calculated for the present illustration. A projected work completion achievement curve 210 presenting the expected progress of the project can be estimated and drawn on the graph 200. Curve 210 can be drawn and defined before the project is initiated. The projected work completion curve 210 represents the percentage of work expected to be completed at defined time period intervals. For example, in the present illustration of FIG. 2, 10% of work involved in the project is expected to be completed within first 10 days and 50% of the work is expected to be completed within 50 days from initiation of the project. This work rate, in the present illustration, would lead to 100% work completion after 100 days. Therefore, a project or program manager or a user can plan that the project will be completed in 100 days and that the project be monitored after every 10 days to understand the progress of the program.”; Paragraph 69, “Project analysis engine 120 can generate a disruption metric 122 comprising mean square derivative (MSD) value of fourth order time derivative of one or more project metrics 112 of a program, wherein mean square derivative (MSD) value is a sum of squares of periodic efficiency values or snaps observed over a number of time periods. MSD value can be computed by calculating fourth order time derivatives of a project metric at periodic time intervals (such as daily) of a defined duration of project execution (such as 1 month) and then calculating mean of the derivative values. MSD value can be stored in the disruption metric 122 along with disruption and efficiency indices. Efficiency index can also be configured to include an absolute value derived from the fourth order time derivative of one or more project metrics 112. Such absolute values have already been illustrated in FIG. 2B. In another implementation, efficiency index can include cumulative efficiency or inefficiency over a defined period of time, wherein the cumulative efficiency can include a sum of all absolute values derived from the fourth order time derivatives for the defined period.”; Paragraph 70, “FIG. 3A represent an S-curve 315 with respect to a project metric 112 such as man-hours and time. Any other suitable project metric based on output, cost, scope of work, procurement, logistics, risk, communication, human resource plan, quality, or number of activities can also be incorporated. S-curve 315 is an S-shaped graph produced by Sigmoid formula which calculates the cumulative expenditure of certain project metrics against time. S-curve 315 is typically used against estimates such as projections or budgets on such project metrics 112. The projected curve 310 represents the projections of total number of man-hours planned to be used over the period of 100 days of the project. For simplicity, the projected curve 310 has been shown with a slope of 1, with 10% of the work intended to be covered in 10 days and 100% of the work intended to be covered in 100 days. As can be seen, the S-curve 315 typically represents a slow start and a slow finish with varying acceleration in between, wherein the man-hours consumed are lower than projected in the first half and higher in the second half. For example, after 30 days the number of man-hours to be consumed is planned to be 30 and the actual consumption is 15. Similarly, after 90 days, the number of man-hours to be consumed is planned to be 90 and the actual consumption is 98.”; Paragraph 73, “As a can be seen, the efficiency index or snap can have actual values from negative to positive, wherein the negative values can indicate inefficiencies (such as undesirable disruptions or events leading to lag in projects) and positive values can indicate efficiencies such as on-time or before time start of new activities, email communications indicating no change in scope of an activity, reduction in man-hours, among others. Furthermore, magnitude of efficiency index, as shown on Y axis can indicate the level of efficiency, which can be compared with defined thresholds, so as to take necessary action for highlighting the event responsible, activities undertaken in the event, people responsible for those activities, duration of those activities, importance of each of those activities, and correct or continue the activities depending on efficiency or inefficiency. It should also be noted that, in the present illustration of FIG. 3C, the frequency of efficiency or inefficiency is more in the middle of the time duration of 10 days and highest around the 5'th day, whereas the frequency of variation is relatively lower in the beginning and in the end. However, such a representation is purely project or program specific and can vary.”)
wherein the step is the second step, (Prieto: Paragraph 13, “The inventive subject matter is considered to include a project management system comprising a project database and a project analysis engine operatively coupled with the project database. The project database can be configured to store project metrics with respect to time, wherein the project metrics are associated with a program, or projects related to a program, and can include cost incurred, resources utilized, schedule, completion percentage, personnel usage, man-hour usage, or such parameters that define or characterize attributes of the program. The project analysis engine can be configured to access the project database to select at least one of the project metrics of the project and calculate a disruption metric as a function of at least a third order time derivative of the project metric. The disruption metric can include a disruption index, which is defined to be derived specifically from the third order time derivative of the project metric and which represents jerk or disruption changes in the project metric in the project. A project achievement curve (e.g., planned loading curve, estimated progress curve, etc.), can be obtained based on the project metric and can be displayed on an output device with respect to the disruption metric to portray the duration, timestamp, location, severity of disruption or jerk, or other disruptive aspect of the program. Further, the distribution metric can include an efficiency index, which is defined to be derived specifically from the fourth order time derivative of the program metric and represents a snap or jounce associated with changes in the project metric.”)
and the processor is further configured to: acquire information of at least one first milestone in the first step and information of a second milestone corresponding to each first milestone in terms of timing in the second step; (Prieto: Paragraph 55, “FIG. 2A illustrates a graph 200 for percentage of work completed over time period T. In the present exemplary embodiment, "percentage of work completed" depicts a project metric 112 and is expressed as work completion percentage taken along Y axis. Amount of time taken to finish the specified amount of work is illustrated on X axis as time period T of the project. For illustration and simplicity, percentage of work completed is divided into 10 divisions, wherein each division indicates 10% of project work completed. Time period T along X axis can be divided into number of days after which the work rate is to be calculated and in the present illustration, the defined time period interval is 10 days. Therefore, after every 10 days, the percentage work completed is calculated for the present illustration. A projected work completion achievement curve 210 presenting the expected progress of the project can be estimated and drawn on the graph 200. Curve 210 can be drawn and defined before the project is initiated. The projected work completion curve 210 represents the percentage of work expected to be completed at defined time period intervals. For example, in the present illustration of FIG. 2, 10% of work involved in the project is expected to be completed within first 10 days and 50% of the work is expected to be completed within 50 days from initiation of the project. This work rate, in the present illustration, would lead to 100% work completion after 100 days. Therefore, a project or program manager or a user can plan that the project will be completed in 100 days and that the project be monitored after every 10 days to understand the progress of the program.”; Paragraph 56, “An actual work completed achievement curve 215 is drawn on graph 200 to represent actual percentage of work completed during the time period T. As has earlier been mentioned, "percentage of work completed" is merely an exemplary project metric 112 and any other project metric such as resource utilized or cost incurred, can be used independently or in combination with other project metrics. In an embodiment, curve 215, can also be referred to as achievement curve 132 interchangeably, whereas in an alternate embodiment, the curve 215 can be different from achievement curve 132 in terms of the manner in which their respective project metrics are processed, evaluated, or analyzed. As can be seen from curve 215, even though projected work to be completed after the first 10 days was 10%, the actual work completed was 9%, leading to a lag of 1%. Similarly, even though the projected work to be completed after the first 30 days was 30%, the actual work completed was 32%, leading to a delta of 2% over the projected schedule. As can be seen, the actual work completed curve 215 merely depicts whether the project metric 112 is ahead of or behind the planned projected curve 210 but does not explain or give any details of the reasons, location, timestamp, or activity giving rise to such a lag or leap. Although this document references "derivatives", one should appreciate that such values can be calculated based on difference in discrete values at points in time.”; Paragraph 66, “Project analysis engine 120 can be configured to generate recommendations to a project manager to manage disruption metric 122 in a program based on comparison between projected curve 210 and an actual curve 215, wherein the recommendations can comprise actions to minimize disruptions or maximize snaps in the program. The project analysis engine 120 can also help in optimizing disruption metric 122 of one or more project metrics 112 based on needs of the program manager. In some embodiments, analysis engine 120 can compare characteristics of disruption or efficiency indices (e.g., jerk and snap respectively) to known event signatures. When the characteristics suitably match such signatures, analysis engine 120 can construct a notification or recommendation on corrective actions as derived from information stored within or associated with the known event signatures.”)
accumulate the data of the progress performance of each of multiple completed projects; (Prieto: Paragraph 63, “Graphs 200 and 250 in FIGS. 2A and 2B of the present embodiment are drawn and described with respect to a projected achievement curve 210 and an actual achievement curve 215 for a defined project metric 112 and show disruptions and efficiencies in the program through disruption and efficiency indices (represented as unit or magnitude of jerk or snap). In some embodiments the projected curve 210 can be generated through a predetermined execution model stored in the project analysis engine 120 and can be indicative of the pattern of execution of the project proposed by the manager before initiation of the project or program. Projected curve 210 can also be planned based on historical project or program information, inputs from subject matter experts, budget involved, among other parameters. A plurality of patterns of proposed execution models can be stored in the project analysis engine 120 and the project analysis engine 120 can be configured to select one of the proposed execution models from the plurality of execution models. The proposed execution model can be related to one or more project metrics 112 or can be independent of the metrics 112.”; Paragraph 42, “Achievement curve 132 can also be obtained based on planned values for project metrics 112 such as planned schedule, cost, expenditure rates, man-hours, installation rates, or earned value, before or after initiation of the project. Multiple achievement curves 132 can also be represented at the output device 130 for one or a combination of project metrics 112. In another instance, achievement curve 132 can also be modeled or simulated based on previous similar projects, projections of subject matter experts who can make objective assumptions around efficiency with which certain activities would be carried out and also efficiency with which transition between activities would take place (start:stop; ramp-up:ramp-down), or known simulation models such as Monte Carlo techniques. Therefore, achievement curve 132 could be built based on a statistical aggregation of model programs or projects from Monte Carlo simulations. Project metric data that is represented with respect to time by the achievement curve can be hereinafter referred to as baseline data.”)
calculate a corrected evaluation index which is obtained by correcting the progress evaluation index of the second step based on the influence evaluation model at the predetermined time point; and . (Prieto: Paragraph 74, “The system 100 can further be configured to generate signatures based on certain trends, types, or magnitudes of disruptions, efficiencies, or inefficiencies and store such signatures in program database 110. Such signatures can be generated based on experience of subject matter experts on anticipated disruptions or efficiencies, previous signatures in same or other programs, or common types of jerks or snaps that are generated in a particular type of project. The signatures can either be stored in the database 110 in an encoded format or any other known format, which can help their efficient retrieval or processing by the program analysis engine 120. The signatures can also be updated or new signatures can be formed as the program proceeds over a period time, wherein such update or formation can be based on earlier disruptions detected in the same program, new learning from other parts of the program or from other projects in the same program. The signatures can be configured to store disruption or efficiency characteristics along with their possible reasons and resolutions. The database 110 can be configured to classify the signatures based on whether they relate to efficiencies or disruptions, type of program or project, project metrics involved, % of confidence in suggested resolution or other parameters.”; Paragraph 76, “FIG. 4 presents a method 400 for program management to identify disruptions or efficiencies in a program or project with respect to one or a combination of project metrics of the program. Step 410 can include providing access to a project database that stores project metric objects of one or more project metrics. The project metrics can include manpower; cost incurred; resources utilized; logistics; schedule; test; inspection work, project, program completion percentage; personnel usage; email communication; earned value; man-hour usage; or other program related metrics; wherein the project metric objects can include data related to the project metrics obtained at a particular time period.”; Paragraph 78, “Step 430 includes the analysis engine deriving a disruption metric based on at least a third order time derivative of a project metric that is stored in the project metric database. The selected project metric of the program can be analyzed by reading project metric data over a time period and calculating a third order time derivative of the project metric at one or more time points to assess whether a jerk has happened in the program at any of those time points. Each jerk can represent a disruption (desired or undesired) that occurs the program. The disruption metric can be generated as a function of the third order time derivative of the project metric, and can be represented as f(d.sup.3PM/dt.sup.3), where PM represents the selected project metric. It should be appreciated that although the disruption metric has been described in the present disclosure as a function of the third order time derivative of the project metric, which indicates an indirect computation of the metric from the project metric, the disruption metric can also be directly implemented as equal in value to the third order time derivative of the project metric rather than being a function thereof. Alternatively, based on the project metric involved and program characteristics, the disruption metric can also be computed as a third order time derivative including a constant or offset value. Furthermore, the disruption metric can also represent multiple third order time derivatives of the project metric across different time periods and store them together as part of the metric.”)
in prediction of the data of the progress performance regarding the second step, predict, based on the corrected evaluation index, the data of the progress performance after the predetermined time point in the second step. . (Prieto: Paragraph 74, “The system 100 can further be configured to generate signatures based on certain trends, types, or magnitudes of disruptions, efficiencies, or inefficiencies and store such signatures in program database 110. Such signatures can be generated based on experience of subject matter experts on anticipated disruptions or efficiencies, previous signatures in same or other programs, or common types of jerks or snaps that are generated in a particular type of project. The signatures can either be stored in the database 110 in an encoded format or any other known format, which can help their efficient retrieval or processing by the program analysis engine 120. The signatures can also be updated or new signatures can be formed as the program proceeds over a period time, wherein such update or formation can be based on earlier disruptions detected in the same program, new learning from other parts of the program or from other projects in the same program. The signatures can be configured to store disruption or efficiency characteristics along with their possible reasons and resolutions. The database 110 can be configured to classify the signatures based on whether they relate to efficiencies or disruptions, type of program or project, project metrics involved, % of confidence in suggested resolution or other parameters.”; Paragraph 76, “FIG. 4 presents a method 400 for program management to identify disruptions or efficiencies in a program or project with respect to one or a combination of project metrics of the program. Step 410 can include providing access to a project database that stores project metric objects of one or more project metrics. The project metrics can include manpower; cost incurred; resources utilized; logistics; schedule; test; inspection work, project, program completion percentage; personnel usage; email communication; earned value; man-hour usage; or other program related metrics; wherein the project metric objects can include data related to the project metrics obtained at a particular time period.”; Paragraph 78, “Step 430 includes the analysis engine deriving a disruption metric based on at least a third order time derivative of a project metric that is stored in the project metric database. The selected project metric of the program can be analyzed by reading project metric data over a time period and calculating a third order time derivative of the project metric at one or more time points to assess whether a jerk has happened in the program at any of those time points. Each jerk can represent a disruption (desired or undesired) that occurs the program. The disruption metric can be generated as a function of the third order time derivative of the project metric, and can be represented as f(d.sup.3PM/dt.sup.3), where PM represents the selected project metric. It should be appreciated that although the disruption metric has been described in the present disclosure as a function of the third order time derivative of the project metric, which indicates an indirect computation of the metric from the project metric, the disruption metric can also be directly implemented as equal in value to the third order time derivative of the project metric rather than being a function thereof. Alternatively, based on the project metric involved and program characteristics, the disruption metric can also be computed as a third order time derivative including a constant or offset value. Furthermore, the disruption metric can also represent multiple third order time derivatives of the project metric across different time periods and store them together as part of the metric.”)
Prieto does not explicitly disclose the following, however, in analogous art of project management, Davies discloses the following:
acquire an influence evaluation model that represents influence of relationship between data regarding each first milestone in the data of the progress performance of the first step and data regarding the corresponding second milestone in the data of the progress performance of the second step on the progress evaluation index of the second step, wherein the influence evaluation model is determined based on the data of the progress performance that has been accumulated, and wherein the influence evaluation model is a third machine learning model that has learned a relationship between the data of the progress performance that has been accumulated and the progress evaluation index of the second step; (Davies: Paragraph 44, “Once the team setup has been completed and/or approved by the client 101, module 110 generates 208 a plan for the completion of the requested project. The plan establishes the project time line, the order of tasks, the milestones of the project, invoicing schedule, establishing the communication between the client 101 and resource(s) 105 as well as the resource(s) 105 and other resource(s) 105 in tasks which are related, and the other factors which the requested project is to be completed on/by. In some embodiments, the module 110 accesses a project history database 107 which provides previously completed projects of similarity to establish a plan that is realistic based on previously record data. To determine the time specific task may take, tentative fees or prices for the tasks (or project as a whole), and other variables about the project which are requested by the client 101, required by the module 110, or important to establish prior to beginning the project.”; Paragraph 47, “In additional embodiments, when a task is not completed 216 on time, the module 110 enables dynamic revision to a given project plan based on changes to a task due date that has dependencies cause downstream impact (Plan management) or initiated based on clients 101 demand. The module 110 analyzes the impacts and is able to assess to see any changes to end delivery date and recommend new target dates to following resource(s) 105 task delivery. Based on the resource(s) 105 responses to recommended changes, the plan can either be delivered to plan or delivered to the new date (requiring client change management.)”; Paragraph 61, “In an example where the activity/task can be completed internally, the module compiles 406, the data for the action. Executes 408 the steps, procedures, or processes which are necessary to complete the task. The module 110 then manages 410 the asset in relation to the parties and the project.”; Paragraph 57, “The module 110 is continuously, and in some embodiments automatically, processing the updates and assets from the parties through a task progress monitoring system 309. The task progress monitoring system 309 evaluates the progress and risk for a given task and, in some embodiments the overall project. The task progress monitoring system 309 is constantly assessed while a task is active and can trigger targeted communications to the client 101 or resource(s) 105, the more detailed escalation and change asset management service 312 if concerns are identified, when a task is completed this service triggers a project process check 320 and hand off to the next task/project close out functionality. For example, the task progress monitoring system 309 may provide schedule assessment, resource engagement, client 101 sentiment, resource(s) 105 sentiment, task completion, dependency risk, and the like. Based on the assessment of the task progress monitoring system 309, the module 110 can determine an appropriate reaction to the client 101 and the resource(s) 105 actions. The module 110 is able to process a sentiment issues 314 determined by the task progress monitoring system 309 process an escalation assessment 322 (FIG. 6), wherein an escalation risk score is calculated, and a determination is made if a third-party intervention is required. The module 110 is able to determine where a task is delayed 318, how the delay affects the overall project, and if this delay results in an adjustment to the escalation 322 of the project.”)
Prieto discloses a method of determining progress and predictions of a project based on various acquired data values. Davies discloses a method for managing the monitoring the workflow of a project.. At the time of Applicant’s filed invention, one of ordinary skill in the art would have deemed it obvious to combine the methods of Prieto with the teachings of Davies in order to improve the planning and execution of projects as disclosed by Davies (Davies: Paragraph 5, “Therefore, it is desired for a method, computer program, or computer system to create a central system to plan the project, connect the resources, establish a timeline and project deliverables, all while maintaining communication between parties and monitor task completions, and project adjustments.”)
Claim 16 –
Prieto discloses the following:
acquiring data of a progress plan including a progress level of the step and an execution timing corresponding thereto; (Prieto: Paragraph 28, “In FIG. 1, program management system 100 comprises of a project database 110, a project analysis engine 120 operatively coupled to the project database 110, and an output device 130. The project database 110, the project analysis engine 120, and the output device 130 can be operatively connected to each other by a network 115. Network 115 can either be a wired or a wireless network and can comprise a WAN, LAN, VPN, the Internet, cellular telephone network, or other types of network. The project database 110, alternatively also referred to as program database 110 hereinafter, can be configured to store one or more project or program metrics 112A, 112B . . . 112N, which define, present, or objectify the progress or characteristics of a project or program. The project metrics 112A . . . 112N, collectively referred to as project metrics 112 hereinafter, can be associated with a program, or one or more projects related to a program, and can include manpower utilized, cost incurred, resources used, logistics, schedule, test, inspection, completion percentage, personnel usage, man-hour usage, among other such program related metrics.”; Paragraph 31, “Further, a higher order time derivative such as a fourth order time derivative of a project metric can indicate the level of efficiency or inefficiency in a program, i.e. the fourth order time derivative can indicate when a program shows sudden or consistent improvement or inefficiency over a period of time. A fourth order time derivative represents the change in third order time derivative and therefore is configured to represent the noise or disruptions caused or detected in the third order time derivative. Thus, the fourth order time derivative can be considered representative of a level of efficiency or inefficiency in the program. The fourth order time derivative can also be used to detect efficiencies in behavior of project metrics over a period of time that are not detected as disruptions by the third order derivative calculations, thereby increasing the sensitivity to change in project metrics over a given time instant. Furthermore, as each project metric represents a different view of the program progress, one metric might not necessarily reflect efficient application of a resource in a project with respect to a particular point of view, whereas other metrics might appear to represent efficient application of different resources. For example, consider cost and man-hours as two project metrics in a project over a small period of time, T. The project could be executed such that, when looked from the perspective of cost as the project metric through analysis of the third order time derivative of cost, it appears to be running smoothly or as planned without any disruptions. Furthermore, it can also be possible that the fourth order time derivative of the cost project metric shows that the metric lacks efficiency and has multiple small duration negative changes in disruptions. In such a case, it can also be possible that when a fourth order time derivative of man-hours is computed for the same time period, the time derivative depicts a strong efficiency with respect to man-hours spent during a portion of time period T with some number of man-hours saved during the portion. Therefore, multiple project metrics or even higher order derivatives of a single metric can yield different views of behavior or impact of the project metric 112 on the program, and as a result, metrics 112 can be treated individually or in combination.”; Paragraph 41, “An achievement curve 132 can be obtained based on one or more project metrics 112 and can represent actual or planned progress or achievement of the project or program. Disruption metric 122, which is presented through one or more disruption indices, can be displayed on an output device 130 with respect to the achievement curve 132 to portray the duration, timestamp, location, severity of disruption or jerk, or other disruptive attributes of the project. As each disruption index is derived from a third order or higher time derivative of the project metric, it represents the change in rate of change (second order time derivative) of the project metric and therefore indicates the actual reason for the disruption or jerk in a project instead of merely indicating the rate of progress of project. Understanding the actual reason behind the jerk can, as a result, help the people and activities responsible for the jerk and assist in taking necessary measures to overcome the inefficiencies. The output device 130 can be a web browser, a cell phone, a tablet, a printer, a computer device or other type of suitable device.”)
acquiring data of progress performance including a progress level of a completed part of the progress plan and an execution timing corresponding thereto; (Prieto: Paragraph 34, “Project metrics 112 can be stored in such a manner that the data relating to these metrics 112 can easily be categorized and retrieved to analyze the project with respect to their progress, resource utilization, among other attributes. For example, a project metric 112 can represent the "percentage of work completed in the project". Although this and other forthcoming embodiments of the present disclosure are explained with respect of this project metric, it would be well appreciated that project metrics can include any parameter that can define or be associated with a project or program. Various other project metrics 112 can, individually or in combination with other, be analyzed to derive their respective third order and fourth order time derivatives to identify disruptions or efficiencies in the project. It has been appreciated by the applicant that a project metric 112 can be presented in a time-series model to explain the change in values of project metric 112 over a defined period of time. Before the project analysis engine 120 processes the project metric 112, the time-series fitted model can also be refined to determine if the model is stationery or presents some seasonality or periodicity in behavior.”; Paragraph 35, “In an embodiment, project analysis engine 120, alternatively also referred to as program analysis engine 120 hereinafter, can be implemented in a server such as a HTTP server or as a web service, PaaS, Iaas, SaaS, cloud or the like. Analysis engine 120 can be configured to access project database 110 to select at least one project metric 112 of a project and calculate a disruption metric 122 as a function of at least a third order time derivative of the project metric. Third order time derivative of a project metric 112, as described above, can be computed by calculating the change in ramp rate or acceleration (second order time derivative) of the concerned project metric 112 with respect to time. Ramp rate represents the change in rate of change of a particular project metric with respect to time. For example, in case the project metric 112 represents % of work completed, change in percentage of work with respect to time, say from 5% to 9% in 5 days (4% per 5 days) and 9% to 11% in the next 5 days (2% per 5 days) represent velocities of the project metric 112 calculated at five day intervals. A ramp rate of change of the project metric 112, on the other hand, represents the acceleration, i.e. the acceleration represents rate of change the velocities (-2% per 5 days) with respect to work completion in 5 days, wherein such acceleration can be computed on a daily basis or according to other desired time interval. Third order time derivative, on the other hand, further evaluates the change in project metric over a period of time and focuses on instantaneous changes in acceleration, which is also commonly referred to as "jerk" in physics. Therefore, increases in acceleration of project metric 112 result in positive values of the third the third order time derivative of project metric 112. Such deviations of actual project metrics from planned values can lead to higher jerks or disruptions, which can be monitored, identified, or evaluated by the third order time derivatives.”)
calculating, based on the data of the progress performance, a performance period from a reference time point of the step to a predetermined time point at which a predetermined progress level was achieved; (Prieto: Paragraph 56, “An actual work completed achievement curve 215 is drawn on graph 200 to represent actual percentage of work completed during the time period T. As has earlier been mentioned, "percentage of work completed" is merely an exemplary project metric 112 and any other project metric such as resource utilized or cost incurred, can be used independently or in combination with other project metrics. In an embodiment, curve 215, can also be referred to as achievement curve 132 interchangeably, whereas in an alternate embodiment, the curve 215 can be different from achievement curve 132 in terms of the manner in which their respective project metrics are processed, evaluated, or analyzed. As can be seen from curve 215, even though projected work to be completed after the first 10 days was 10%, the actual work completed was 9%, leading to a lag of 1%. Similarly, even though the projected work to be completed after the first 30 days was 30%, the actual work completed was 32%, leading to a delta of 2% over the projected schedule. As can be seen, the actual work completed curve 215 merely depicts whether the project metric 112 is ahead of or behind the planned projected curve 210 but does not explain or give any details of the reasons, location, timestamp, or activity giving rise to such a lag or leap. Although this document references "derivatives", one should appreciate that such values can be calculated based on difference in discrete values at points in time.”; Paragraph 57, “Project analysis engine 120 can access project database 110 and fetch data related to "percentage of work completed" as the project metric 112 and compute third order time derivative of the project metric 112. The engine 120 can then generate a disruption metric 122 as a function of the third order time derivative, wherein the disruption metric 122 comprises of a disruption index that is derived from the third order time derivative and represents a jerk or disruption in the project due to the selected project metric 112. The disruption metric 122 can also comprise an efficiency index that is derived from fourth order time derivative of the project metric 112 and represents a snap or jounce or efficiency in the project when seen with respect to the selected project metric 112.”; Paragraph 60, “In the present exemplary embodiment, FIGS. 2A and 2B are shown with respect to each other and map in terms of time vs. project metric behavior. To identify jerk and snap clearly, jerk is represented through a dotted line and snap is represented through a continuous line. As was noticed in FIG. 2A, after the first time period of 10 days, the actual project work completed was 9%, which was a lag of 1% over the projected completion of 10%. FIG. 2B can, for this first time period (i.e., per day), through the disruption and efficiency indices stored in the disruption metric 122, identify and present the reason, location, and severity of the jerk or snap though the magnitude of unit of jerk or snap. For example, it can be noticed from representation 250 that there was a jerk or disruption of 2 units on the 7'th day of the project and a snap or efficiency of 3 units on 9'th day of the project, which lead to an overall percentage of work completion as 9%. A project manager or other stakeholder can, based on the representation 250, point to the event responsible, location, duration, and severity of the jerk (on 7'th day) and snap (on 9'th day) so as to understand the rationale behind the overall behavior of the project metric 112 and take a more informed decision on the project or program including allowing project teams to take necessary steps to improve the identified reasons for jerks. Reasons for disruption and efficiency can be measured and evaluated based on the details of the activities undertaken during the days or time of jerk or snap. In an embodiment, multiple project metrics can be evaluated simultaneously to assess and evaluate one or a combination of parameters that affect the project.”)
calculating, based on the data of the progress plan, a plan period from the reference time point of the step to a time point at which a progress level same as the predetermined progress level is achieved; (Prieto: Paragraph 13, “The inventive subject matter is considered to include a project management system comprising a project database and a project analysis engine operatively coupled with the project database. The project database can be configured to store project metrics with respect to time, wherein the project metrics are associated with a program, or projects related to a program, and can include cost incurred, resources utilized, schedule, completion percentage, personnel usage, man-hour usage, or such parameters that define or characterize attributes of the program. The project analysis engine can be configured to access the project database to select at least one of the project metrics of the project and calculate a disruption metric as a function of at least a third order time derivative of the project metric. The disruption metric can include a disruption index, which is defined to be derived specifically from the third order time derivative of the project metric and which represents jerk or disruption changes in the project metric in the project. A project achievement curve (e.g., planned loading curve, estimated progress curve, etc.), can be obtained based on the project metric and can be displayed on an output device with respect to the disruption metric to portray the duration, timestamp, location, severity of disruption or jerk, or other disruptive aspect of the program. Further, the distribution metric can include an efficiency index, which is defined to be derived specifically from the fourth order time derivative of the program metric and represents a snap or jounce associated with changes in the project metric.”; Paragraph 33, “Further, apart from conventional project metrics, a number of new or customized project metrics can be defined where analysis of one or a combination such introduced project metrics can throw deeper insights into the execution, planning, or implementation of a program. Certain exemplary project metrics can include email communications of program or project teams, text messages, employee retention, recruitment pattern, inputs from multiple project management tools, quality reviews and number of defects, extent of rework, stakeholder involvement, impact on management, change in scope, cost-performance indicator, schedule performance index (SPI), sensor outputs, response times, an index indicating comparison between planned value (PV), actual cost (AC) and Earned Value (EV), or other such measures that are directly or indirectly indicative of the above.”; Paragraph 39, “As has been described above, project metrics 112 can also include multiple user defined metrics, third order time derivatives of which can be used to flag abrupt or disruptive events. For example, change in rate of exchange of emails between two parties involved in a particular project can be an indicator of a disruption in the project, specifically in the activity defined in the subject line of the emails. Disruption index can therefore be derived based on the third order time derivative of email project metric and an appropriate action can be taken. Furthermore, it should be appreciated that a disruption can also exist or take place in case there is no jerk in a particular project metric over a defined period of time. For example, in case an activity was planned to be initiated on 15'th July, which was expected to raise the cost of the project by USD 500,000, the lack of change in the rate of change of the cost project metric till 18'th July could mean a disruption in the project and a possible suggestion of non-initiation of the activity. In this example, the farther the date of non-change in cost project metric is from 15'th July, the higher can be the value of the disruption index. In other words, a delay in a start date can be an indicator of future disruptions.”; Paragraph 42, “Achievement curve 132 can also be obtained based on planned values for project metrics 112 such as planned schedule, cost, expenditure rates, man-hours, installation rates, or earned value, before or after initiation of the project. Multiple achievement curves 132 can also be represented at the output device 130 for one or a combination of project metrics 112. In another instance, achievement curve 132 can also be modeled or simulated based on previous similar projects, projections of subject matter experts who can make objective assumptions around efficiency with which certain activities would be carried out and also efficiency with which transition between activities would take place (start:stop; ramp-up:ramp-down), or known simulation models such as Monte Carlo techniques. Therefore, achievement curve 132 could be built based on a statistical aggregation of model programs or projects from Monte Carlo simulations. Project metric data that is represented with respect to time by the achievement curve can be hereinafter referred to as baseline data.”)
calculating, based on the performance period and the plan period, a progress evaluation index regarding progress of the step; and (Prieto: Paragraph 42, “Achievement curve 132 can also be obtained based on planned values for project metrics 112 such as planned schedule, cost, expenditure rates, man-hours, installation rates, or earned value, before or after initiation of the project. Multiple achievement curves 132 can also be represented at the output device 130 for one or a combination of project metrics 112. In another instance, achievement curve 132 can also be modeled or simulated based on previous similar projects, projections of subject matter experts who can make objective assumptions around efficiency with which certain activities would be carried out and also efficiency with which transition between activities would take place (start:stop; ramp-up:ramp-down), or known simulation models such as Monte Carlo techniques. Therefore, achievement curve 132 could be built based on a statistical aggregation of model programs or projects from Monte Carlo simulations. Project metric data that is represented with respect to time by the achievement curve can be hereinafter referred to as baseline data.”; Paragraph 43, “Achievement curve 132 can be represented as a mathematical equation (e.g., a curve, a fitted curve to actual data, fitted curve simulation data, hybrid data, etc.), which aims to represent utilization of resources over the proposed time of the project. The curve 132 can also be illustrated as a combination of two or more curves that help represent side by side comparisons of actual time and expenditure components (actual project metric values) vs. proposed time and costs allocations of specific resources (planned values for the project metrics).”; Paragraph 54, “FIGS. 2A and 2B illustrate exemplary graphs showing disruption or jerk or efficiency or snap or jounce in a project through analysis of a project metric 112 with respect to time. In the present disclosure, as an exemplary illustration, the graphs are drawn for "percentage of work completed" as the project metric 112. The graphs can help in understanding the disruptions or efficiencies that occur during a project. FIG. 2A illustrates a projected achievement curve 210 for a project metric 112 (percentage of work completed for example) with respect to time and also illustrates the actual obtained achievement curve 215 for the project metric 112 of the project, plotted over percentage of work completed against time period in two axis. FIG. 2B, on the other hand, through disruption metric 122 comprising one or more disruption and efficiency indices, illustrates the magnitude and location of jerk or snap in the project. FIG. 2A and FIG. 2B can be described in a better manner as below.”)
predicting, based on the progress evaluation index, data of the progress performance after the predetermined time point, (Prieto: Paragraph 55, “FIG. 2A illustrates a graph 200 for percentage of work completed over time period T. In the present exemplary embodiment, "percentage of work completed" depicts a project metric 112 and is expressed as work completion percentage taken along Y axis. Amount of time taken to finish the specified amount of work is illustrated on X axis as time period T of the project. For illustration and simplicity, percentage of work completed is divided into 10 divisions, wherein each division indicates 10% of project work completed. Time period T along X axis can be divided into number of days after which the work rate is to be calculated and in the present illustration, the defined time period interval is 10 days. Therefore, after every 10 days, the percentage work completed is calculated for the present illustration. A projected work completion achievement curve 210 presenting the expected progress of the project can be estimated and drawn on the graph 200. Curve 210 can be drawn and defined before the project is initiated. The projected work completion curve 210 represents the percentage of work expected to be completed at defined time period intervals. For example, in the present illustration of FIG. 2, 10% of work involved in the project is expected to be completed within first 10 days and 50% of the work is expected to be completed within 50 days from initiation of the project. This work rate, in the present illustration, would lead to 100% work completion after 100 days. Therefore, a project or program manager or a user can plan that the project will be completed in 100 days and that the project be monitored after every 10 days to understand the progress of the program.”; Paragraph 69, “Project analysis engine 120 can generate a disruption metric 122 comprising mean square derivative (MSD) value of fourth order time derivative of one or more project metrics 112 of a program, wherein mean square derivative (MSD) value is a sum of squares of periodic efficiency values or snaps observed over a number of time periods. MSD value can be computed by calculating fourth order time derivatives of a project metric at periodic time intervals (such as daily) of a defined duration of project execution (such as 1 month) and then calculating mean of the derivative values. MSD value can be stored in the disruption metric 122 along with disruption and efficiency indices. Efficiency index can also be configured to include an absolute value derived from the fourth order time derivative of one or more project metrics 112. Such absolute values have already been illustrated in FIG. 2B. In another implementation, efficiency index can include cumulative efficiency or inefficiency over a defined period of time, wherein the cumulative efficiency can include a sum of all absolute values derived from the fourth order time derivatives for the defined period.”; Paragraph 70, “FIG. 3A represent an S-curve 315 with respect to a project metric 112 such as man-hours and time. Any other suitable project metric based on output, cost, scope of work, procurement, logistics, risk, communication, human resource plan, quality, or number of activities can also be incorporated. S-curve 315 is an S-shaped graph produced by Sigmoid formula which calculates the cumulative expenditure of certain project metrics against time. S-curve 315 is typically used against estimates such as projections or budgets on such project metrics 112. The projected curve 310 represents the projections of total number of man-hours planned to be used over the period of 100 days of the project. For simplicity, the projected curve 310 has been shown with a slope of 1, with 10% of the work intended to be covered in 10 days and 100% of the work intended to be covered in 100 days. As can be seen, the S-curve 315 typically represents a slow start and a slow finish with varying acceleration in between, wherein the man-hours consumed are lower than projected in the first half and higher in the second half. For example, after 30 days the number of man-hours to be consumed is planned to be 30 and the actual consumption is 15. Similarly, after 90 days, the number of man-hours to be consumed is planned to be 90 and the actual consumption is 98.”; Paragraph 73, “As a can be seen, the efficiency index or snap can have actual values from negative to positive, wherein the negative values can indicate inefficiencies (such as undesirable disruptions or events leading to lag in projects) and positive values can indicate efficiencies such as on-time or before time start of new activities, email communications indicating no change in scope of an activity, reduction in man-hours, among others. Furthermore, magnitude of efficiency index, as shown on Y axis can indicate the level of efficiency, which can be compared with defined thresholds, so as to take necessary action for highlighting the event responsible, activities undertaken in the event, people responsible for those activities, duration of those activities, importance of each of those activities, and correct or continue the activities depending on efficiency or inefficiency. It should also be noted that, in the present illustration of FIG. 3C, the frequency of efficiency or inefficiency is more in the middle of the time duration of 10 days and highest around the 5'th day, whereas the frequency of variation is relatively lower in the beginning and in the end. However, such a representation is purely project or program specific and can vary.”)
calculating a corrected evaluation index which is obtained by correcting the progress evaluation index of the second step based on the influence evaluation model at the predetermined time point; and (Prieto: Paragraph 74, “The system 100 can further be configured to generate signatures based on certain trends, types, or magnitudes of disruptions, efficiencies, or inefficiencies and store such signatures in program database 110. Such signatures can be generated based on experience of subject matter experts on anticipated disruptions or efficiencies, previous signatures in same or other programs, or common types of jerks or snaps that are generated in a particular type of project. The signatures can either be stored in the database 110 in an encoded format or any other known format, which can help their efficient retrieval or processing by the program analysis engine 120. The signatures can also be updated or new signatures can be formed as the program proceeds over a period time, wherein such update or formation can be based on earlier disruptions detected in the same program, new learning from other parts of the program or from other projects in the same program. The signatures can be configured to store disruption or efficiency characteristics along with their possible reasons and resolutions. The database 110 can be configured to classify the signatures based on whether they relate to efficiencies or disruptions, type of program or project, project metrics involved, % of confidence in suggested resolution or other parameters.”; Paragraph 76, “FIG. 4 presents a method 400 for program management to identify disruptions or efficiencies in a program or project with respect to one or a combination of project metrics of the program. Step 410 can include providing access to a project database that stores project metric objects of one or more project metrics. The project metrics can include manpower; cost incurred; resources utilized; logistics; schedule; test; inspection work, project, program completion percentage; personnel usage; email communication; earned value; man-hour usage; or other program related metrics; wherein the project metric objects can include data related to the project metrics obtained at a particular time period.”; Paragraph 78, “Step 430 includes the analysis engine deriving a disruption metric based on at least a third order time derivative of a project metric that is stored in the project metric database. The selected project metric of the program can be analyzed by reading project metric data over a time period and calculating a third order time derivative of the project metric at one or more time points to assess whether a jerk has happened in the program at any of those time points. Each jerk can represent a disruption (desired or undesired) that occurs the program. The disruption metric can be generated as a function of the third order time derivative of the project metric, and can be represented as f(d.sup.3PM/dt.sup.3), where PM represents the selected project metric. It should be appreciated that although the disruption metric has been described in the present disclosure as a function of the third order time derivative of the project metric, which indicates an indirect computation of the metric from the project metric, the disruption metric can also be directly implemented as equal in value to the third order time derivative of the project metric rather than being a function thereof. Alternatively, based on the project metric involved and program characteristics, the disruption metric can also be computed as a third order time derivative including a constant or offset value. Furthermore, the disruption metric can also represent multiple third order time derivatives of the project metric across different time periods and store them together as part of the metric.”)
in prediction of the data of the progress performance regarding the second step, predicting, based on the corrected evaluation index, the data of the progress performance after the predetermined time point in the second step. (Prieto: Paragraph 74, “The system 100 can further be configured to generate signatures based on certain trends, types, or magnitudes of disruptions, efficiencies, or inefficiencies and store such signatures in program database 110. Such signatures can be generated based on experience of subject matter experts on anticipated disruptions or efficiencies, previous signatures in same or other programs, or common types of jerks or snaps that are generated in a particular type of project. The signatures can either be stored in the database 110 in an encoded format or any other known format, which can help their efficient retrieval or processing by the program analysis engine 120. The signatures can also be updated or new signatures can be formed as the program proceeds over a period time, wherein such update or formation can be based on earlier disruptions detected in the same program, new learning from other parts of the program or from other projects in the same program. The signatures can be configured to store disruption or efficiency characteristics along with their possible reasons and resolutions. The database 110 can be configured to classify the signatures based on whether they relate to efficiencies or disruptions, type of program or project, project metrics involved, % of confidence in suggested resolution or other parameters.”; Paragraph 76, “FIG. 4 presents a method 400 for program management to identify disruptions or efficiencies in a program or project with respect to one or a combination of project metrics of the program. Step 410 can include providing access to a project database that stores project metric objects of one or more project metrics. The project metrics can include manpower; cost incurred; resources utilized; logistics; schedule; test; inspection work, project, program completion percentage; personnel usage; email communication; earned value; man-hour usage; or other program related metrics; wherein the project metric objects can include data related to the project metrics obtained at a particular time period.”; Paragraph 78, “Step 430 includes the analysis engine deriving a disruption metric based on at least a third order time derivative of a project metric that is stored in the project metric database. The selected project metric of the program can be analyzed by reading project metric data over a time period and calculating a third order time derivative of the project metric at one or more time points to assess whether a jerk has happened in the program at any of those time points. Each jerk can represent a disruption (desired or undesired) that occurs the program. The disruption metric can be generated as a function of the third order time derivative of the project metric, and can be represented as f(d.sup.3PM/dt.sup.3), where PM represents the selected project metric. It should be appreciated that although the disruption metric has been described in the present disclosure as a function of the third order time derivative of the project metric, which indicates an indirect computation of the metric from the project metric, the disruption metric can also be directly implemented as equal in value to the third order time derivative of the project metric rather than being a function thereof. Alternatively, based on the project metric involved and program characteristics, the disruption metric can also be computed as a third order time derivative including a constant or offset value. Furthermore, the disruption metric can also represent multiple third order time derivatives of the project metric across different time periods and store them together as part of the metric.”)
Prieto does not explicitly disclose the following, however, in analogous art of project management, Davies teaches the following:
wherein the project includes, as the at least one step, a preceding first step and a subsequent second step, (Davies: Paragraph 39, “FIG. 2 depicts a flowchart of the operational steps in the project management process 200, in accordance with an embodiment of the present invention. The method(s) and associated process(es) are now discussed, over the course of the following paragraphs, with extensive reference to FIG. 2, in accordance with one embodiment of the present invention. Project process 200 is a combination of the sub processes/functions controlled and managed by the project management module 110. The workflow follows a series of steps to optimally prepare the project for launch, validate the project is ready to start, manage delivery of the team to budget and plan and optimize for future success based on the project learnings.”; Paragraph 51, “FIG. 3 depicts a flowchart of the operational steps of the project launch process 300, in accordance with an embodiment of the present invention. The method(s) and associated process(es) are now discussed, over the course of the following paragraphs, with extensive reference to FIG. 3, in accordance with one embodiment of the present invention.”)
wherein the step is the second step, the method further comprising: acquiring information of at least one first milestone in the first step and information of a second milestone corresponding to each first milestone in terms of timing in the second step; (Davies: Paragraph 44, “Once the team setup has been completed and/or approved by the client 101, module 110 generates 208 a plan for the completion of the requested project. The plan establishes the project time line, the order of tasks, the milestones of the project, invoicing schedule, establishing the communication between the client 101 and resource(s) 105 as well as the resource(s) 105 and other resource(s) 105 in tasks which are related, and the other factors which the requested project is to be completed on/by. In some embodiments, the module 110 accesses a project history database 107 which provides previously completed projects of similarity to establish a plan that is realistic based on previously record data. To determine the time specific task may take, tentative fees or prices for the tasks (or project as a whole), and other variables about the project which are requested by the client 101, required by the module 110, or important to establish prior to beginning the project.”; Paragraph 46, “Module 110 handles the deliver 214 of the project between the resource(s) 105 and the client 101. The module 110 communicates with the resource(s) 105 based on their assigned tasks, provides the completed work to client 101 for review, and communicates any issues, modifications, questions, or the like between the client 101 and the resource(s) 105. Once the final task of the project is completed (or approved by the client) 216, the module 110 submits the assets or completed project to the client 101 with any additional invoices or requirements of the client 101. In some embodiments, the module 110 follows a pre-defined workflow ensuring that each element (Milestone, Task, Asset) are assigned, tracked and delivered according to the approved plan.”; Paragraph 48, “The module 110 may, in some embodiments, request or receive feedback 218 from the resource(s) 105 and/or the client 101 based on the project. This may include how the resource(s) 105 worked together, how the resource(s) 105 worked with the client 101, how the client 101 felt about the resource(s) 105, the length of the project, and issues with the project, any comments (positive and/or negative) about the project, ways to improve upon the project, effectiveness of communication between the parties, and the like. The module 110, takes this information and processes the information to optimize 220 the overall process. This may include, but not limited to, adjusting project types/templates, identifying resource(s) 105 which work well together, adjusting timelines to a more realistic length, adjusting prices and fees, and the like.”)
accumulating the data of the progress performance of each of multiple completed projects; (Davies: Paragraph 25, “The present invention provides a method, system, or program for automating the delivery of a project without a human project manager, comprising, project definition, resource allocation, success forecasting, plan development, automated communication and delivery execution. In one embodiment, the method, system, or program uses a combination of cloud computing environments and machine learning resources (e.g. Web Portal, cloud storage and back end application logic, Machine Learning and pre-programmed algorithms, trained conversation service and communication through an email client, Instant Messaging and Notifications) to facilitate the project management process. Which is able to leverage a project management workflow, historic/trained project knowledge, historic resource performance, sentiment analysis and simulated Project Manager communications to monitor the project, determine when tasks are completed, identify issues which arise, providing potential solutions to these issues, and provide additional resources to the project that would assist in the efficiency of the project.”)
acquiring an influence evaluation model that represents influence of relationship between data regarding each first milestone in the data of the progress performance of the first step and data regarding the corresponding second milestone in the data of the progress performance of the second step on the progress evaluation index of the second step, wherein the influence evaluation model is determined based on the data of the progress performance that has been accumulated, and (Davies: Paragraph 44, “Once the team setup has been completed and/or approved by the client 101, module 110 generates 208 a plan for the completion of the requested project. The plan establishes the project time line, the order of tasks, the milestones of the project, invoicing schedule, establishing the communication between the client 101 and resource(s) 105 as well as the resource(s) 105 and other resource(s) 105 in tasks which are related, and the other factors which the requested project is to be completed on/by. In some embodiments, the module 110 accesses a project history database 107 which provides previously completed projects of similarity to establish a plan that is realistic based on previously record data. To determine the time specific task may take, tentative fees or prices for the tasks (or project as a whole), and other variables about the project which are requested by the client 101, required by the module 110, or important to establish prior to beginning the project.”; Paragraph 47, “In additional embodiments, when a task is not completed 216 on time, the module 110 enables dynamic revision to a given project plan based on changes to a task due date that has dependencies cause downstream impact (Plan management) or initiated based on clients 101 demand. The module 110 analyzes the impacts and is able to assess to see any changes to end delivery date and recommend new target dates to following resource(s) 105 task delivery. Based on the resource(s) 105 responses to recommended changes, the plan can either be delivered to plan or delivered to the new date (requiring client change management.)”; Paragraph 61, “In an example where the activity/task can be completed internally, the module compiles 406, the data for the action. Executes 408 the steps, procedures, or processes which are necessary to complete the task. The module 110 then manages 410 the asset in relation to the parties and the project.”; Paragraph 57, “The module 110 is continuously, and in some embodiments automatically, processing the updates and assets from the parties through a task progress monitoring system 309. The task progress monitoring system 309 evaluates the progress and risk for a given task and, in some embodiments the overall project. The task progress monitoring system 309 is constantly assessed while a task is active and can trigger targeted communications to the client 101 or resource(s) 105, the more detailed escalation and change asset management service 312 if concerns are identified, when a task is completed this service triggers a project process check 320 and hand off to the next task/project close out functionality. For example, the task progress monitoring system 309 may provide schedule assessment, resource engagement, client 101 sentiment, resource(s) 105 sentiment, task completion, dependency risk, and the like. Based on the assessment of the task progress monitoring system 309, the module 110 can determine an appropriate reaction to the client 101 and the resource(s) 105 actions. The module 110 is able to process a sentiment issues 314 determined by the task progress monitoring system 309 process an escalation assessment 322 (FIG. 6), wherein an escalation risk score is calculated, and a determination is made if a third-party intervention is required. The module 110 is able to determine where a task is delayed 318, how the delay affects the overall project, and if this delay results in an adjustment to the escalation 322 of the project.”)
wherein the influence evaluation model is a third machine learning model that has learned a relationship between the data of the progress performance that has been accumulated and the progress evaluation index of the second step; (Davies: Paragraph 44, “Once the team setup has been completed and/or approved by the client 101, module 110 generates 208 a plan for the completion of the requested project. The plan establishes the project time line, the order of tasks, the milestones of the project, invoicing schedule, establishing the communication between the client 101 and resource(s) 105 as well as the resource(s) 105 and other resource(s) 105 in tasks which are related, and the other factors which the requested project is to be completed on/by. In some embodiments, the module 110 accesses a project history database 107 which provides previously completed projects of similarity to establish a plan that is realistic based on previously record data. To determine the time specific task may take, tentative fees or prices for the tasks (or project as a whole), and other variables about the project which are requested by the client 101, required by the module 110, or important to establish prior to beginning the project.”; Paragraph 47, “In additional embodiments, when a task is not completed 216 on time, the module 110 enables dynamic revision to a given project plan based on changes to a task due date that has dependencies cause downstream impact (Plan management) or initiated based on clients 101 demand. The module 110 analyzes the impacts and is able to assess to see any changes to end delivery date and recommend new target dates to following resource(s) 105 task delivery. Based on the resource(s) 105 responses to recommended changes, the plan can either be delivered to plan or delivered to the new date (requiring client change management.)”; Paragraph 61, “In an example where the activity/task can be completed internally, the module compiles 406, the data for the action. Executes 408 the steps, procedures, or processes which are necessary to complete the task. The module 110 then manages 410 the asset in relation to the parties and the project.”; Paragraph 57, “The module 110 is continuously, and in some embodiments automatically, processing the updates and assets from the parties through a task progress monitoring system 309. The task progress monitoring system 309 evaluates the progress and risk for a given task and, in some embodiments the overall project. The task progress monitoring system 309 is constantly assessed while a task is active and can trigger targeted communications to the client 101 or resource(s) 105, the more detailed escalation and change asset management service 312 if concerns are identified, when a task is completed this service triggers a project process check 320 and hand off to the next task/project close out functionality. For example, the task progress monitoring system 309 may provide schedule assessment, resource engagement, client 101 sentiment, resource(s) 105 sentiment, task completion, dependency risk, and the like. Based on the assessment of the task progress monitoring system 309, the module 110 can determine an appropriate reaction to the client 101 and the resource(s) 105 actions. The module 110 is able to process a sentiment issues 314 determined by the task progress monitoring system 309 process an escalation assessment 322 (FIG. 6), wherein an escalation risk score is calculated, and a determination is made if a third-party intervention is required. The module 110 is able to determine where a task is delayed 318, how the delay affects the overall project, and if this delay results in an adjustment to the escalation 322 of the project.”)
Claim 17 –
Prieto in view of Davies disclose the limitations of claim 16
Prieto further discloses the following:
the first milestone and the second milestone are determined based on the data of the progress performance that has been accumulated. (Prieto: Paragraph 55, “FIG. 2A illustrates a graph 200 for percentage of work completed over time period T. In the present exemplary embodiment, "percentage of work completed" depicts a project metric 112 and is expressed as work completion percentage taken along Y axis. Amount of time taken to finish the specified amount of work is illustrated on X axis as time period T of the project. For illustration and simplicity, percentage of work completed is divided into 10 divisions, wherein each division indicates 10% of project work completed. Time period T along X axis can be divided into number of days after which the work rate is to be calculated and in the present illustration, the defined time period interval is 10 days. Therefore, after every 10 days, the percentage work completed is calculated for the present illustration. A projected work completion achievement curve 210 presenting the expected progress of the project can be estimated and drawn on the graph 200. Curve 210 can be drawn and defined before the project is initiated. The projected work completion curve 210 represents the percentage of work expected to be completed at defined time period intervals. For example, in the present illustration of FIG. 2, 10% of work involved in the project is expected to be completed within first 10 days and 50% of the work is expected to be completed within 50 days from initiation of the project. This work rate, in the present illustration, would lead to 100% work completion after 100 days. Therefore, a project or program manager or a user can plan that the project will be completed in 100 days and that the project be monitored after every 10 days to understand the progress of the program.”; Paragraph 59, “When mapped with respect to time T, the disruption and efficiency index units can present the location of jerk or snap, event causing the jerk or snap, severity of jerk or snap, or time duration of the event causing the jerk or snap. FIG. 2B illustrates a schematic representation 250 showing disruption and efficiency indices by means of units or magnitude of jerk or snap with respect to time period T. As discussed earlier, although the present illustration represents third and fourth order time derivatives, in actual implementation, any higher order time derivative can be utilized for assessment of disruption and efficiency parameters. In FIG. 2B, magnitude (absolute value) of jerk or snap is represented through disruption and efficiency indices along Y axis and time period T is represented along X axis in the form of days.”; Paragraph 61, “Similar to above, FIG. 2A shows that the percentage of completion after 20 days is 15%, which, in fact, was planned for 20%. FIG. 2B correspondingly represents a series of jerks and snaps between days 11 to 20, wherein there is a jerk of 3 units on day 13, another jerk of 5 units on day 17, a snap of 4 units on day 18, and a snap of 4 units on day 19. As would be noticed, a higher magnitude of jerk corresponds to a higher severity disruption, and likewise a higher magnitude of snap corresponds to higher efficiency. In an embodiment, continuous jerks or snaps can indicate continuous disruption or efficiency, and therefore the representation 250 can indicate the duration, extent, severity, and timestamp of jerk or snap. In another embodiment, the time period interval for representation 250 can also be in hours, minutes, or even seconds for accurate assessment of the cause and extent of disruption or efficiency.”)
Claim 18 –
Prieto in view of Davies disclose the limitations of claims 16-17
Prieto further discloses the following:
wherein each first milestone and each second milestone are determined based on the data of the progress performance of a project with a shortest work period of the second step among the multiple completed projects. (Prieto: Paragraph 55, “FIG. 2A illustrates a graph 200 for percentage of work completed over time period T. In the present exemplary embodiment, "percentage of work completed" depicts a project metric 112 and is expressed as work completion percentage taken along Y axis. Amount of time taken to finish the specified amount of work is illustrated on X axis as time period T of the project. For illustration and simplicity, percentage of work completed is divided into 10 divisions, wherein each division indicates 10% of project work completed. Time period T along X axis can be divided into number of days after which the work rate is to be calculated and in the present illustration, the defined time period interval is 10 days. Therefore, after every 10 days, the percentage work completed is calculated for the present illustration. A projected work completion achievement curve 210 presenting the expected progress of the project can be estimated and drawn on the graph 200. Curve 210 can be drawn and defined before the project is initiated. The projected work completion curve 210 represents the percentage of work expected to be completed at defined time period intervals. For example, in the present illustration of FIG. 2, 10% of work involved in the project is expected to be completed within first 10 days and 50% of the work is expected to be completed within 50 days from initiation of the project. This work rate, in the present illustration, would lead to 100% work completion after 100 days. Therefore, a project or program manager or a user can plan that the project will be completed in 100 days and that the project be monitored after every 10 days to understand the progress of the program.”; Paragraph 59, “When mapped with respect to time T, the disruption and efficiency index units can present the location of jerk or snap, event causing the jerk or snap, severity of jerk or snap, or time duration of the event causing the jerk or snap. FIG. 2B illustrates a schematic representation 250 showing disruption and efficiency indices by means of units or magnitude of jerk or snap with respect to time period T. As discussed earlier, although the present illustration represents third and fourth order time derivatives, in actual implementation, any higher order time derivative can be utilized for assessment of disruption and efficiency parameters. In FIG. 2B, magnitude (absolute value) of jerk or snap is represented through disruption and efficiency indices along Y axis and time period T is represented along X axis in the form of days.”; Paragraph 61, “Similar to above, FIG. 2A shows that the percentage of completion after 20 days is 15%, which, in fact, was planned for 20%. FIG. 2B correspondingly represents a series of jerks and snaps between days 11 to 20, wherein there is a jerk of 3 units on day 13, another jerk of 5 units on day 17, a snap of 4 units on day 18, and a snap of 4 units on day 19. As would be noticed, a higher magnitude of jerk corresponds to a higher severity disruption, and likewise a higher magnitude of snap corresponds to higher efficiency. In an embodiment, continuous jerks or snaps can indicate continuous disruption or efficiency, and therefore the representation 250 can indicate the duration, extent, severity, and timestamp of jerk or snap. In another embodiment, the time period interval for representation 250 can also be in hours, minutes, or even seconds for accurate assessment of the cause and extent of disruption or efficiency.”)
Claim 19 –
Prieto in view of Davies disclose the limitations of claim 16
Prieto further discloses the following:
wherein the corrected evaluation index is calculated based on a first milestone period from the reference time point to each first milestone, a second milestone period from the reference time point to each second milestone, and a difference between each first milestone period and each second milestone period corresponding thereto. (Prieto: Paragraph 56, “An actual work completed achievement curve 215 is drawn on graph 200 to represent actual percentage of work completed during the time period T. As has earlier been mentioned, "percentage of work completed" is merely an exemplary project metric 112 and any other project metric such as resource utilized or cost incurred, can be used independently or in combination with other project metrics. In an embodiment, curve 215, can also be referred to as achievement curve 132 interchangeably, whereas in an alternate embodiment, the curve 215 can be different from achievement curve 132 in terms of the manner in which their respective project metrics are processed, evaluated, or analyzed. As can be seen from curve 215, even though projected work to be completed after the first 10 days was 10%, the actual work completed was 9%, leading to a lag of 1%. Similarly, even though the projected work to be completed after the first 30 days was 30%, the actual work completed was 32%, leading to a delta of 2% over the projected schedule. As can be seen, the actual work completed curve 215 merely depicts whether the project metric 112 is ahead of or behind the planned projected curve 210 but does not explain or give any details of the reasons, location, timestamp, or activity giving rise to such a lag or leap. Although this document references "derivatives", one should appreciate that such values can be calculated based on difference in discrete values at points in time.”; Paragraph 66, “Project analysis engine 120 can be configured to generate recommendations to a project manager to manage disruption metric 122 in a program based on comparison between projected curve 210 and an actual curve 215, wherein the recommendations can comprise actions to minimize disruptions or maximize snaps in the program. The project analysis engine 120 can also help in optimizing disruption metric 122 of one or more project metrics 112 based on needs of the program manager. In some embodiments, analysis engine 120 can compare characteristics of disruption or efficiency indices (e.g., jerk and snap respectively) to known event signatures. When the characteristics suitably match such signatures, analysis engine 120 can construct a notification or recommendation on corrective actions as derived from information stored within or associated with the known event signatures.”; Paragraph 71, “FIG. 3B represents a graphical representation 350 illustrating jerks or disruptions for a short time periods within the project shown in FIG. 3A. Representation 350 shows the third order derivatives of the man-hours project metric 112 with respect to the actual progress curve 315 and illustrates the values of third order time derivatives of the metric 112 for the first 10 days of the project. As a can be seen, the disruption index or jerk can have actual values from negative to positive, wherein the negative disruptions can indicate negative jerks (unanticipated or unexpected) and positive disruptions are expected jerks representing start of new activities, allocation of new man-hours, among others. Furthermore, magnitude of disruption index, as shown on Y axis can indicate the level of disruption, which can later be compared with defined thresholds, so as to take necessary action such as allocating additional man-hours to complete the activity at hand. For example, in case -1 to +1 is the defined threshold for third order time derivatives of man-hours project metric, disruption due to activities undertaken on Day 4 of the program is higher than the defined threshold and therefore such activities along with remedial measures can be reported to the project team on Day 4 itself. It should also be noted that, in the present illustration of FIG. 3B, the frequency of disruption is more in the middle of the time duration of 10 days and highest around the 5'th day, whereas the disruption is relatively lower in the beginning and in the end. However, such a representation is purely project or program specific and can vary.”; Paragraph 74, " The system 100 can further be configured to generate signatures based on certain trends, types, or magnitudes of disruptions, efficiencies, or inefficiencies and store such signatures in program database 110. Such signatures can be generated based on experience of subject matter experts on anticipated disruptions or efficiencies, previous signatures in same or other programs, or common types of jerks or snaps that are generated in a particular type of project. The signatures can either be stored in the database 110 in an encoded format or any other known format, which can help their efficient retrieval or processing by the program analysis engine 120. The signatures can also be updated or new signatures can be formed as the program proceeds over a period time, wherein such update or formation can be based on earlier disruptions detected in the same program, new learning from other parts of the program or from other projects in the same program. The signatures can be configured to store disruption or efficiency characteristics along with their possible reasons and resolutions. The database 110 can be configured to classify the signatures based on whether they relate to efficiencies or disruptions, type of program or project, project metrics involved, % of confidence in suggested resolution or other parameters”)
Claim 20 –
Prieto in view of Davies disclose the limitations of claim 16
Prieto does not explicitly disclose the following, however, in analogous art of project management, Davies teaches the following:
wherein in a case where a delay has occurred in the timing of the first milestone in the data of the progress performance of the first step, the timing of the corresponding second milestone in the data of the progress plan of the second step is changed to after the timing of the first milestone in which the delay has occurred. (Davies: Paragraph 57, “The module 110 is continuously, and in some embodiments automatically, processing the updates and assets from the parties through a task progress monitoring system 309. The task progress monitoring system 309 evaluates the progress and risk for a given task and, in some embodiments the overall project. The task progress monitoring system 309 is constantly assessed while a task is active and can trigger targeted communications to the client 101 or resource(s) 105, the more detailed escalation and change asset management service 312 if concerns are identified, when a task is completed this service triggers a project process check 320 and hand off to the next task/project close out functionality. For example, the task progress monitoring system 309 may provide schedule assessment, resource engagement, client 101 sentiment, resource(s) 105 sentiment, task completion, dependency risk, and the like. Based on the assessment of the task progress monitoring system 309, the module 110 can determine an appropriate reaction to the client 101 and the resource(s) 105 actions. The module 110 is able to process a sentiment issues 314 determined by the task progress monitoring system 309 process an escalation assessment 322 (FIG. 6), wherein an escalation risk score is calculated, and a determination is made if a third-party intervention is required. The module 110 is able to determine where a task is delayed 318, how the delay affects the overall project, and if this delay results in an adjustment to the escalation 322 of the project.”; Paragraph 67, “When a sentiment issue has been identified 601, the module 110, a task is delayed or a deadline is approaching without an update, this service produces an escalation risk score. The module 110 reviews 602 the project data. The project data may include, but not limited to, Specific project complexity, project completeness, percentage of project task overdue or delivered late, current task delay, latest and average client and personnel sentiment, resources known to client risk, team risk, dependency assessment, dependency risk, and the like. Based on these and other relevant factors, the module 110 calculates 604 an escalation risk score. Based on the escalation risk score, the module 110 assess 605 the escalation method. The module 110 is able to escalate to the client 606A, the personnel 606B, or a “Human-in-Loop” Project Manager 606C. The escalations to the client 101 and the resource(s) 105 use carefully constructed and dynamically selected change management language to minimize the impact and optimize the end user experience/engagement. Escalations to the HIL PM is in effect a failsafe to ensure client 101 satisfaction, when a project is at significant risk, a client service specialist (HIL PM) can be informed, simply see the cause of escalation and directly intervene in the project to ensure a sustained successful outcome.”; Paragraph 71, “In the process once a project is complete, is able to review the data (communications, assets, teams, tasks, etc.) of the project to train the module 110 and sub-systems as well as optimize 750 the module 110 and the sub-systems to create an improved project design for future projects. The module 110 ensures that future delivery performance is optimized based on Learning from Historic Project delivery. By comparing the project template used for the requested project, through populating 752 the task deviation data, and the time deviation data. Delays to specific tasks or longer deliveries are automatically considered in future project plans by the intelligent plan builder service. The module 110 is able to see the accuracy of the project template and detect deviations and analyze the possible reasons for the deviations. The module 110 analyzes 753 the team delivery and in particular interactions between team members. Poorly performing resource pairings who did not make an effective team are marked to prevent future usage in a project team. Individual resources 105 and clients 101 who create a negative experience are flagged for review to ensure that bad experiences are not repeated on future projects. The module 110 updates the project templates 754 for future projects. In some embodiments, previously created templates are maintained for future use.”)
Prieto discloses a method of determining progress and predictions of a project based on various acquired data values. Davies discloses a method for managing the monitoring the workflow of a project.. At the time of Applicant’s filed invention, one of ordinary skill in the art would have deemed it obvious to combine the methods of Prieto with the teachings of Davies in order to improve the planning and execution of projects as disclosed by Davies (Davies: Paragraph 5, “Therefore, it is desired for a method, computer program, or computer system to create a central system to plan the project, connect the resources, establish a timeline and project deliverables, all while maintaining communication between parties and monitor task completions, and project adjustments.”)
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Philip N Warner whose telephone number is (571)270-7407. The examiner can normally be reached Monday-Friday 7am-4:00pm.
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, Jerry O’Connor can be reached at 571-272-6787. 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.
/Philip N Warner/Examiner, Art Unit 3624
/Jerry O'Connor/Supervisory Patent Examiner,Group Art Unit 3624
Prosecution Insights