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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on and between 3/30/2023 and 10/14/2025 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Notice to Applicant
Claims 1, 3, 8-9, 11, 13, 18-19 and 21 are currently amended.
Claims 1-22 are pending.
Response to Amendment
Applicant’s amendments are acknowledged.
Response to Arguments
Applicant' s arguments filed 12/10/2025 have been fully considered in view of further consideration of statutory law, Office policy, precedential common law, and the cited prior art as necessitated by the amendments to the claims, and are not persuasive for the reasons set forth below.
35 USC § 101 Rejections
First, regarding Step 2A Prong One and present claim 1, Applicant argues that “In being directed to the specific, technical solution to the problem that arises uniquely in the context of assessing labor efficiency from inconsistent and heterogeneous digital records of knowledge work, the method of amended independent claim 1 includes the following key technological limitations.
The method is expressly performed "by a computing system" underscoring that the
steps are machine-executed…
The method begins with receiving event data extracted from a plurality of data sources. Such data sources represent distinct digital systems used in knowledge work, each of which may encode data using different time formats and schemas…
The method includes "processing the event records to account for differences in time representation or system format across the plurality of data sources." This is a canonical example of a computing-specific technical operation - not a conceptual abstraction…
In sum, the steps of amended independent claim 1 as a whole reflect a technical solution for evaluating labor efficiency across heterogeneous data sources, not a mental process or economic abstraction. Amended independent claim 1 solves a technical problem in distributed and asynchronous work tracking, not a general human coordination challenge. Its structure and transformations are consistent with the types of improvements found patent-eligible in Ex parte Desjardins (effort modeling using contextual information in a computing environment).
In view of the foregoing, amended independent claim 1 is not directed to a judicial exception as amended independent claim 1 presents a computer-executed solution to a technical data harmonization and modeling problem using structured inputs, intermediate processing, context-aware transformation, and GUI-configured output.” [Arguments, pages 7-9].
In response, Applicant’s arguments are considered but are not persuasive. Examiner respectfully disagrees and maintains that the present claims recite a judicial exception. In particular, Examiner maintains that the present claims, when considered as a whole, recite concepts relating to certain methods of organizing human activity. The amended limitations describe steps for managing personal behavior or relationships or interactions between people, including social activities, teaching, and following rules or instructions. Specifically, determining work effort values based on activity records of a worker is considered to describe steps for managing personal behavior.
Further, with respect to the above arguments, Examiner respectfully maintains that the claims do not demonstrate a technical solution to a problem. In particular, Examiner observes that the additional elements and technical components are not sufficient to overcome the judicial exception. Thus, claims 1, 11 and 21 recite concepts identified as abstract ideas without significantly more. As such, Examiner remains unpersuaded.
Second, regarding Step 2A Prong Two, Applicant argues that “Amended independent claim 1
integrates any exception into a practical application. Even if effort generation were considered abstract in isolation, amended independent claim 1 integrates it into a structure, computing-specific workflow that includes the creation of structured activity records, the reconciliation of time representations and system formats across sources, metadata-based effort modeling, and generation of a GUI-configured report. The use of time interval-based allocation and metadata- driven adjustment reflects a computing implementation, not an abstract idea. In addition, the output is a machine-readable, segmented report configured for graphical display, providing interactive utility rather than passive reporting. This satisfies MPEP §2106.05(a) (Improvements to the Functioning of a Computer or to Any Other Technology or Technical Field) and §2106.05(f) (Mere Instructions to Apply an Exception). Amended independent claim 1 integration of contextual metadata into a structured modeling process, together with its reliance on machine- specific operations, reinforces that the method is a practical application within a computing environment.” [Arguments, pages 9-10].
In response, Applicant’s arguments are considered but are not persuasive. Examiner respectfully disagrees and maintains that the present claims recite a judicial exception without significantly more. Under Step 2A Prong Two, Examiners evaluate integration into a practical application by: (1) identifying whether there are any additional elements recited in the claim beyond the judicial exception(s); and (2) evaluating those additional elements individually and in combination to determine whether they integrate the exception into a practical application, using one or more of the considerations introduced in subsection I supra, and discussed in more detail in MPEP §§ 2106.04(d)(1), 2106.04(d)(2), 2106.05(a) through (c) and 2106.05(e) through (h).
Amended claim 1 only recite the following additional elements –
…a computing system… ; …a graphical user interface [Claim 1],
The computing system and GUI elements are recited at a high-level of generality (see MPEP § 2106.05(a)), like the following MPEP example:
iii. Gathering and analyzing information using conventional techniques and displaying the result, TLI Communications, 823 F.3d at 612-13, 118 USPQ2d at 1747-48;
Furthermore, the computer implemented element is considered to amount to no more than mere instructions to apply the exception using a generic computer component (see MPEP 2106.05(f)), like the following MPEP example:
i. A commonplace business method or mathematical algorithm being applied on a general purpose computer, Alice Corp. Pty. Ltd. V. CLS Bank Int’l, 573 U.S. 208, 223, 110 USPQ2d 1976, 1983 (2014); Gottschalk v. Benson, 409 U.S. 63, 64, 175 USPQ 673, 674 (1972); Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015);
Accordingly, these additional elements do not integrate the abstract idea into a practical application. The remaining dependent claims do not recite any new additional elements, and thus do not integrate the abstract idea into a practical application. As such, Examiner remains unpersuaded.
Third, regarding Step 2B, Applicant argues that “Amended independent claim 1 recites significantly more than any alleged abstract idea because amended independent claim 1 involves event data processing to account for differences in time format; contextual metadata fields tied to specific activity dimensions; a two- stage effort modeling approach using both time intervals and metadata; and a machine-readable, segmented output configured for GUI display. These elements are not generic or conventional and provide a structured, technical improvement in how labor effort is inferred and reported from heterogenous activity data. This is consistent with PTAB precedent in Ex parte Desjardins, where claims applying data-driven logic to real-world technical problems were held patent-eligible.
In summary, amended independent claim 1 recites a specific technical method implemented in a computing system. The method of amended independent claim 1 involves transforming structured event data into effort-evaluation reports through time-based allocation and metadata-driven adjustment. The method of amended independent claim 1 is not abstract, integrates any possible exception into a practical application, and recites significantly more than any possible exception. Accordingly, amended independent claim 1 is patent eligible…” [Arguments, pages 10-11].
In response, Applicant’s arguments are considered but are not persuasive. Examiner respectfully disagrees and maintains that the present claims recite a judicial exception without significantly more. Under Step 2B, Examiners should:
• Carry over their identification of the additional element(s) in the claim from Step 2A Prong Two;
• Carry over their conclusions from Step 2A Prong Two on the considerations discussed in MPEP §§ 2106.05(a) - (c), (e) (f) and (h):
• Re-evaluate any additional element or combination of elements that was considered to be insignificant extra-solution activity per MPEP § 2106.05(g), because if such re-evaluation finds that the element is unconventional or otherwise more than what is well-understood, routine, conventional activity in the field, this finding may indicate that the additional element is no longer considered to be insignificant; and
• Evaluate whether any additional element or combination of elements are other than what is well-understood, routine, conventional activity in the field, or simply append well-understood, routine, conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception, per MPEP § 2106.05(d).
As stated in response to the above-argument, amended claim 1 only recite the following additional elements –
…a computing system… ; …a graphical user interface [Claim 1],
Examiner respectfully maintains that the computing system and graphical user interface are recited at a high level of generate, and do not amount to significantly more than the abstract idea for the reasons discussed in 2A prong 2 with regard to MPEP 2106.05(a) and MPEP 2106.05(f). By the failure of the elements to integrate the abstract idea into a practical application there, the additional elements likewise fail to amount to an inventive concept that is significantly more than an abstract idea here, in Step 2B. Thus, both individually or in combination, these limitations do not add significantly more to the judicial exception. As such, Examiner remains unpersuaded.
Fourth, regarding Step 2A Prong One and present claim 11, Applicant argues that “Amended independent claim 1 is not directed to an abstract idea, such as a mental process or a method of organizing human activity, as amended independent claim 1 recites a specific computing system configured to receive structured event data, generate activity records that include contextual metadata, and perform effort modeling using a trained data model. These steps are technical in nature and solve a computing-specific problem estimating labor effort based on heterogeneous data with time and system inconsistencies. The inclusion of a trained data model that adjusts effort values based on structured metadata reflects a computational improvement, not a general concept. As in Ex parte Desjardins, the use of trained data for contextual estimation provides a technical solution within a digital environment…” [Arguments, page 11].
In response, Applicant’s arguments are considered but are not persuasive for the same reasons as stated in response to the above arguments. In particular, while claim 11 includes a trained data model, the claim recites essentially the same abstract idea as claim 1. The amended limitations describe steps for managing personal behavior or relationships or interactions between people, including social activities, teaching, and following rules or instructions. Specifically, determining work effort values based on activity records of a worker is considered to describe steps for managing personal behavior. Thus, claims 1, 11 and 21 recite concepts identified as abstract ideas without significantly more. As such, Examiner remains unpersuaded.
Fifth, regarding Step 2A Prong Two and present claim 11, Applicant argues that “Amended independent claim 11 integrates any exception into a practical application. Even if the concept of effort estimation were abstract in isolation, amended independent claim 11 integrates this functionality into a practical application. The operations are performed by a hardware-based computing system that processes structured digital inputs, reconciles them into activity records with contextual metadata, and generates both preliminary and final effort values. The effort adjustment step uses a trained data model, configured for use within the system's operational context. The modeling is not abstract-it is directly dependent on the structured inputs and metadata available in the digital activity records. This satisfies MPEP §2106.05(a) (Improvements to the Functioning of a Computer or to any Other Technology or Technical Field) and §2106.05(f) (Mere Instructions to Apply an Exception), as the claimed system provides a technical solution implemented by specific computing components” [Arguments, pages 11-12].
In response, Applicant’s arguments are considered but are not persuasive. Examiner respectfully disagrees and maintains that the present claims recite a judicial exception without significantly more.
In particular, claims 11 and 21 only recite the following additional elements –
…at least one hardware processor; and at least one storage device coupled to the at least one hardware processor and for storing instructions that are operable, when executed by the at least one hardware processor to cause the at least one hardware processor to perform operations comprising…; …a trained machine learning model, wherein the trained machine learning model… [Claim 11],
… A computer-readable storage medium storing a program of instructions executable by a machine…; …a trained machine learning model, wherein the trained machine learning model… [Claim 21].
The computer system and trained machine learning model are recited at a high-level of generality (see MPEP § 2106.05(a)), like the following MPEP example:
iii. Gathering and analyzing information using conventional techniques and displaying the result, TLI Communications, 823 F.3d at 612-13, 118 USPQ2d at 1747-48;
Furthermore, the computer implemented element is considered to amount to no more than mere instructions to apply the exception using a generic computer component (see MPEP 2106.05(f)), like the following MPEP example:
i. A commonplace business method or mathematical algorithm being applied on a general purpose computer, Alice Corp. Pty. Ltd. V. CLS Bank Int’l, 573 U.S. 208, 223, 110 USPQ2d 1976, 1983 (2014); Gottschalk v. Benson, 409 U.S. 63, 64, 175 USPQ 673, 674 (1972); Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015);
Accordingly, these additional elements do not integrate the abstract idea into a practical application. The remaining dependent claims do not recite any new additional elements, and thus do not integrate the abstract idea into a practical application. As such, Examiner remains unpersuaded.
Sixth, regarding Step 2B and present claim 11, Applicant argues that “Amended independent claim 11 recites significantly more than any alleged abstract idea. Amended independent claim 11 does not merely describe a high-level goal or invoke a generic computer. Instead, amended independent claim 11 requires a processor and a storage device, specifies structured operations including receipt of event data, construction of activity records, and contextual modeling, incorporates contextual metadata such as task classification and task complexity, and applies a trained data model for metadata-dependent effort estimation. These limitations reflect a computing-based approach that improves how labor effort is analyzed and modeled from digital activity data. The structured, metadata-driven workflow and trained data model adjustment process are not routine or conventional. As recognized in Ex parte Desjardins, claims that apply algorithmic modeling to structured inputs for technical purposes are patent eligible.
In summary, amended independent claim 11 is directed to a computing system including technical components configured to implement a structured modeling pipeline for labor efficiency. Amended independent claim 11 is not directed to an abstract idea, it integrates any such concept into a practical computing system, and it recites significantly more than any abstract idea” [Arguments, page 12].
In response, Applicant’s arguments are considered but are not persuasive. Examiner respectfully disagrees and maintains that the present claims recite a judicial exception without significantly more.
As stated in response to the above-argument, amended claim 11 and 21 only recite the following additional elements –
…at least one hardware processor; and at least one storage device coupled to the at least one hardware processor and for storing instructions that are operable, when executed by the at least one hardware processor to cause the at least one hardware processor to perform operations comprising…; …a trained machine learning model, wherein the trained machine learning model… [Claim 11],
… A computer-readable storage medium storing a program of instructions executable by a machine…; …a trained machine learning model, wherein the trained machine learning model… [Claim 21].
The modeling elements are not considered to be described at a level of particularity considered to demonstrate an improvement to any particular field of technology, nor to the functioning of computers. Therefore, Examiner respectfully maintains that the computing system and graphical user interface are recited at a high level of generate, and do not amount to significantly more than the abstract idea for the reasons discussed in 2A prong 2 with regard to MPEP 2106.05(a) and MPEP 2106.05(f). By the failure of the elements to integrate the abstract idea into a practical application there, the additional elements likewise fail to amount to an inventive concept that is significantly more than an abstract idea here, in Step 2B. Thus, both individually or in combination, these limitations do not add significantly more to the judicial exception. As such, Examiner remains unpersuaded.
35 USC § 102/103 Rejections
First, Applicant argues that “Amended independent claim 1 involves processing event records to account for differences in time representation or system format ("processing the event records to account for differences in time representation or system format across the plurality of data sources"). Boss does not teach or suggest processing event records to account for differences in time representation or system format across multiple data sources. Amended independent claim 1 recites that such processing occurs after receiving event data and before generating activity records. Boss processes team-related data such as HR, code contributions, and email content, but does not describe resolving structural or temporal inconsistencies between these systems in the form of event records” [Arguments, page 14].
In response, Applicant’s arguments are considered but are not persuasive. Examiner respectfully disagrees and directs the Applicant to (Boss, ¶ 45, Retuning to FIG. 1, at 105, there are performed methods to cognitively analyze and classify activities by a team member(s) of the development team being evaluated. The cognitive classification enables users to create and understand cognitively, i.e., in detail, what each team member has done. In one embodiment, the system tracks on a periodic basis, e.g., daily, the activities (work) relating to the team member (developer), for example, relating to the code that was checked in by the team member, and how that user interacted and/or communicated, e.g., what was communicated (socially or collaboratively), in the context of development activities, e.g., in a social collaboration network or system, with colleagues while developing code. Such data may be considered unstructured, arrive from varying sources in no defined format, and may include text, speech, or other audio or video format), and to (Id., ¶ 50, At step 110, FIG. 1, the combined developer activity data that is generated based on the structured and unstructured data found in productivity data reservoir 250 is analyzed and a productivity index function is generated. That is, based on the cognitive classification of the activities of each developer from the team, the process proceeds to 110 to compute a productivity index function. In one embodiment, this productivity index function represents what an entity, e.g., a team manager, is desirous to get out of the product being developed, e.g., increased revenue growth, improved margin, increased sales, or any other objective or goal).
Here, Boss discloses resolving structural inconsistencies between structured and unstructured data in order to process event records, in accordance with the presently amended limitation of claim 1. Thus, Examiner respectfully maintains that the art of record anticipates the above-argued limitation. As such, Examiner remains unpersuaded.
Second, Applicant argues that “Amended independent claim 1 involves activity records with specific contextual metadata fields ("generating activity records each activity record including contextual metadata indicative of a task classification, a worker identifier, and at least one of an activity type and a task complexity"). Boss does not teach or suggest generating activity records in this structured form, nor does Boss identify or use this set of metadata fields in modeling or recommendation steps. Boss works with broad categories of data and team performance indicators, not activity records tied to these specific metadata elements” [Arguments, page 14].
In response, Applicant’s arguments are considered but are not persuasive. Examiner respectfully disagrees and directs the Applicant to (Boss, ¶ 38, FIG. 2 shows a linking of the various data sources 200 providing data and metadata for the tool to ingest and provide recommendations for improving productivity from the developers of the software development team. The data sources provide structured and unstructured data/metadata that is input and stored in a storage device, i.e., a productivity data reservoir 250. In one embodiment, the data/metadata is stored in the form of one or more productivity matrices (not shown) in the productivity data reservoir 250. More specifically, the productivity data reservoir is created by ingesting and transforming data and metadata for key product performance metrics across the company or like entity), and to (Id., ¶ 26, A further program module 330 provides analytics to classify a developer's activity. Such a module 330 provides for a cognitive classification of a developer. In one embodiment, the module may implement or access a cognitive system, e.g., IBM's Watson® Natural Language Classifier and IBM's Watson® Explorer, or like, cognitive search and content analysis platform that may be leveraged to understand the detailed nature of the work each team member performs. In one embodiment, cognitive algorithms are applied to social data, human resources (HR) data and source code management data to determine exact activities performed by person, such as development, testing, product management, support, operations, etc. In one embodiment, this information may be combined with other data to obtain a detailed understanding of how each developer(s) is(are) spending their time on each task and activity).
Here, and in Figure 2, Boss discloses generating activity records including contextual metadata in order to model labor efficiency. Examiner maintains that classifying developer activities as described in Boss anticipates the activity record and classification elements of the present invention. Thus, Examiner respectfully maintains that the art of record anticipates the above-argued limitation. As such, Examiner remains unpersuaded.
Third, Applicant argues that “Amended independent claim 1 involves two-stage effort value estimation process or modeling ("allocating work effort based on the time intervals from the activity records to obtain a preliminary effort value indicating amount of effort for each activity record" and then "generating a final effort value by adjusting the preliminary effort value based on the contextual metadata "). Boss does not teach or suggest allocating effort values to specific activity records, nor does Boss teach or suggest adjusting those values using record-level metadata such as task complexity or activity type” [Arguments, page 15].
In response, Applicant’s arguments are considered but are not persuasive. Examiner respectfully disagrees and directs the Applicant to (Boss, ¶ 58, In one embodiment, given the current and historical data that has been collected from the systems that measure user's behavior and personal productivity and/or product performance, a computer run model is generated that is configured to find which team(s) were most productive, and indicate which attributes (i.e., performance indicators) had the most impact upon the most productive team. In one embodiment, machine learning algorithms (such as multivariate linear models) are trained to establish quantitative relationships between the profiles of most effective development team (data derived from steps 102 and 105) and desired performance objectives (based on the model weights data input by the user at step 116 or determined at 120, FIG. 1). Support vector machines, multilinear models and regression based models can alternatively be trained and applied at step 118 to produce similar results based on the developers' personal and productivity data relating to the product and software product financial data received (discloses generating and adjusting an effort value)), (Id., ¶ 69, In on embodiment, in the computing system of FIG. 3, multivariate linear machine learning algorithms are implemented and the model is continuously updated and trained with most positive outcomes to correlate and learn and recognize the most important attributes (parameters) that most positively increases team productivity. These positive predicting attributes are alternatively referred to as key performance indicators (KPI) and may change over time. Consequently, the recommendations (KPI's) and their target values such as shown in recommendation table 500 of FIG. 5, may be change over time).
Here, Boss discloses feeding current data including effort values based on contextual metadata to machine learning algorithms in order to determine a final adjusted effort value with respect to a software developer’s personal productivity, in accordance with the presently amended limitation of the present invention. Thus, Examiner respectfully maintains that the art of record anticipates the above-argued limitation. As such, Examiner remains unpersuaded.
Fourth, Applicant argues that “Amended independent claim 1 involves machine-readable report segmented by specific fields ("generating a machine-readable report including the activity records and corresponding effort values, wherein the report is segmented by at least one of time period, task classification, and worker, and is configured for display via a graphical user interface"). Boss mentions dashboards but does not disclose segmenting output by these fields or presenting effort values derived through the structured modeling of activity records” [Arguments, page 15].
In response, Applicant’s arguments are considered but are not persuasive. Examiner respectfully disagrees and directs the Applicant to (Boss, ¶ 62, FIG. 4 shows an example dashboard display 400 providing an operational read-out of productivity index 402 for a particular individual or team, with an indication of example top improvement areas, 410, 420, 430. The dashboard 400, in one embodiment, depicts an operational or benchmarking type approach by indicating comparisons of particular KPI attributes for a developer's team with other teams having average and more productive levels. In particular, data from the outputs of the model algorithms are formatted for display as shown in example dashboard 400 to provide visualizations for example KPI attributes 410 (“Attrition %” attrition rate attribute), 420 (“% Collocated” attribute), and 430 (“$k Cost Compensation per HC” or salary attribute). For example, from the dashboard 400 of FIG. 4, there is depicted for each improvement area 410-430, a developer's team's performance over a historical time period plotted against other teams that may have a similar composition, e.g., an average performing development team or compared against the best performing team. Via the dashboard, a user can track the performance for the displayed KPIs attributes over time can further show whether one individual or team's performance indicator goals have been met. Thus, for first example improvement area 410 (business objective parameter is “per cent attrition”), there is shown a developer's team's performance over a historical time period 411, and showing their performance as compared to a performance 414 averaged across many development teams, and further differentiated against the best performing team 417).
Here, and in Figure 4, Boss depicts and describes report configured for GUI display segmented by quarterly time periods and including separate elements for tracking effort/improvements in each classified task, in accordance with the presently amended limitation of the present invention. Thus, Examiner respectfully maintains that the art of record anticipates the above-argued limitation. As such, Examiner remains unpersuaded.
Fifth, Applicant argues that “Amended independent claim 11 involves system architecture and specific functional sequencing (a hardware processor and a storage device executing specific instructions for assessing labor efficiency of knowledge work). Boss is focused on software analysis and recommendation logic and does not disclose a system architecture where processors perform the operations in the structured sequence required by amended independent claim 11. There is no teaching or suggestion in Boss of a computing system receiving work-related event data and producing effort-adjusted activity records as described in amended independent claim 11” [Arguments, page 16].
In response, Applicant’s arguments are considered but are not persuasive. Examiner respectfully disagrees and observes that Boss details a system architecture including processors, computer modeling and graphical interfaces. In particular, Examiner directs the Applicant to (Boss ¶ 6, there is provided a computer-implemented method for improving the effectiveness and efficiency of software development operations. The method comprises: for each of a plurality of teams, receiving, at a hardware processor, activities data representing each team member's productivity relating to a product currently being developed; and receiving, at the hardware processor, further activities data relating to each team member's collaborative interactions; and performing, at the hardware processor, a cognitive classification of the activities for each of members of each team, and aggregating classifications of team members of each team to generate a respective individual team profile; generating, at the hardware processor, a respective productivity index function representing desired performance objectives for the team; and inputting, using the hardware processor, an individual team profile data and corresponding team productivity function index data to a model trained to correlate the individual team profile to learned positive attributes associated with a most productive development team of the plurality of teams; and generating, using the trained model, an output recommending which performance attributes of an individual team can be improved based on the model's correlating that team's data with the learned positive predicting attributes for increasing productivity of that team).
Here, Boss describes computer elements which anticipate those in the present claims. As such, Examiner remains unpersuaded.
Sixth, Applicant argues that “Amended independent claim 11 involves generation of activity records including contextual metadata "generating activity records each activity record including contextual metadata indicative of a task classification, a worker identifier, and at least one of an activity type and a task complexity"). Boss does not teach or suggest the creation of such activity records, nor the specific metadata fields. Boss's disclosures around 'contributions' or 'interactions' are abstracted at a higher team level and not implemented at the granularity of per-record contextual metadata with effort attribution” [Arguments, pages 16-17].
In response, Applicant’s arguments are considered but are not persuasive. Examiner respectfully disagrees and directs the Applicant to (Boss, ¶ 38, FIG. 2 shows a linking of the various data sources 200 providing data and metadata for the tool to ingest and provide recommendations for improving productivity from the developers of the software development team. The data sources provide structured and unstructured data/metadata that is input and stored in a storage device, i.e., a productivity data reservoir 250. In one embodiment, the data/metadata is stored in the form of one or more productivity matrices (not shown) in the productivity data reservoir 250. More specifically, the productivity data reservoir is created by ingesting and transforming data and metadata for key product performance metrics across the company or like entity), and to (Id., ¶ 26, A further program module 330 provides analytics to classify a developer's activity. Such a module 330 provides for a cognitive classification of a developer. In one embodiment, the module may implement or access a cognitive system, e.g., IBM's Watson® Natural Language Classifier and IBM's Watson® Explorer, or like, cognitive search and content analysis platform that may be leveraged to understand the detailed nature of the work each team member performs. In one embodiment, cognitive algorithms are applied to social data, human resources (HR) data and source code management data to determine exact activities performed by person, such as development, testing, product management, support, operations, etc. In one embodiment, this information may be combined with other data to obtain a detailed understanding of how each developer(s) is(are) spending their time on each task and activity).
Here, and in Figure 2, Boss discloses generating activity records including contextual metadata in order to model labor efficiency. Examiner maintains that classifying developer activities as described in Boss anticipates the activity record and classification elements of the present invention. Thus, Examiner respectfully maintains that the art of record anticipates the above-argued limitation. As such, Examiner remains unpersuaded.
Seventh, Applicant argues that “Amended independent claim 11 involves two-stage effort modeling using trained data ("allocating work effort based on the time intervals from the activity records to associate a cost with the activities and to obtain a preliminary effort value indicating amount of effort for each time interval" and "generating a final effort value for each activity record by applying a trained data model, wherein the trained data model is configured to adjust the preliminary effort value based on contextual metadata included in the activity record"). The approach of the two-stage effort modeling using trained data includes allocating a preliminary effort value based on time intervals and then adjusting that value with a trained data model using contextual metadata. Boss fails to teach or suggest a system in which effort is first allocated at a time-based level and then refined using per-record metadata fields via a trained data model. Boss's use of machine learning appears limited to KPI-based recommendation logic and does not involve modeling individual labor effort values based on structured activity features ” [Arguments, page 17].
In response, Applicant’s arguments are considered but are not persuasive. Examiner respectfully disagrees and directs the Applicant to (Boss, ¶ 58, In one embodiment, given the current and historical data that has been collected from the systems that measure user's behavior and personal productivity and/or product performance, a computer run model is generated that is configured to find which team(s) were most productive, and indicate which attributes (i.e., performance indicators) had the most impact upon the most productive team. In one embodiment, machine learning algorithms (such as multivariate linear models) are trained to establish quantitative relationships between the profiles of most effective development team (data derived from steps 102 and 105) and desired performance objectives (based on the model weights data input by the user at step 116 or determined at 120, FIG. 1). Support vector machines, multilinear models and regression based models can alternatively be trained and applied at step 118 to produce similar results based on the developers' personal and productivity data relating to the product and software product financial data received (discloses generating and adjusting an effort value)), (Id., ¶ 69, In on embodiment, in the computing system of FIG. 3, multivariate linear machine learning algorithms are implemented and the model is continuously updated and trained with most positive outcomes to correlate and learn and recognize the most important attributes (parameters) that most positively increases team productivity. These positive predicting attributes are alternatively referred to as key performance indicators (KPI) and may change over time. Consequently, the recommendations (KPI's) and their target values such as shown in recommendation table 500 of FIG. 5, may be change over time).
Here, Boss discloses feeding current data including effort values based on contextual metadata to machine learning algorithms in order to determine a final adjusted effort value with respect to a software developer’s personal productivity, in accordance with the presently amended limitation of the present invention. Thus, Examiner respectfully maintains that the art of record anticipates the above-argued limitation. As such, Examiner remains unpersuaded.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-22 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Step 1: Claims 1-22 are directed to statutory categories, namely a process (claims 1-10), a machine (claims 11-20) and an article of manufacture (claims 21-22).
Step 2A, Prong 1: Claims 1, 11 and 21 in part, recite the following abstract idea:
…A computer-implemented method of assessing labor efficiency of knowledge work, the method comprising, by… the steps of: receiving event data extracted from a plurality of data sources, the event data being related to activities conducted by knowledge workers, to obtain event records, each event record containing the identity of each worker associated with an event and either a time interval or a point in time when the event occurred; processing the event records to account for differences in time representation or system format across the plurality of data sources; generating activity records associated with the time intervals during a time period from the processed event records, the activity records containing information about work activities based on the event records, each activity record including contextual metadata indicative of a task classification, a worker identifier, and at least one of an activity type and a task complexity; and allocating work effort based on the time intervals from the activity records to associate a cost with the activities and to obtain an effort value indicating amount of effort for each activity record; generating a final effort value by adjusting the preliminary effort value based on the contextual metadata included in the activity record; and generating a machine-readable report including the activity records and corresponding effort values, wherein the report is segmented by at least one of time period, task classification, and worker, and is configured for display via… [Claim 1], …A system for assessing labor efficiency of knowledge work, the system comprising:… receiving event data extracted from one or more data sources, the data being related to activities conducted by knowledge workers, to obtain event records, each event record containing the identity of each worker associated with an event and either a time interval or a point in time when the event occurred; generating activity records associated with time intervals during a time period from the event records, the activity records containing information related to the events that occurred during the time intervals, each activity record including contextual metadata indicative of a task classification, a worker identifier, and at least one of an activity type and a task complexity; allocating work effort based on the time intervals from the activity records to associate a cost with the activities and to obtain a preliminary effort value indicating amount of effort for each time interval; and generating a final effort value for each activity record by applying … is configured to adjust the preliminary effort value based on contextual metadata included in the activity record [Claim 11],
…to perform operations, for assessing labor efficiency of knowledge work, comprising: receiving event data extracted from one or more data sources, the data being related to activities conducted by knowledge workers to obtain records, each event record containing the identity of each worker associated with an event and either a time interval or a point in time when the event occurred; generating activity records associated with time intervals during a time period from the event records, the activity records containing information about the events that occurred during the time intervals, each activity record including contextual metadata indicative of a task classification, a worker identifier, and at least one of an activity type and a task complexity; and allocating work effort based on the time intervals from the activity records to associate a cost with the activities and to obtain an effort value indicating amount of effort for each time interval; and generating a final effort value for each activity record by applying … is configured to adjust the preliminary effort value based on contextual metadata included in the activity record [Claim 21].
These concepts are not meaningfully different than the following concepts identified by the MPEP:
Concepts relating to certain methods of organizing human activity. The aforementioned limitations describe steps for managing personal behavior or relationships or interactions between people, including social activities, teaching, and following rules or instructions. Specifically, determining work effort values based on activity records of a worker is considered to be steps for managing personal behavior. As such, claims 1, 11 and 21 recite concepts identified as abstract ideas.
The dependent claims recite limitations relative to the independent claims, including, for example:
…further comprising the step of classifying the activity records. [Claim 2],
…further comprising the step of enriching the activity records to compute additional information about the activities based on the level of effort that goes into the activities and activity metadata [Claim 3],
…further comprising the step of classifying the enriched activity records [Claim 4],
…further comprising presenting the classified activity records to a user [Claim 5],
…wherein the classified activity records are presented to a user in the form of a report [Claim 6].
The limitations of these dependent claims are merely narrowing the abstract idea identified in the independent claims, and thus, the dependent claims also recite abstract ideas.
Step 2A, Prong 2: This judicial exception is not integrated into a practical application. In particular, claims 1, 11 and 21 only recite the following additional elements –
…a computing system… ; …a graphical user interface [Claim 1],
…at least one hardware processor; and at least one storage device coupled to the at least one hardware processor and for storing instructions that are operable, when executed by the at least one hardware processor to cause the at least one hardware processor to perform operations comprising…; …a trained machine learning model, wherein the trained machine learning model… [Claim 11],
… A computer-readable storage medium storing a program of instructions executable by a machine…; …a trained machine learning model, wherein the trained machine learning model… [Claim 21].
The apparatus and executable instructions are recited at a high-level of generality (see MPEP § 2106.05(a)), like the following MPEP example:
iii. Gathering and analyzing information using conventional techniques and displaying the result, TLI Communications, 823 F.3d at 612-13, 118 USPQ2d at 1747-48;
Furthermore, the computer implemented element is considered to amount to no more than mere instructions to apply the exception using a generic computer component (see MPEP 2106.05(f)), like the following MPEP example:
i. A commonplace business method or mathematical algorithm being applied on a general purpose computer, Alice Corp. Pty. Ltd. V. CLS Bank Int’l, 573 U.S. 208, 223, 110 USPQ2d 1976, 1983 (2014); Gottschalk v. Benson, 409 U.S. 63, 64, 175 USPQ 673, 674 (1972); Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015);
Accordingly, these additional elements do not integrate the abstract idea into a practical application.
The remaining dependent claims do not recite any new additional elements, and thus do not integrate the abstract idea into a practical application.
Step 2B: Claims 1, 11 and 21 and their underlying limitations, steps, features and terms, considered both individually and as a whole, do not include additional elements that are sufficient to amount to significantly more than the judicial exception for the following reasons:
Independent claims 1, 11 and 21 only recite the following additional elements –
…a computing system… ; …a graphical user interface [Claim 1],
…at least one hardware processor; and at least one storage device coupled to the at least one hardware processor and for storing instructions that are operable, when executed by the at least one hardware processor to cause the at least one hardware processor to perform operations comprising…; …a trained machine learning model, wherein the trained machine learning model… [Claim 11],
… A computer-readable storage medium storing a program of instructions executable by a machine…; …a trained machine learning model, wherein the trained machine learning model… [Claim 21].
These elements do not amount to significantly more than the abstract idea for the reasons discussed in 2A prong 2 with regard to MPEP 2106.05(a) and MPEP 2106.05(f). By the failure of the elements to integrate the abstract idea into a practical application there, the additional elements likewise fail to amount to an inventive concept that is significantly more than an abstract idea here, in Step 2B.
As such, both individually or in combination, these limitations do not add significantly more to the judicial exception.
The remaining dependent claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the dependent claims do not recite any new additional elements other than those mentioned in the independent claims, which amount to no more than mere instructions to apply the exception using a generic computer component (see MPEP 2106.05(f)). As such, these claims are not patent eligible.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-7, 10-17 and 20-22 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Boss et al., U.S. Publication No. 2019/0012167 [hereinafter Boss].
Regarding Claim 1, Boss anticipates …A computer-implemented method of assessing labor efficiency of knowledge work, the method comprising, by a computing system, the steps of: receiving event data extracted from a plurality of data sources, the event data being related to activities conducted by knowledge workers, to obtain event records, each event record containing the identity of each worker associated with an event and either a time interval or a point in time when the event occurred (Boss, ¶ 41, Human resources data 208 may include data regarding a developer's salary. For example, a first developer may be deemed an effective developer and make a low salary, while a second developer that is twice as effective (discloses labor efficiency of knowledge work) may receive a ten times greater salary, which would mean the first developer may be more effective per unit of money. Moreover, there may be obtained from an entity's human resources department further developer information, including: their position, title, and the product they are developing, attrition, salaries, tenure, etc.), (Id., ¶ 26, A further program module 330 provides analytics to classify a developer's activity. Such a module 330 provides for a cognitive classification of a developer. In one embodiment, the module may implement or access a cognitive system, e.g., IBM's Watson® Natural Language Classifier and IBM's Watson® Explorer, or like, cognitive search and content analysis platform that may be leveraged to understand the detailed nature of the work each team member performs. In one embodiment, cognitive algorithms are applied to social data, human resources (HR) data and source code management data to determine exact activities performed by person, such as development, testing, product management, support, operations, etc. In one embodiment, this information may be combined with other data to obtain a detailed understanding of how each developer(s) is(are) spending their time on each task and activity. (discloses obtaining event records and identities for each worker)), (Id., ¶ 45, Retuning to FIG. 1, at 105, there are performed methods to cognitively analyze and classify activities by a team member(s) of the development team being evaluated. The cognitive classification enables users to create and understand cognitively, i.e., in detail, what each team member has done. In one embodiment, the system tracks on a periodic basis, e.g., daily, the activities (work) relating to the team member (developer), for example, relating to the code that was checked in by the team member, and how that user interacted and/or communicated, e.g., what was communicated (socially or collaboratively), in the context of development activities, e.g., in a social collaboration network or system, with colleagues while developing code. Such data may be considered unstructured, arrive from varying sources in no defined format, and may include text, speech, or other audio or video format);
processing the event records to account for differences in time representation or system format across the plurality of data sources (Id., ¶ 26, A further program module 330 provides analytics to classify a developer's activity. Such a module 330 provides for a cognitive classification of a developer. In one embodiment, the module may implement or access a cognitive system, e.g., IBM's Watson® Natural Language Classifier and IBM's Watson® Explorer, or like, cognitive search and content analysis platform that may be leveraged to understand the detailed nature of the work each team member performs. In one embodiment, cognitive algorithms are applied to social data, human resources (HR) data and source code management data to determine exact activities performed by person, such as development, testing, product management, support, operations, etc. In one embodiment, this information may be combined with other data to obtain a detailed understanding of how each developer(s) is(are) spending their time on each task and activity. (discloses obtaining event records and identities for each worker)), (Id., ¶ 45, Retuning to FIG. 1, at 105, there are performed methods to cognitively analyze and classify activities by a team member(s) of the development team being evaluated. The cognitive classification enables users to create and understand cognitively, i.e., in detail, what each team member has done. In one embodiment, the system tracks on a periodic basis, e.g., daily, the activities (work) relating to the team member (developer), for example, relating to the code that was checked in by the team member, and how that user interacted and/or communicated, e.g., what was communicated (socially or collaboratively), in the context of development activities, e.g., in a social collaboration network or system, with colleagues while developing code. Such data may be considered unstructured, arrive from varying sources in no defined format, and may include text, speech, or other audio or video format), (Id., ¶ 50, At step 110, FIG. 1, the combined developer activity data that is generated based on the structured and unstructured data found in productivity data reservoir 250 (discloses processing event records to account for format differences) is analyzed and a productivity index function is generated. That is, based on the cognitive classification of the activities of each developer from the team, the process proceeds to 110 to compute a productivity index function. In one embodiment, this productivity index function represents what an entity, e.g., a team manager, is desirous to get out of the product being developed, e.g., increased revenue growth, improved margin, increased sales, or any other objective or goal);
generating activity records associated with the time intervals during a time period from the processed event records, the activity records containing information about work activities based on the event records, each activity record including contextual metadata indicative of a task classification, a worker identifier, and at least one of an activity type and a task complexity (Id., ¶ 47, The interaction data and developer's activities, obtained at step 105, FIG. 1, may be combined to make various determinations relating to the developer and that developer's team. For example, the analysis methods determine how a developer's day(s) is(are) spent, e.g., whether/when and how often new code was checked in, (discloses generating activity records based on the event records) whether a developer was chatting with colleagues all day, or was given free coffee or tea, etc. This determination may be combined with other data obtained from the productivity reservoir or repository 250. For example, the developer's delivery of code may be combined with that developer's financial and other personal information and/or product financial information, e.g., revenue, and used to classify the developer's productivity. There is a trade-off between various activities the developer can be engaged in. For example, a developer who does nothing else during the day but generate lines of code would have one classification or role assigned, while a developer that develops efficient algorithms that reduces lines of code yet takes a lot of daily work breaks and/or is more interactive or collaborative may be assigned a different role or classification), (Id., ¶ 38, FIG. 2 shows a linking of the various data sources 200 providing data and metadata for the tool to ingest and provide recommendations for improving productivity from the developers of the software development team. The data sources provide structured and unstructured data/metadata that is input and stored in a storage device, i.e., a productivity data reservoir 250. In one embodiment, the data/metadata is stored in the form of one or more productivity matrices (not shown) in the productivity data reservoir 250. More specifically, the productivity data reservoir is created by ingesting and transforming data and metadata for key product performance metrics across the company or like entity), (Id., ¶ 26, A further program module 330 provides analytics to classify a developer's activity (discloses task classifications) Such a module 330 provides for a cognitive classification of a developer. In one embodiment, the module may implement or access a cognitive system, e.g., IBM's Watson® Natural Language Classifier and IBM's Watson® Explorer, or like, cognitive search and content analysis platform that may be leveraged to understand the detailed nature of the work each team member performs. In one embodiment, cognitive algorithms are applied to social data, human resources (HR) data and source code management data to determine exact activities performed by person, such as development, testing, product management, support, operations, etc. In one embodiment, this information may be combined with other data to obtain a detailed understanding of how each developer(s) is(are) spending their time on each task and activity), (Id., Fig. 2, figure depicts metadata including a worker identifier and activity type (i.e. software changes));
PNG
media_image1.png
331
406
media_image1.png
Greyscale
allocating work effort based on the time intervals from the activity records to obtain a preliminary effort value indicating amount of effort for each activity record (Id., ¶ 41, Human resources data 208 may include data regarding a developer's salary. For example, a first developer may be deemed an effective developer and make a low salary, while a second developer that is twice as effective may receive a ten times greater salary, which would mean the first developer may be more effective per unit of money (discloses associating a cost with the developer activities to obtain an effort value (i.e. effectiveness per unit of money)). Moreover, there may be obtained from an entity's human resources department further developer information, including: their position, title, and the product they are developing, attrition, salaries, tenure, etc.), (Id., ¶ 33, In one embodiment, a cognitive training system/recommender program module 380 is stored in memory 350 and implements a model training algorithm that builds the knowledgebase 360 based on developer(s) activities and personal productivity, and product performance/financials over time. The model aggregates data for all developer's of specific development teams as will be described with respect to the method of FIG. 1), (Id., ¶ 62, FIG. 4 shows an example dashboard display 400 providing an operational read-out of productivity index 402 for a particular individual or team, with an indication of example top improvement areas, 410, 420, 430. The dashboard 400, in one embodiment, depicts an operational or benchmarking type approach by indicating comparisons of particular KPI attributes for a developer's team with other teams having average and more productive levels. In particular, data from the outputs of the model algorithms are formatted for display as shown in example dashboard 400 to provide visualizations for example KPI attributes 410 (“Attrition %” attrition rate attribute), 420 (“% Collocated” attribute), and 430 (“$k Cost Compensation per HC” or salary attribute). For example, from the dashboard 400 of FIG. 4, there is depicted for each improvement area 410-430, a developer's team's performance over a historical time period plotted against other teams that may have a similar composition, e.g., an average performing development team or compared against the best performing team. Via the dashboard, a user can track the performance for the displayed KPIs attributes over time can further show whether one individual or team's performance indicator goals have been met. Thus, for first example improvement area 410 (business objective parameter is “per cent attrition”), there is shown a developer's team's performance over a historical time period 411, and showing their performance as compared to a performance 414 averaged across many development teams, and further differentiated against the best performing team 417);
generating a final effort value by adjusting the preliminary effort value based on the contextual metadata included in the activity record (Id., ¶ 36, Based on the input data, the trained system/recommender module 350 takes the KPIs and builds the model that determines which of those KPI would be most predictive and/or important to address to increase productivity. The model learns, over time, which input parameters have the most improved effect on the output parameters for a particular productivity. The machine learning algorithms implemented in the model provides a set of predictive and descriptive data elements at a predetermined confidence level), (Id., ¶ 38, FIG. 2 shows a linking of the various data sources 200 providing data and metadata for the tool to ingest and provide recommendations for improving productivity from the developers of the software development team. The data sources provide structured and unstructured data/metadata that is input and stored in a storage device, i.e., a productivity data reservoir 250. In one embodiment, the data/metadata is stored in the form of one or more productivity matrices (not shown) in the productivity data reservoir 250. More specifically, the productivity data reservoir is created by ingesting and transforming data and metadata for key product performance metrics across the company or like entity), (Id., ¶ 58, In one embodiment, given the current and historical data that has been collected from the systems that measure user's behavior and personal productivity and/or product performance, a computer run model is generated that is configured to find which team(s) were most productive, and indicate which attributes (i.e., performance indicators) had the most impact upon the most productive team. In one embodiment, machine learning algorithms (such as multivariate linear models) are trained to establish quantitative relationships between the profiles of most effective development team (data derived from steps 102 and 105) and desired performance objectives (based on the model weights data input by the user at step 116 or determined at 120, FIG. 1). Support vector machines, multilinear models and regression based models can alternatively be trained and applied at step 118 to produce similar results based on the developers' personal and productivity data relating to the product and software product financial data received (discloses generating and adjusting an effort value)), (Id., ¶ 69, In on embodiment, in the computing system of FIG. 3, multivariate linear machine learning algorithms are implemented and the model is continuously updated and trained with most positive outcomes to correlate and learn and recognize the most important attributes (parameters) that most positively increases team productivity. These positive predicting attributes are alternatively referred to as key performance indicators (KPI) and may change over time. Consequently, the recommendations (KPI's) and their target values such as shown in recommendation table 500 of FIG. 5, may be change over time);
and generating a machine-readable report including the activity records and corresponding effort values, wherein the report is segmented by at least one of time period, task classification, and worker, and is configured for display via a graphical user interface (Id., ¶ 62, FIG. 4 shows an example dashboard display 400 providing an operational read-out of productivity index 402 for a particular individual or team, with an indication of example top improvement areas, 410, 420, 430. The dashboard 400, in one embodiment, depicts an operational or benchmarking type approach by indicating comparisons of particular KPI attributes for a developer's team with other teams having average and more productive levels. In particular, data from the outputs of the model algorithms are formatted for display as shown in example dashboard 400 to provide visualizations for example KPI attributes 410 (“Attrition %” attrition rate attribute), 420 (“% Collocated” attribute), and 430 (“$k Cost Compensation per HC” or salary attribute). For example, from the dashboard 400 of FIG. 4, there is depicted for each improvement area 410-430, a developer's team's performance over a historical time period plotted against other teams that may have a similar composition, e.g., an average performing development team or compared against the best performing team. Via the dashboard, a user can track the performance for the displayed KPIs attributes over time can further show whether one individual or team's performance indicator goals have been met. Thus, for first example improvement area 410 (business objective parameter is “per cent attrition”), there is shown a developer's team's performance over a historical time period 411, and showing their performance as compared to a performance 414 averaged across many development teams, and further differentiated against the best performing team 417), (Id., Fig. 4, figure depicts a report configured for GUI display segmented by quarterly time periods and including separate elements for tracking effort/improvements in each classified task)
PNG
media_image2.png
536
658
media_image2.png
Greyscale
Regarding Claim 2, Boss anticipates …The method as claimed in claim 1…
Boss further anticipates …further comprising the step of classifying the activity records (Boss, ¶ 26, A further program module 330 provides analytics to classify a developer's activity. (discloses classifying activity records) Such a module 330 provides for a cognitive classification of a developer. In one embodiment, the module may implement or access a cognitive system, e.g., IBM's Watson® Natural Language Classifier and IBM's Watson® Explorer, or like, cognitive search and content analysis platform that may be leveraged to understand the detailed nature of the work each team member performs. In one embodiment, cognitive algorithms are applied to social data, human resources (HR) data and source code management data to determine exact activities performed by person, such as development, testing, product management, support, operations, etc. In one embodiment, this information may be combined with other data to obtain a detailed understanding of how each developer(s) is(are) spending their time on each task and activity).
Regarding Claim 3, Boss anticipates …The method as claimed in claim 1…
Boss further anticipates …further comprising the step of enriching the activity records by computing additional information about the activities based on the level of effort that goes into the activities and activity metadata (Boss, ¶ 37, In one aspect, the tool 300 runs a method 100 such as described with respect to FIG. 1. As shown at a first step 102, FIG. 1, the method continually ingests data and metadata for the tool, and transforms the ingested data/metadata (discloses enriching activity records using activity metadata) into a productivity data reservoir which may form the developer knowledgebase 360), (Id., ¶ 38, FIG. 2 shows a linking of the various data sources 200 providing data and metadata for the tool to ingest and provide recommendations for improving productivity from the developers of the software development team. The data sources provide structured and unstructured data/metadata that is input and stored in a storage device, i.e., a productivity data reservoir 250. In one embodiment, the data/metadata is stored in the form of one or more productivity matrices (not shown) in the productivity data reservoir 250. More specifically, the productivity data reservoir is created by ingesting and transforming data and metadata for key product performance metrics across the company or like entity), (Id., ¶ 47, The interaction data and developer's activities, obtained at step 105, FIG. 1, may be combined to make various determinations relating to the developer and that developer's team. For example, the analysis methods determine how a developer's day(s) is(are) spent, e.g., whether/when and how often new code was checked in, whether a developer was chatting with colleagues all day, or was given free coffee or tea, etc. This determination may be combined with other data obtained from the productivity reservoir or repository 250. For example, the developer's delivery of code may be combined with that developer's financial and other personal information and/or product financial information, e.g., revenue, and used to classify the developer's productivity. There is a trade-off between various activities the developer can be engaged in. For example, a developer who does nothing else during the day but generate lines of code would have one classification or role assigned, while a developer that develops efficient algorithms that reduces lines of code yet takes a lot of daily work breaks and/or is more interactive or collaborative may be assigned a different role or classification (discloses effort level)).
Regarding Claim 4, Boss anticipates …The method as claimed in claim 3…
Boss further anticipates …further comprising the step of classifying the enriched activity records (Boss, ¶ 47, The interaction data and developer's activities, obtained at step 105, FIG. 1, may be combined to make various determinations relating to the developer and that developer's team. For example, the analysis methods determine how a developer's day(s) is(are) spent, e.g., whether/when and how often new code was checked in, whether a developer was chatting with colleagues all day, or was given free coffee or tea, etc. This determination may be combined with other data obtained from the productivity reservoir or repository 250. For example, the developer's delivery of code may be combined with that developer's financial and other personal information and/or product financial information, e.g., revenue, and used to classify the developer's productivity (discloses classifying enriched activity records). There is a trade-off between various activities the developer can be engaged in. For example, a developer who does nothing else during the day but generate lines of code would have one classification or role assigned, while a developer that develops efficient algorithms that reduces lines of code yet takes a lot of daily work breaks and/or is more interactive or collaborative may be assigned a different role or classification).
Regarding Claim 5, Boss anticipates …The method as claimed in claim 2…
Boss further anticipates …further comprising presenting the classified activity records to a user (Boss, ¶ 45, Retuning to FIG. 1, at 105, there are performed methods to cognitively analyze and classify activities by a team member(s) of the development team being evaluated. The cognitive classification enables users to create and understand cognitively, i.e., in detail, what each team member has done. In one embodiment, the system tracks on a periodic basis, e.g., daily, the activities (work) relating to the team member (developer), for example, relating to the code that was checked in by the team member, and how that user interacted and/or communicated, e.g., what was communicated (socially or collaboratively), in the context of development activities, e.g., in a social collaboration network or system, with colleagues while developing code. Such data may be considered unstructured, arrive from varying sources in no defined format, and may include text, speech, or other audio or video format), (Id., ¶ 61, Returning to 118, FIG. 1, having determined the quantitative relationships between developers' profiles and aggregate productivity function, in one embodiment, the method continues to 125, where, based on the determined quantitative relationships between developers' profiles and aggregate productivity function, the method provides operational read-out and assessment. In one embodiment, the system leverages reporting dashboards to provide a visual display of an overall productivity index with recommended improvement areas for the development team).
Regarding Claim 6, Boss anticipates …The method as claimed in claim 5…
Boss further anticipates …further comprising presenting the classified activity records to a user (Boss, ¶ 45, Retuning to FIG. 1, at 105, there are performed methods to cognitively analyze and classify activities by a team member(s) of the development team being evaluated. The cognitive classification enables users to create and understand cognitively, i.e., in detail, what each team member has done. In one embodiment, the system tracks on a periodic basis, e.g., daily, the activities (work) relating to the team member (developer), for example, relating to the code that was checked in by the team member, and how that user interacted and/or communicated, e.g., what was communicated (socially or collaboratively), in the context of development activities, e.g., in a social collaboration network or system, with colleagues while developing code. Such data may be considered unstructured, arrive from varying sources in no defined format, and may include text, speech, or other audio or video format), (Id., ¶ 61, Returning to 118, FIG. 1, having determined the quantitative relationships between developers' profiles and aggregate productivity function, in one embodiment, the method continues to 125, where, based on the determined quantitative relationships between developers' profiles and aggregate productivity function, the method provides operational read-out and assessment. In one embodiment, the system leverages reporting dashboards to provide a visual display of an overall productivity index with recommended improvement areas for the development team).
Regarding Claim 7, Boss anticipates …The method as claimed in claim 4…
Boss further anticipates …wherein the classified enriched activity records are presented to a user (Boss, ¶ 45, Retuning to FIG. 1, at 105, there are performed methods to cognitively analyze and classify activities by a team member(s) of the development team being evaluated. The cognitive classification enables users to create and understand cognitively, i.e., in detail, what each team member has done. In one embodiment, the system tracks on a periodic basis, e.g., daily, the activities (work) relating to the team member (developer), for example, relating to the code that was checked in by the team member, and how that user interacted and/or communicated, e.g., what was communicated (socially or collaboratively), in the context of development activities, e.g., in a social collaboration network or system, with colleagues while developing code. Such data may be considered unstructured, arrive from varying sources in no defined format, and may include text, speech, or other audio or video format), (Id., ¶ 61, Returning to 118, FIG. 1, having determined the quantitative relationships between developers' profiles and aggregate productivity function, in one embodiment, the method continues to 125, where, based on the determined quantitative relationships between developers' profiles and aggregate productivity function, the method provides operational read-out and assessment. In one embodiment, the system leverages reporting dashboards to provide a visual display of an overall productivity index with recommended improvement areas for the development team), (Id., ¶ 62, FIG. 4 shows an example dashboard display 400 providing an operational read-out of productivity index 402 for a particular individual or team, with an indication of example top improvement areas, 410, 420, 430. The dashboard 400, in one embodiment, depicts an operational or benchmarking type approach by indicating comparisons of particular KPI attributes for a developer's team with other teams having average and more productive levels. In particular, data from the outputs of the model algorithms are formatted for display as shown in example dashboard 400 to provide visualizations for example KPI attributes 410 (“Attrition %” attrition rate attribute), 420 (“% Collocated” attribute), and 430 (“$k Cost Compensation per HC” or salary attribute). For example, from the dashboard 400 of FIG. 4, there is depicted for each improvement area 410-430, a developer's team's performance over a historical time period plotted against other teams that may have a similar composition, e.g., an average performing development team or compared against the best performing team. Via the dashboard, a user can track the performance for the displayed KPIs attributes over time can further show whether one individual or team's performance indicator goals have been met. Thus, for first example improvement area 410 (business objective parameter is “per cent attrition”), there is shown a developer's team's performance over a historical time period 411, and showing their performance as compared to a performance 414 averaged across many development teams, and further differentiated against the best performing team 417).
Regarding Claim 10, Boss anticipates …The method as claimed in claim 1…
Boss further anticipates …wherein the knowledge work is software development work (Boss, ¶ 1, The present invention generally relates to systems and methods for maximizing the productivity of software development teams comprising plural individuals).
Regarding Claim 11, Boss anticipates …A system for assessing labor efficiency of knowledge work, the system comprising: at least one hardware processor; and at least one storage device coupled to the at least one hardware processor and for storing instructions that are operable, when executed by the at least one hardware processor to cause the at least one hardware processor to perform operations comprising: receiving event data extracted from one or more data sources, the data being related to activities conducted by knowledge workers, to obtain event records, each event record containing the identity of each worker associated with an event, and either a time interval or a point in time when the event occurred (Boss, ¶ 41, Human resources data 208 may include data regarding a developer's salary. For example, a first developer may be deemed an effective developer and make a low salary, while a second developer that is twice as effective (discloses labor efficiency of knowledge work) may receive a ten times greater salary, which would mean the first developer may be more effective per unit of money. Moreover, there may be obtained from an entity's human resources department further developer information, including: their position, title, and the product they are developing, attrition, salaries, tenure, etc.), (Id., ¶ 26, A further program module 330 provides analytics to classify a developer's activity. Such a module 330 provides for a cognitive classification of a developer. In one embodiment, the module may implement or access a cognitive system, e.g., IBM's Watson® Natural Language Classifier and IBM's Watson® Explorer, or like, cognitive search and content analysis platform that may be leveraged to understand the detailed nature of the work each team member performs. In one embodiment, cognitive algorithms are applied to social data, human resources (HR) data and source code management data to determine exact activities performed by person, such as development, testing, product management, support, operations, etc. In one embodiment, this information may be combined with other data to obtain a detailed understanding of how each developer(s) is(are) spending their time on each task and activity. (discloses obtaining event records and identities for each worker)), (Id., ¶ 45, Retuning to FIG. 1, at 105, there are performed methods to cognitively analyze and classify activities by a team member(s) of the development team being evaluated. The cognitive classification enables users to create and understand cognitively, i.e., in detail, what each team member has done. In one embodiment, the system tracks on a periodic basis, e.g., daily, the activities (work) relating to the team member (developer), for example, relating to the code that was checked in by the team member, and how that user interacted and/or communicated, e.g., what was communicated (socially or collaboratively), in the context of development activities, e.g., in a social collaboration network or system, with colleagues while developing code. Such data may be considered unstructured, arrive from varying sources in no defined format, and may include text, speech, or other audio or video format), (Id., ¶ 6, there is provided a computer-implemented method for improving the effectiveness and efficiency of software development operations. The method comprises: for each of a plurality of teams, receiving, at a hardware processor, activities data representing each team member's productivity relating to a product currently being developed; and receiving, at the hardware processor, further activities data relating to each team member's collaborative interactions; and performing, at the hardware processor, a cognitive classification of the activities for each of members of each team, and aggregating classifications of team members of each team to generate a respective individual team profile; generating, at the hardware processor, a respective productivity index function representing desired performance objectives for the team; and inputting, using the hardware processor, an individual team profile data and corresponding team productivity function index data to a model trained to correlate the individual team profile to learned positive attributes associated with a most productive development team of the plurality of teams; and generating, using the trained model, an output recommending which performance attributes of an individual team can be improved based on the model's correlating that team's data with the learned positive predicting attributes for increasing productivity of that team), (Id., ¶ 24, Computing system 300 includes at least a processor 302, a memory 304, e.g., for storing an operating system and program instructions, a network interface 306, a display device 308, an input device 309, and any other features common to a computing device. In some aspects, computing system 300 may, for example, be any computing device that is configured to communicate with a social media web-site 320 or web- or cloud-based server (not shown) over a public or private communications network 99);
generating activity records associated with the time intervals during a time period from the event records, the activity records containing information related to the events that occurred during the time intervals, each activity record including contextual metadata indicative of a task classification, a worker identifier, and at least one of an activity type and a task complexity (Id., ¶ 47, The interaction data and developer's activities, obtained at step 105, FIG. 1, may be combined to make various determinations relating to the developer and that developer's team. For example, the analysis methods determine how a developer's day(s) is(are) spent, e.g., whether/when and how often new code was checked in, (discloses generating activity records based on the event records) whether a developer was chatting with colleagues all day, or was given free coffee or tea, etc. This determination may be combined with other data obtained from the productivity reservoir or repository 250. For example, the developer's delivery of code may be combined with that developer's financial and other personal information and/or product financial information, e.g., revenue, and used to classify the developer's productivity. There is a trade-off between various activities the developer can be engaged in. For example, a developer who does nothing else during the day but generate lines of code would have one classification or role assigned, while a developer that develops efficient algorithms that reduces lines of code yet takes a lot of daily work breaks and/or is more interactive or collaborative may be assigned a different role or classification), (Id., ¶ 38, FIG. 2 shows a linking of the various data sources 200 providing data and metadata for the tool to ingest and provide recommendations for improving productivity from the developers of the software development team. The data sources provide structured and unstructured data/metadata that is input and stored in a storage device, i.e., a productivity data reservoir 250. In one embodiment, the data/metadata is stored in the form of one or more productivity matrices (not shown) in the productivity data reservoir 250. More specifically, the productivity data reservoir is created by ingesting and transforming data and metadata for key product performance metrics across the company or like entity), (Id., ¶ 26, A further program module 330 provides analytics to classify a developer's activity (discloses task classifications) Such a module 330 provides for a cognitive classification of a developer. In one embodiment, the module may implement or access a cognitive system, e.g., IBM's Watson® Natural Language Classifier and IBM's Watson® Explorer, or like, cognitive search and content analysis platform that may be leveraged to understand the detailed nature of the work each team member performs. In one embodiment, cognitive algorithms are applied to social data, human resources (HR) data and source code management data to determine exact activities performed by person, such as development, testing, product management, support, operations, etc. In one embodiment, this information may be combined with other data to obtain a detailed understanding of how each developer(s) is(are) spending their time on each task and activity), (Id., Fig. 2, figure depicts metadata including a worker identifier and activity type (i.e. software changes));
PNG
media_image1.png
331
406
media_image1.png
Greyscale
allocating work effort based on the time intervals from the activity records to associate a cost with the activities and to obtain a preliminary effort value indicating amount of effort for each time interval (Id., ¶ 41, Human resources data 208 may include data regarding a developer's salary. For example, a first developer may be deemed an effective developer and make a low salary, while a second developer that is twice as effective may receive a ten times greater salary, which would mean the first developer may be more effective per unit of money (discloses associating a cost with the developer activities to obtain an effort value (i.e. effectiveness per unit of money)). Moreover, there may be obtained from an entity's human resources department further developer information, including: their position, title, and the product they are developing, attrition, salaries, tenure, etc.), (Id., ¶ 33, In one embodiment, a cognitive training system/recommender program module 380 is stored in memory 350 and implements a model training algorithm that builds the knowledgebase 360 based on developer(s) activities and personal productivity, and product performance/financials over time. The model aggregates data for all developer's of specific development teams as will be described with respect to the method of FIG. 1), (Id., ¶ 62, FIG. 4 shows an example dashboard display 400 providing an operational read-out of productivity index 402 for a particular individual or team, with an indication of example top improvement areas, 410, 420, 430. The dashboard 400, in one embodiment, depicts an operational or benchmarking type approach by indicating comparisons of particular KPI attributes for a developer's team with other teams having average and more productive levels. In particular, data from the outputs of the model algorithms are formatted for display as shown in example dashboard 400 to provide visualizations for example KPI attributes 410 (“Attrition %” attrition rate attribute), 420 (“% Collocated” attribute), and 430 (“$k Cost Compensation per HC” or salary attribute). For example, from the dashboard 400 of FIG. 4, there is depicted for each improvement area 410-430, a developer's team's performance over a historical time period plotted against other teams that may have a similar composition, e.g., an average performing development team or compared against the best performing team. Via the dashboard, a user can track the performance for the displayed KPIs attributes over time can further show whether one individual or team's performance indicator goals have been met. Thus, for first example improvement area 410 (business objective parameter is “per cent attrition”), there is shown a developer's team's performance over a historical time period 411, and showing their performance as compared to a performance 414 averaged across many development teams, and further differentiated against the best performing team 417);
and generating a final effort value for each activity record by applying a trained data model, wherein the trained data model is configured to adjust the preliminary effort value based on contextual metadata included in the activity record (Id., ¶ 36, Based on the input data, the trained system/recommender module 350 takes the KPIs and builds the model that determines which of those KPI would be most predictive and/or important to address to increase productivity. The model learns, over time, which input parameters have the most improved effect on the output parameters for a particular productivity. The machine learning algorithms implemented in the model provides a set of predictive and descriptive data elements at a predetermined confidence level. (discloses trained machine learning model)), (Id., ¶ 58, In one embodiment, given the current and historical data that has been collected from the systems that measure user's behavior and personal productivity and/or product performance, a computer run model is generated that is configured to find which team(s) were most productive, and indicate which attributes (i.e., performance indicators) had the most impact upon the most productive team. In one embodiment, machine learning algorithms (such as multivariate linear models) are trained to establish quantitative relationships between the profiles of most effective development team (data derived from steps 102 and 105) and desired performance objectives (based on the model weights data input by the user at step 116 or determined at 120, FIG. 1). Support vector machines, multilinear models and regression based models can alternatively be trained and applied at step 118 to produce similar results based on the developers' personal and productivity data relating to the product and software product financial data received (discloses generating and adjusting an effort value)), (Id., ¶ 69, In on embodiment, in the computing system of FIG. 3, multivariate linear machine learning algorithms are implemented and the model is continuously updated and trained with most positive outcomes to correlate and learn and recognize the most important attributes (parameters) that most positively increases team productivity. These positive predicting attributes are alternatively referred to as key performance indicators (KPI) and may change over time. Consequently, the recommendations (KPI's) and their target values such as shown in recommendation table 500 of FIG. 5, may be change over time).
Regarding Claims 12-17 and 20, these claims recite substantially the same limitations as stated in claims 2-7 and 10, respectively, and are rejected for the same reasons as stated above.
Regarding Claim 21, Boss anticipates … A computer-readable storage medium storing a program of instructions executable by a machine to perform operations, for assessing labor efficiency of knowledge work, comprising: receiving event data extracted from one or more data sources, the data being related to activities conducted by knowledge workers, to obtain event records, each event record containing the identity of each worker associated with an event, and either a time interval or a point in time when the event occurred (Boss, ¶ 41, Human resources data 208 may include data regarding a developer's salary. For example, a first developer may be deemed an effective developer and make a low salary, while a second developer that is twice as effective (discloses labor efficiency of knowledge work) may receive a ten times greater salary, which would mean the first developer may be more effective per unit of money. Moreover, there may be obtained from an entity's human resources department further developer information, including: their position, title, and the product they are developing, attrition, salaries, tenure, etc.), (Id., ¶ 26, A further program module 330 provides analytics to classify a developer's activity. Such a module 330 provides for a cognitive classification of a developer. In one embodiment, the module may implement or access a cognitive system, e.g., IBM's Watson® Natural Language Classifier and IBM's Watson® Explorer, or like, cognitive search and content analysis platform that may be leveraged to understand the detailed nature of the work each team member performs. In one embodiment, cognitive algorithms are applied to social data, human resources (HR) data and source code management data to determine exact activities performed by person, such as development, testing, product management, support, operations, etc. In one embodiment, this information may be combined with other data to obtain a detailed understanding of how each developer(s) is(are) spending their time on each task and activity. (discloses obtaining event records and identities for each worker)), (Id., ¶ 45, Retuning to FIG. 1, at 105, there are performed methods to cognitively analyze and classify activities by a team member(s) of the development team being evaluated. The cognitive classification enables users to create and understand cognitively, i.e., in detail, what each team member has done. In one embodiment, the system tracks on a periodic basis, e.g., daily, the activities (work) relating to the team member (developer), for example, relating to the code that was checked in by the team member, and how that user interacted and/or communicated, e.g., what was communicated (socially or collaboratively), in the context of development activities, e.g., in a social collaboration network or system, with colleagues while developing code. Such data may be considered unstructured, arrive from varying sources in no defined format, and may include text, speech, or other audio or video format), (Id., ¶ 79, The present invention may be a system, a method, and/or a computer program product at any possible technical detail level of integration. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention), (Id., ¶ 24, Computing system 300 includes at least a processor 302, a memory 304, e.g., for storing an operating system and program instructions, a network interface 306, a display device 308, an input device 309, and any other features common to a computing device. In some aspects, computing system 300 may, for example, be any computing device that is configured to communicate with a social media web-site 320 or web- or cloud-based server (not shown) over a public or private communications network 99);
generating activity records associated with the time intervals during a time period from the event records, the activity records containing information about the events that occurred during the time intervals, each activity record including contextual metadata indicative of a task classification, a worker identifier, and at least one of an activity type and a task complexity (Id., ¶ 47, The interaction data and developer's activities, obtained at step 105, FIG. 1, may be combined to make various determinations relating to the developer and that developer's team. For example, the analysis methods determine how a developer's day(s) is(are) spent, e.g., whether/when and how often new code was checked in, (discloses generating activity records based on the event records) whether a developer was chatting with colleagues all day, or was given free coffee or tea, etc. This determination may be combined with other data obtained from the productivity reservoir or repository 250. For example, the developer's delivery of code may be combined with that developer's financial and other personal information and/or product financial information, e.g., revenue, and used to classify the developer's productivity. There is a trade-off between various activities the developer can be engaged in. For example, a developer who does nothing else during the day but generate lines of code would have one classification or role assigned, while a developer that develops efficient algorithms that reduces lines of code yet takes a lot of daily work breaks and/or is more interactive or collaborative may be assigned a different role or classification), (Id., ¶ 38, FIG. 2 shows a linking of the various data sources 200 providing data and metadata for the tool to ingest and provide recommendations for improving productivity from the developers of the software development team. The data sources provide structured and unstructured data/metadata that is input and stored in a storage device, i.e., a productivity data reservoir 250. In one embodiment, the data/metadata is stored in the form of one or more productivity matrices (not shown) in the productivity data reservoir 250. More specifically, the productivity data reservoir is created by ingesting and transforming data and metadata for key product performance metrics across the company or like entity), (Id., ¶ 26, A further program module 330 provides analytics to classify a developer's activity (discloses task classifications) Such a module 330 provides for a cognitive classification of a developer. In one embodiment, the module may implement or access a cognitive system, e.g., IBM's Watson® Natural Language Classifier and IBM's Watson® Explorer, or like, cognitive search and content analysis platform that may be leveraged to understand the detailed nature of the work each team member performs. In one embodiment, cognitive algorithms are applied to social data, human resources (HR) data and source code management data to determine exact activities performed by person, such as development, testing, product management, support, operations, etc. In one embodiment, this information may be combined with other data to obtain a detailed understanding of how each developer(s) is(are) spending their time on each task and activity), (Id., Fig. 2, figure depicts metadata including a worker identifier and activity type (i.e. software changes));
PNG
media_image1.png
331
406
media_image1.png
Greyscale
allocating work effort based on the time intervals from the activity records to associate a cost with the activities and to obtain a preliminary effort value indicating amount of effort for each time interval (Id., ¶ 41, Human resources data 208 may include data regarding a developer's salary. For example, a first developer may be deemed an effective developer and make a low salary, while a second developer that is twice as effective may receive a ten times greater salary, which would mean the first developer may be more effective per unit of money (discloses associating a cost with the developer activities to obtain an effort value (i.e. effectiveness per unit of money)). Moreover, there may be obtained from an entity's human resources department further developer information, including: their position, title, and the product they are developing, attrition, salaries, tenure, etc.), (Id., ¶ 33, In one embodiment, a cognitive training system/recommender program module 380 is stored in memory 350 and implements a model training algorithm that builds the knowledgebase 360 based on developer(s) activities and personal productivity, and product performance/financials over time. The model aggregates data for all developer's of specific development teams as will be described with respect to the method of FIG. 1), (Id., ¶ 62, FIG. 4 shows an example dashboard display 400 providing an operational read-out of productivity index 402 for a particular individual or team, with an indication of example top improvement areas, 410, 420, 430. The dashboard 400, in one embodiment, depicts an operational or benchmarking type approach by indicating comparisons of particular KPI attributes for a developer's team with other teams having average and more productive levels. In particular, data from the outputs of the model algorithms are formatted for display as shown in example dashboard 400 to provide visualizations for example KPI attributes 410 (“Attrition %” attrition rate attribute), 420 (“% Collocated” attribute), and 430 (“$k Cost Compensation per HC” or salary attribute). For example, from the dashboard 400 of FIG. 4, there is depicted for each improvement area 410-430, a developer's team's performance over a historical time period plotted against other teams that may have a similar composition, e.g., an average performing development team or compared against the best performing team. Via the dashboard, a user can track the performance for the displayed KPIs attributes over time can further show whether one individual or team's performance indicator goals have been met. Thus, for first example improvement area 410 (business objective parameter is “per cent attrition”), there is shown a developer's team's performance over a historical time period 411, and showing their performance as compared to a performance 414 averaged across many development teams, and further differentiated against the best performing team 417);
and generating a final effort value for each activity record by applying a trained machine learning model, wherein the trained machine learning model is configured to adjust the preliminary effort value based on contextual metadata included in the activity record (Id., ¶ 36, Based on the input data, the trained system/recommender module 350 takes the KPIs and builds the model that determines which of those KPI would be most predictive and/or important to address to increase productivity. The model learns, over time, which input parameters have the most improved effect on the output parameters for a particular productivity. The machine learning algorithms implemented in the model provides a set of predictive and descriptive data elements at a predetermined confidence level. (discloses trained machine learning model)), (Id., ¶ 58, In one embodiment, given the current and historical data that has been collected from the systems that measure user's behavior and personal productivity and/or product performance, a computer run model is generated that is configured to find which team(s) were most productive, and indicate which attributes (i.e., performance indicators) had the most impact upon the most productive team. In one embodiment, machine learning algorithms (such as multivariate linear models) are trained to establish quantitative relationships between the profiles of most effective development team (data derived from steps 102 and 105) and desired performance objectives (based on the model weights data input by the user at step 116 or determined at 120, FIG. 1). Support vector machines, multilinear models and regression based models can alternatively be trained and applied at step 118 to produce similar results based on the developers' personal and productivity data relating to the product and software product financial data received (discloses generating and adjusting an effort value)), (Id., ¶ 69, In on embodiment, in the computing system of FIG. 3, multivariate linear machine learning algorithms are implemented and the model is continuously updated and trained with most positive outcomes to correlate and learn and recognize the most important attributes (parameters) that most positively increases team productivity. These positive predicting attributes are alternatively referred to as key performance indicators (KPI) and may change over time. Consequently, the recommendations (KPI's) and their target values such as shown in recommendation table 500 of FIG. 5, may be change over time).
Regarding Claim 22, this claim recites substantially the same limitations as stated in claim 10, and is rejected for the same reasons as stated above.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 8-9 and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Boss in view of Mohanty et al., U.S. Publication No. 2023/0066141 [hereinafter Mohanty].
Regarding Claim 8, Boss anticipates …The method as claimed in claim 1…
While suggested in at least Fig. 4 and related text, Boss does not explicitly disclose … further comprising the step of processing the event data to add or change metadata related to each event to obtain preprocessed event data.
However, Mohanty discloses … further comprising the step of processing the event data to add or change metadata to form updated event records (Mohanty, ¶ 96, Referring back to FIG. 4, the activity tracker 214 includes an activity watcher 404 that monitors the various stages (e.g., the plurality of stages 216) of the development of the software product. The activity watcher 404 may be configured to track and monitor user input and actions performed using the service application 112 at each stage (e.g., the define stage 216a, the design stage 216b, the development stage 216c, and deployment stage 216d) of the plurality of stages 216. In other words, the activity watcher 404 is configured to track a plurality of activities executed during the plurality of stages 216 of the development of the software product), (Id., ¶ 77, The user action designer 202 records (e.g., captures) a first plurality of user actions performed by the user on the UI. In other words, the first plurality of user actions include user actions associated with the plurality of stages 216 (e.g., one of the plurality of stages 216) and performed by the user on the UI rendered on the first user device 102a. The user action designer 202 may generate, based on the recorded first plurality of user actions, metadata associated with the first plurality of user actions. The generated metadata may include, but is not limited to, the selection of the first set of operations, the selection of the first technology of the second plurality of technologies, provision of a set of execution parameters for the execution of the first set of operations, or the like. The set of execution parameters (e.g., configuration parameters) may refer to one or more parameters/parameter values provided (e.g., entered) by the user (discloses execution parameter metadata generated by user configuration parameter input) (e.g., the plurality of users) for the execution of the first set of operations. Examples of the execution parameters are provided in later figures. Further, the first plurality of user actions may include any other action performed by the user for the execution of the first set of operations. For example, the first plurality of user actions may include entry of time schedule (discloses event records) (e.g., a start time and/or stop time) for the execution of the first set of operations. The first plurality of user actions may further include provision of one or more parameters (or parameter values) for the execution of the first set of operations. For example, if the first set of operations corresponds to data ingestion, the first plurality of user actions may include one or more user actions associated with a definition of data source from which data is to be extracted, one or more user actions associated with data transformation to be performed on the extracted data, or the like. Similarly, if the first set of operations corresponds to repository management or code commits, the first plurality of user actions may include one or more user actions associated with an entry of an identifier of a repository to which the code is to be committed), (Id., ¶ 78, In an exemplary scenario, the user may select a data source (e.g., comma separated values or CSV file) and a data ingestion technology (e.g., DataBricks®, Hadoop®, or the like) for developing or implementing a data pipeline for the software product. In such a scenario, the generated metadata may be indicative of the selection of the data source (e.g., CSV file) and the data ingestion technology (e.g., DataBricks®, Hadoop®, or the like) for the development of the data pipeline for the software product by the user (e.g., the plurality of users). In another exemplary scenario, the user may select a deployment mode/deployment technology (e.g., Docker®, Kubernetes®, or Terraform®) and a cloud technology (e.g., Microsoft Azure®, Amazon AWS®, or Google Cloud Platform®) for deploying the software product. In such a scenario, the generated metadata may be indicative of the selection of the cloud technology and the deployment mode (e.g., Docker®, Kubernetes®, or Terraform®) by the user for the deployment of the software product. For the sake of brevity, it is assumed that the first plurality of user actions may include the selection of the first set of operations and the first technology 11).
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified the labor efficiency and activity record elements of Boss to include the metadata changing elements of Mohanty in the analogous art of analysis of value stream for software products.
The motivation for doing so would have been to provide “improved tracking of development of software products” (Mohanty, ¶ 5), wherein such improvements would benefit Boss’ method which seeks to provide “a computer-implemented method for improving the effectiveness and efficiency of software development operations” [Mohanty, ¶ 5; Boss, ¶ 6].
Regarding Claim 9, the combination of Boss and Mohanty discloses…The method as claimed in claim 8…
While suggested in at least Fig. 4 and related text, Boss does not explicitly disclose …wherein the step of generating activity records is performed with the updated event records.
However, Mohanty discloses … wherein the step of generating activity records is performed with the updated event records (Mohanty, ¶ 78, In an exemplary scenario, the user may select a data source (e.g., comma separated values or CSV file) and a data ingestion technology (e.g., DataBricks®, Hadoop®, or the like) for developing or implementing a data pipeline for the software product. In such a scenario, the generated metadata may be indicative of the selection of the data source (e.g., CSV file) and the data ingestion technology (e.g., DataBricks®, Hadoop®, or the like) for the development of the data pipeline for the software product by the user (e.g., the plurality of users). In another exemplary scenario, the user may select a deployment mode/deployment technology (e.g., Docker®, Kubernetes®, or Terraform®) and a cloud technology (e.g., Microsoft Azure®, Amazon AWS®, or Google Cloud Platform®) for deploying the software product. In such a scenario, the generated metadata may be indicative of the selection of the cloud technology and the deployment mode (e.g., Docker®, Kubernetes®, or Terraform®) by the user for the deployment of the software product. For the sake of brevity, it is assumed that the first plurality of user actions may include the selection of the first set of operations and the first technology 11), (Id., ¶ 79, The user action designer 202 stores, in the user action catalog 203, the metadata associated with the first plurality of user actions. The user action script compiler 204 may generate a first set of user action scripts based on the metadata stored in the user action catalog 203. (discloses calculating activity records with the preprocessed event data obtained through metadata changes) The generated first set of user action scripts may include data, application program interfaces (APIs), code, database scripts, configuration files, or the like that correspond to the metadata. In one example, the first set of user action scripts may be indicative of defined ideas, features, and/or business requirements for documentation of the define stage 216a of the product development of the software product. In another example, the first set of user action scripts may be indicative of one or more UI design mock-ups for designing different facets of the software product. In another example, the first set of user action scripts may be indicative of the selection of a data source (e.g., a CSV file) and a data ingestion technology (e.g., Databricks®) for an implementation of the data pipeline. The first set of user action scripts may correspond to a format or a programming language (e.g., a proprietary language, an open-source language, or the like) natively supported by the service application 112).
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified the labor efficiency and activity record elements of Boss to include the metadata changing elements of Mohanty in the analogous art of analysis of value stream for software products for the same reasons as stated for claim 8.
Regarding Claims 18-19, these claims recite substantially the same limitations as stated in claims 8-9, respectively, and are rejected for the same reasons as stated above.
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.
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Dyer et al., U.S. Publication No. 2017/0301039 discloses devices, systems, and methods of activity-based monitoring and incentivization.
Silverstein et al., U.S. Publication No. 2022/0012666 discloses a system and method for optimum alternative recommendation for personal productivity efficiency.
Fanning et al., U.S. Publication No. 2024/0095027 discloses a software development quality assessment.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NICHOLAS D BOLEN whose telephone number is (408)918-7631. The examiner can normally be reached Monday - Friday 8:00 AM - 5:00 PM PST.
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, Patty Munson can be reached at (571) 270-5396. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/NICHOLAS D BOLEN/ Examiner, Art Unit 3624 /PATRICIA H MUNSON/Supervisory Patent Examiner, Art Unit 3624
Prosecution Insights