DETAILED ACTION
This is a non-final, first office action on the merits. Claims 1-20 are pending. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. Specifically, claims 1-20 are directed to an abstract idea without additional elements amounting to significantly more than the abstract idea.
With respect to Step 2A Prong One of the framework, claims 1, 7, and 13 recite an abstract idea. Claims 1, 7, and 13 include “receive a request for completing one or more projects, wherein the request includes one or more features assigned for each project; communicate to one or more developers that are selected a project workflow to complete the one or more projects, wherein the project workflow is generated based on an optimization of one or more parameters for timely completing the projects; determine an average time interval taken to complete each project; and update the project workflow based on the average time interval determined”.
The limitations above recite an abstract idea under Step 2A Prong One. More particularly, the elements above recite mental processes-concepts performed in the human mind (including an observation, evaluation, judgment, opinion) and certain methods of organizing human activity-managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions) because the elements describe a process for managing one or more projects. As a result, claims 1, 7, and 13 recite an abstract idea under Step 2A Prong One.
Claims 2-6, 8-12, and 14-20 further describe the process for managing one or more projects. As a result, claims 2-6, 8-12, and 14-20 recite an abstract idea under Step 2A Prong One for the same reasons as stated above with respect to claims 1, 7, and 13.
With respect to Step 2A Prong Two of the framework, claims 1, 7, and 13 do not include additional elements that integrate the abstract idea into a practical application. Claims 1, 7, and 13 include additional elements that do not recite an abstract idea under Step 2A Prong One. The additional elements of claims 1, 7, and 13 include a processor, a memory, a computer readable storage medium, a software, and a computer. When considered in view of the claim as a whole, the additional elements do not integrate the abstract idea into a practical application because the additional computing elements are generic computing elements that are merely used as a tool to perform the recited abstract idea. As a result, claims 1, 7, and 13 do not include additional elements that integrate the abstract idea into a practical application under Step 2A Prong Two.
Claims 3-6, 9-12, and 15-20 do not include any additional elements beyond those recited with respect to claims 1, 7, and 13. As a result, claims 3-6, 9-12, and 15-20 do not include additional elements that integrate the abstract idea into a practical application under Step 2A Prong Two for the same reasons as stated above with respect to claims 1, 7, and 13.
Claims 2, 8, and 14 include additional elements that do not recite an abstract idea under Step 2A Prong One. The additional elements of claims 2, 8, and 14 include pieces of code that implement functionalities. When considered in view of the claims as a whole, the additional elements do not integrate the abstract idea into a practical application because the additional computing elements do no more than generally link the use of the recited abstract idea to a particular technological environment. As a result, claims 2, 8, and 14 do not include additional elements that integrate the abstract idea into a practical application under Step 2A Prong Two.
With respect to Step 2B of the framework, claims 1, 7, and 13 do not include additional elements amounting to significantly more than the abstract idea. As noted above, claims 1, 7, and 13 include additional elements that do not recite an abstract idea under Step 2A Prong One. The additional elements of claims 1, 7, and 13 include a processor, a memory, a computer readable storage medium, a software, and a computer. The additional elements do not amount to significantly more than the abstract idea because the additional computing elements are generic computing elements that are merely used as a tool to perform the recited abstract idea. Further, looking at the additional elements as an ordered combination adds nothing that is not already present when considering the additional elements individually. As a result, independent claims 1, 7, and 13 do not include additional elements that amount to significantly more than the abstract idea under Step 2B.
Claims 3-6, 9-12, and 15-20 do not include any additional elements beyond those recited with respect to claims 1, 7, and 13. As a result, claims 3-6, 9-12, and 15-20 do not include additional elements that amount to significantly more than the abstract idea under Step 2B for the same reasons as stated above with respect to claims 1, 7, and 13.
Claims 2, 8, and 14 include additional elements that do not recite an abstract idea under Step 2A Prong One. The additional elements of claims 2, 8, and 14 include pieces of code that implement functionalities. The additional elements do not amount to significantly more than the abstract idea because the additional computing elements do no more than generally link the use of the recited abstract idea to a particular technological environment. Further, looking at the additional elements as an ordered combination adds nothing that is not already present when considering the additional elements individually. As a result, claims 2, 8, and 14 do not include additional elements that amount to significantly more than the abstract idea under Step 2B.
Therefore, the claims are directed to an abstract idea without additional elements amounting to significantly more than the abstract idea. Accordingly, claims 1-20 are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Signal per se
Claim 13, the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because claim 13 recites “a computer readable storage medium……” The broadest reasonable interpretation of a claim drawn to a program for causing a computer typically covers forms of non-transitory tangible media and transitory propagating signals per se in view of the ordinary and customary meaning of computer readable media.
Here, as seen on page 8 paragraphs [0093] of Applicant’s specification “the computing system 500 shown in FIG. 5 includes a bus 505 that connects the various components of the computing system 500, one or more processors 510 connected to a memory 515, and at least one storage 520. The processor 510 is an electronic circuit that executes instructions that are passed to it from the memory 515. Executed instructions are passed back from the processor 510 to the memory 515.” As such, the claim is rejected as covering a signal per se, which is not directed towards statutory subject matter. See MPEP 2111.01.
Examiner recommends amending the claim to clearly include a non-transitory tangible media in order to overcome this rejection.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 3-4, 7, 9-10, 13, and 15-16 are rejected under 35 U.S.C. 103 as being unpatentable over Amit et al. (US Pub No. 2022/0122025) (hereinafter Amit et al.) in view of Macbeth et al. (US Pub No. 2007/0299795) (hereinafter Macbeth et al.).
Regarding claims 1, 7, and 13, Amit in view of Macbeth discloses a system for managing one or more projects, the system comprising:
a processor coupled to a memory (see Amit, Fig. 1),
the processor configured to:
receive a request for completing one or more projects, wherein the request includes one or more features assigned for each project (see Amit, para [0014], wherein retrieved information and the received request so as to compute the time estimate for the new software task includes computing, for the given developer, a task completion duration for the tasks completed by the given developer; and para [0042], wherein a single unit of work may comprise a single new system feature for a software project, a single bug fix to correct a bug in the software project or a single refactor for the software project);
(assign) to one or more developers that are selected by the processor, a project workflow to complete the one or more projects, wherein the project workflow is generated based on an optimization, by the processor, of one or more parameters for timely completing the projects (see Amit, paras [0021]-[0022] & [0046], wherein….upon receiving a time estimation request for a new software task assigned to a given developer…….the new software task belongs to a project including one or more of the completed tasks; paras [0063]-[0068], wherein process task time estimation requests 30. Each given task time estimation request 30 for a new task may comprise new task feature variables….A unique new task identifier (ID) 62…A developer ID 64…..An assigned task type 66…..A predicted task size 68….projects (i.e., comprising multiple tasks) and systems; para [0158], wherein enhance task effort estimation model 26. For example, the different models based on different use cases allow the use of transfer learning in order to improve the performance in the problematic use cases using models built on the easier use case; and para [0018], wherein a given parameter includes an identity of a component to be modified in the new software task, and wherein modeling the retrieved information and the received request so as to compute the time estimate for the new software task includes identifying a time when a most recent task including the given component that was completed by the developer);
determine an average time interval taken to complete each project (see Amit, para [0209], wherein analyzing…..duration average distribution (with additional condition of at least 20 same date commits), the average durations 124 were 36 minutes for a developer in the top 10%, 88 minutes for the median and 193 minutes for the slowest 10%. Hence the top 10% are about 5 times faster than the slowest and 2.5 times faster than the median); and
update the project workflow based on the average time interval determined (see Amit, paras [0106]-[0111], [0181], & [0209], wherein updates profiles 60A-E with parameters 62-70, task time estimate 28 and actual task time duration. Updating effort estimation task effort estimation model 26 ……. Each productivity metric 142 can indicate an average duration or a mean duration of tasks performed by the developer (i.e., as indicated by task durations 124 in task profiles 60B and developer IDs 82 in completed task data records 56, wherein processor 50 can match task profiles 60B to completed task data records 56 by matching task IDs 80 to task IDs 120)……The rationale for this metric is that the size of a given task 34 is related to the number of components in the given task. This is because tasks with more components typically require more time to complete, since any update to one of the components may necessitate an update to other components in the tasks.….).
Amit et al. fails to explicitly disclose communicate to one or more developers that are selected by the processor, a project workflow to complete the one or more projects.
Analogous art Macbeth discloses communicate to one or more developers that are selected by the processor, a project workflow to complete the one or more projects (see Macbeth, paras [0020]-[0021], wherein the system can further perform group activity detection and/or prediction together with associated workflows…..Communicate with a group of people engaged in a particular activity….the system can provide support for delegated, shared (e.g., available to multiple users) and group (e.g., applicable to multiple users) tasks. In an example, if a task is delegated from a manager to an employee and/or shared between individuals, the system can enable a real-time view of the status of the task based upon roles); and
Analogous art Macbeth discloses update the project workflow based on the average time interval determined (see Macbeth, paras [0049]-[0050], wherein the workflow can be updated, modified, revised, etc. with respect to the activity information. At 312, workflow tasks, actions and/or resources can be assigned, delegated and/or shared between the identified activity users (e.g., members)…; and para [0100], wherein workflow estimating tools such as, how long would it take to complete, how long would an average person take to complete, or how long would it take a particular person to complete)
Amit directed to a system for deploying a task effort estimation model that was generated from data on previously completed software tasks. Macbeth directed to activity flow that includes interaction with, or assignment of work to, people, devices, or services by a single individual or a group of individuals. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of Amit, regarding the System for Software Development Task Effort Estimation, to have included communicate to one or more developers that are selected by the processor, a project workflow to complete the one or more projects; and update the project workflow based on the average time interval determined because both inventions teach improving quality and/or efficiency of a particular process. Further, the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Regarding claims 3, 9, and 15, Amit in view of Macbeth discloses the system of claim 1, wherein the one or more parameters are based on at least one of an average time taken to complete each stage, a project complexity, and a value of the projects (see Amit, para [0239], wherein the peak in the middle seems to be a tradeoff between the familiarity with the file and task complexity).
Regarding claims 4, 10, and 16, Amit in view of Macbeth discloses the system of claim 1, wherein the average time interval is determined based on a previous timeframe and a current timeframe (see Amit, para [0240], wherein the files in the current commit 34 were compared to the files in the previous commit; and paras [0094]-[0104], wherein where there exists a corresponding ticket data record 54 for a given completed task data record 56 (e.g., where the task ID in the ticket data records matches the task ID in the completed task data record), processor 50 can populate a given task profile 60B with information derived from both of the records……can compute task duration 124 by (a) identifying the developer ID and the commit time in the given completed task data record, (b) identifying the most recent previous completed task data record 56
whose respective developer ID 82 matches the developer ID in the given completed task data record, and (c) subtracting the commit time in the identified completed task data record from the commit time in the given task. In this embodiment, processor 50 may only compute task duration 124 if the commit times in the given and identified completed task data records comprised identical dates (i.e., in order to filter out the task durations that included "non-working hours")).
Claims 2, 8, and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Amit et al. (US Pub No. 2022/0122025) (hereinafter Amit et al.), in view of Macbeth et al. (US Pub No. 2007/0299795) (hereinafter Macbeth et al.), and further in view of Chaar et al. (US Pub No. 2008/0255693) (hereinafter Chaar et al.).
Regarding claims 2, 8, and 14, Amit in view of Macbeth discloses the system of claim 1, wherein the request includes one or more (completed tasks) that implement the one or more features, and wherein the one or more (completed tasks) are reusable pieces of code that implement functionalities of the one or more features assigned for each project (see Amit, para [0022], wherein a code reuse metric for the one or more completed tasks, and wherein the time estimate is based on the computed code reuse metric; para [0119], wherein a code reuse metric 172 indicating how much of the code in the given project comprises reused code. In some embodiments, processor 50 can use code analysis to identify import or other mechanisms of reuse; para [0246], wherein each reuse case helps to differentiate between the code needed to implement the functionality and the code encapsulated in the reused component; and para [0135], wherein extracts data from the retrieved commits, generates a set of feature variables for each of the commits, and stores the generated feature variables to the corresponding completed task data record).
Amit et al. and Macbeth et al. combined fail to explicitly disclose one or more building blocks that implement the one or more features, and wherein the one or more building blocks.
Analogous art Chaar discloses the request includes one or more building blocks that implement the one or more features, and wherein the one or more building blocks (see Chaar, para [0041], wherein reused assets (e.g., reusable blocks of code, including the requirements, instructions and/or links/pointers associated with those reusable blocks of code); and para [0072], wherein the DTD states what tags and attributes are used to describe content in the deliverable, including where each XML tag is allowed and which XML tags can appear within the deliverable. XML tag values are defined and applied to a newly defined XML template for each functional area of a design center).
Amit directed to a system for deploying a task effort estimation model that was generated from data on previously completed software tasks. Chaar directed to determining if a workflow event model for an assembly line in the software factory has been configured. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of Amit, regarding the System for Software Development Task Effort Estimation, to have included the request includes one or more building blocks that implement the one or more features, and wherein the one or more building blocks because both inventions teach improving quality and/or efficiency of a particular process. Further, the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Claims 5-6, 11-12, and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Amit et al. (US Pub No. 2022/0122025) (hereinafter Amit et al.), in view of Macbeth et al. (US Pub No. 2007/0299795) (hereinafter Macbeth et al.), and further in view of Bodin et al. (US Pub No. 2020/0159499) (hereinafter Bodin et al.).
Regarding claims 5, 11, and 17-19, Amit in view of Macbeth discloses the system of claim 1, wherein the processor is further configured to:
provide one or more (productivities) to the one or more developers based on the average time interval determined (see Amit, paras [0184] & [0241], wherein productivity metrics suggested…….Developer familiarity with the project is considered to be influential on productivity. When looking at the same date duration, the average for developers with at most 10 commits in the project is 94 minutes, compared to 93 minutes with above 200 commits (achievable in about one year's work). While new developers in a project might devote more time to training and have easier tasks assigned to them, they may perform their task as developers familiar with the project."); and
Amit et al. and Macbeth et al. combined fail to explicitly disclose provide one or more recommendations to the one or more developers based on the average time interval determined; receive feedback from the one or more developers based on the one or more recommendations provided to them; and generate one or more personalized recommendations for the one or more developers based on the feedback provided by them.
Analogous art Bodin discloses provide one or more recommendations to the one or more developers based on the average time interval determined (see Bodin, para [0062], wherein provide recommendations of best practices for building components, tutorials or other functionality described herein. Several related actions can be invoked as a result of this monitoring process; and para [0183], wherein a user a substantial amount of time, by providing an object or recommendation desired by the user);
Analogous art Bodin discloses receive feedback from the one or more developers based on the one or more recommendations provided to them (see Bodin, para [0201], wherein the recommendation module 3250 and/or recommendation component 3270 can also establish a best practice based on feedback from the team or a global community on a proposed best practice…when there is a team of enterprise developers that are coding a certain project, it is desirable for the code to look the same from all user contributions for future users); and
Analogous art Bodin discloses generate one or more personalized recommendations for the one or more developers based on the feedback provided by them (see Bodin, para [0300], wherein recommendations may also be customized based on other factors, such as the frequency with which a particular recommendation is made. Using the example of FIGS. 4A and 4B, the system may further customize the recommendation 4015 for the first user (i.e., the developer) by showing this recommendation only once even if the system determines the same intent from this same user in the future (e.g., based on a presumption that a developer does not want to be told multiple times). Similarly, the system may further customize the recommendation 4015' for the second user (i.e., the designer) by showing this recommendation every time the system determines this same intent by the user (e.g., based on a presumption that a designer would benefit from this repeated information). In this manner, the recommendations for the two different users are customized to use different frequencies based on the different personas).
Amit directed to a system for deploying a task effort estimation model that was generated from data on previously completed software tasks. Bodin directed to event processing system. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of Amit, regarding the System for Software Development Task Effort Estimation, to have included provide one or more recommendations to the one or more developers based on the average time interval determined; receive feedback from the one or more developers based on the one or more recommendations provided to them; and generate one or more personalized recommendations for the one or more developers based on the feedback provided by them because both inventions teach improving quality and/or efficiency of a particular process. Further, the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Regarding claims 6, 12, and 20, Amit in view of Macbeth discloses the system of claim 5, wherein the processor is further configured to update the project workflow based on the one or more personalized recommendations generated.
Amit et al. and Macbeth et al. combined fail to explicitly disclose further configured to update the project workflow based on the one or more personalized recommendations generated.
Analogous art Bodin discloses further configured to update the project workflow based on the one or more personalized recommendations generated (see Bodin, para [0187], wherein user journey and send the results of the journey to an engineering team for evaluation and correction of any issues or update of components based on the user actions; para [0334], wherein provide a "workflow assistant" recommendation in the IDE based on best practices learned from other apps; and para [0300], wherein recommendations may also be customized based on other factors, such as the frequency with which a particular recommendation is made. Using the example of FIGS. 4A and 4B, the system may further customize the recommendation 4015 for the first user (i.e., the developer) by showing this recommendation only once even if the system determines the same intent from this same user in the future (e.g., based on a presumption that a developer does not want to be told multiple times)).
One of ordinary skill in the art would have recognized that applying the known technique of Bodin would have yielded predictable results and resulted in an improved system for the same reasons as stated above with respect to claim 5.
Conclusion
The prior arts made of record and not relied upon is considered pertinent to applicant's disclosure. (US Pub No. 2024/0005242; US Pub No. 2021/0081859; US Pub No. 2007/0174101; US Pub No. 2006/0111953; US Pub No. 2012/0227044; US Pub No. 2004/0230468; US Pub No. 2011/0071956; US Pub No. 2019/0164086; and RDH Warburton (A time-dependent earned value model for software projects) - International Journal of Project Management, 2011 – Elsevier).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HAFIZ A KASSIM whose telephone number is (571)272-8534. The examiner can normally be reached 9:00 - 5:00 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Rutao Wu can be reached at 571-272-6045. 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.
/HAFIZ A KASSIM/Primary Examiner, Art Unit 3623 12/11/2025