DETAILED ACTION
Preliminary amendment received on April 15, 2024 has been acknowledged. Claim 17 has been cancelled and amendments to claims 1, 3-4, 6-7, 9-10, 12-16 and 18 have been entered. Therefore, claims 1-16 and 18 are pending.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Priority
Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d).
Information Disclosure Statement
The information disclosure statement (IDS) submitted on April 15, 2024 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Objections
Claim 1 is objected to because of the following informalities: Claim 1, line 25 recites:
provision, based on respective determined cycle times of software project files, of guidance to a user regarding respective time required for modification of different portions of a codebase. The word “of” appears to be inadvertently misplaced. Appropriate correction is required.
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-16 and 18-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claim(s) recite(s):
a task data item to be obtained by accessing project management data stored on first memory circuitry associated with the apparatus,
wherein the project management data is indicative of migration of software project tasks through different project phases including an in-progress phase,
wherein the in-progress phase is a phase where actual modifications to code is performed for the software project, and
wherein the task data item comprises: a task identifier indicating a task corresponding to the task data item; and
a task time stamp indicating when the task migrated to the in-progress phase;
a version control data item to be obtained by accessing version control data stored in second memory circuitry associated with the apparatus,
wherein the version control data is indicative of software commits of the software project,
wherein the version control data item relates to one or more a plurality of software commit commits and comprises, for each related software commit:
a commit-specific version control time stamp indicating when the software commit was performed; and
a commit-specific list of software project files that were modified in association with the software commit; [[and]]
responsive to the version control data item being linked to the task data item:
determination of the cycle time of a software project file in a commit-specific list by determination of time duration between the task time stamp and the version control time stamp specific for the commit of the commit-specific list; and
provision, based on respective determined cycle times of software project files, of guidance to a user regarding respective time required for modification of different portions of a codebase.
The steps of the method, as drafted, provide a process that, under its broadest reasonable
interpretation, covers managing personal behavior or interactions between people such as managing task within project management and providing guidance to a user having a required time for modification of code within the project.
If a claim limitation, under its broadest reasonable interpretation, covers managing personal behavior or interactions between people, then it falls within the “Certain Methods of
Organizing Human Activity” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
This judicial exception is not integrated into a practical application. In particular, the claim does not
recite an additional element. As such, there is nothing recited that can be considered a practical
application or significantly more than the judicial exception.
To the extent that provision may be interpreted as an additional element (if interpreted as a
display monitor or screen), then this additional element would also fail to integrate the abstract idea
into a practical application. If the provision step is interpreted to include a computer monitor or
screen, then this is recited at a high‐level of generality (i.e., as a generic device performing a generic
function of displaying) such that it amounts to no more than mere instructions to apply the exception
using a generic computer component.
Accordingly, this additional element does not integrate the abstract idea into a practical
application because it does not impose any meaningful limits on practicing the abstract idea. Similarly, a
computer monitor or screen would not be 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 additional element of a display (such as a computer screen) amounts to no more than
mere instructions to apply the exception using a generic computer component. Mere instructions to
apply an exception using a generic computer component cannot provide an inventive concept.
The claim is patent ineligible.
A similar analysis should have been applied to claim 16 which recites essentially the same
abstract idea as in claim 1. Similarly, the claim does 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 claim is not patent eligible.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-16 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Nystrom et al., “Sciit: Embedding issue tracking in source control management” March 2, 2021 in view of 변강섭 Korean Patent Number KR 100729086 hereinafter Byeon.
As per Claim 1, Nystrom et al. discloses an electronic data-processing apparatus configured for determination of a cycle time in a software project,
wherein the cycle time relates to a software project file in the software project, the apparatus comprising controlling circuitry configured to cause:
a task data item to be obtained by accessing project management data stored on first memory circuitry associated with the apparatus (pg.1, paragraph 3 discusses the product owner creates a new issue using the Gitlab issue tracker interface (Fig. 1a). Sciit detects this and creates a new branch for the issue in the project repository on the server, creates a new markdown file in the directory of the project repository source (as shown backlog in Fig. 1b), adds the file to the index and performs a commit),
wherein the project management data is indicative of migration of software project tasks through different project phases including an in-progress phase (pg.3, paragraph 7 discusses the developer identifies three tasks that must be completed in order to resolve the issue: updating the database schema, modifying a view to include uploading a photo on a claim and extending the user acceptance testing (UAT) suite),
wherein the in-progress phase is a phase where actual modifications to code is performed for the software project (pg.3, discusses this causes Sciit to automatically report the sub-issue as Open (in progress), as shown in Fig. 3b, without further action required by the user. Sciit determines this state change because there is a commit on the feature branch dated newer than when the issue first appeared in a commit on the master branch), and
wherein the task data item comprises:
a task identifier indicating a task corresponding to the task data item (Figure 1c, depicts Git repository metadata of an issue with a Title and ID: Photo Upload on Claim); and
a task time stamp indicating when the task migrated to the in-progress phase (Figure 3B, depicts the Status: Open (In Progress) and pg.2, paragraph 7 discusses As soon as a commit is made to the branch for the issue it becomes marked by Sciit as in progress…Sciit determines this state change because there is a commit on the feature branch dated newer than when the issue first appeared in a commit on the master branch);
a version control data item to be obtained by accessing version control data stored in second memory circuitry associated with the apparatus (pg.6, paragraph 1, discusses The library has two main functions: maintaining a cache of issue snapshots as commits are added to the repository),
wherein the version control data is indicative of software commits of the software project (Figure 4, depicts 6 software commits of the ‘photo upload on claim’ project stored within Git),
wherein the version control data item relates to one or more a plurality of software commit commits and comprises (Figure 4, depicts 6 software commits),
for each related software commit:
a commit-specific version control time stamp indicating when the software commit was performed (Figure 4, depicts 6 software commits and Tue Apr 21 14:15-14:22 time stamps); and
a commit-specific list of software project files that were modified in association with the software commit (Figure 4, depicts 6 software commits each with a specific file that was modified for example: 7b16b9ae80a31ba0bc0bc232bf205c625839cf92); [[and]]
responsive to the version control data item being linked to the task data item:
determination of the cycle time of a software project file in a commit-specific list by determination of time duration between the task time stamp and the version control time stamp specific for the commit of the commit-specific list (pg.7, paragraph 1 discusses The implementation time of closed issues can be calculated as the time difference between the first and last commits for an issue).
However, Nystrom fails to disclose provision, based on respective determined cycle times of software project files, of guidance to a user regarding respective time required for modification of different portions of a codebase.
Byeon teaches provision, based on respective determined cycle times of software project files, of guidance to a user regarding respective time required for modification of different portions of a codebase (pg.6, paragraph 6, discusses a project management server that generates and displays a project progress report based on the project progress schedule prepared by agreement between the manager and the developers of the source code, the detailed function implementation plan for each development stage, and the development document file and estimated workload list for each developer's task objective).
The cited portion of Byeon teaches where a project progress schedule is generated based on each stage of the project plan.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have the ability to calculate an amount of time to complete a portion of a project as in the improvement discussed in Byeon in the system executing the method of Nystrom. As in Byeon, it is within the capabilities of one of ordinary skill in the art to calculate an estimated time to complete a portion of code to the issue tracking tool with the predicted result of calculating an amount of time needed to complete a task as needed in Nystrom et al.
As per Claim 2, Nystrom et al. discloses the apparatus of claim 1, wherein the controlling circuitry is further configured to cause the cycle time of the software project file to be stored in third memory circuitry (pg.8, paragraph 3, discusses many projects that employ distributed version control still maintain a single common team repository, often deployed on a service such as Gitlab).
As per Claim 3, Nystrom discloses the apparatus of claim 1, wherein the controlling circuitry is further configured to cause linking of the version control data item to the task data item when the software commits of the version control data item are performed for the task corresponding to the task data item (pg.3, paragraph 2 discusses the product owner creates a new issue using the Gitlab issue tracker interface (Fig. 1a). Sciit detects this and creates a new branch for the issue in the project repository on the server, creates a new markdown file in the directory of the project repository source (as shown backlog in Fig. 1b), adds the file to the index and performs a commit).
As per Claim 4, Nystrom discloses he apparatus of claim 1, wherein the controlling circuitry is further configured to cause linking of the version control data item to the task data item when the version control data item pertains to the task identifier of the task data item (pg.3, paragraph 4 discusses Sciit ensures that all issues in a commit have a unique ID and rejects any commits where two issues in the code base have the same ID... the new issue command gives the same name, in this case claim, to the feature branch to assist with workflow tracking photo-upload-on-claim, to the feature branch to assist with workflow tracking).
As per Claim 5, Nystrom discloses the apparatus of claim 4, wherein the version control data item pertaining to the task identifier of the task data item comprises one or more of:
the task identifier appearing in a code comment of a software project file in a commit- specific list of the version control data item (Figure 4, depicts comments made by developer which states: Extend existing claim user stories with scenarios that include photo upload);
the task identifier being indicated for a version control branch comprising the one or more software commit of the version control data item; and
the task identifier being indicated for a pull request, or a merge request, invoking the one or more software commit of the version control data item1.
As per Claim 6, Nystrom discloses the apparatus of claim 1, wherein the version control time stamp used for the determination of the cycle time of the software project file indicates the last commit of the version control data item that has the software project file in its commit- specific list (Figure 4, depicts the last software commit time as Tue Apr 21 14:22:10 2020).
As per Claim 7, Nystrom discloses the apparatus of claim 1, wherein the controlling circuitry is further configured to cause determination of the cycle time of a software project file in a commit-specific list by determination of contributory time duration between an earlier version control time stamp and the version control time stamp specific for the commit of the commit-specific list, wherein the earlier version control time stamp is specific for a commit which is indicated by the version control data item (Figure 4, depicts earlier software commit times).
As per Claim 8, Nystrom discloses the apparatus of claim 7, wherein the earlier version control time stamp is specific for a commit which is directly previous to that of the commit-specific list (Figure 4, depicts earlier software commits).
As per Claim 9, Nystrom et al., discloses the apparatus of claim 7, wherein the controlling circuitry is further configured to cause, for a software project file, determination of contributory time duration for a plurality of commits that each have the software project file in their commit-specific list, and determination of the cycle time of the software project file by combination of contributory time durations (pg.4, paragraph 2 discusses the issue tracker also reports the full history of all branches and file paths that the issue resided in during its life-cycle. Supplementary metrics, such as the duration of the issue (the time between the first in progress commit and the issue being closed) are also reported).
As per Claim 10, Nystrom et al., discloses the apparatus of claim 7, wherein the software project file is a first software project file, and the earlier version control time stamp is specific for a commit which has a second software project file in its commit-specific list (Figure 2b, depicts a main issue updated with the dependencies).
As per Claim 11, Nystrom et al. discloses the apparatus of claim 10, wherein modification of the first software project file is conditioned on modification of the second software project file being completed (pg.4, paragraph 1 discusses the feature passes the team’s QA review process and the developer merges the branch into master, which causes the issue to be removed from master. The issue is now marked as Closed (resolved), as shown in Fig. 3d. Alongside the change in status, Sciit also automatically adds a closed time to the issue).
As per Claim 12, Nystrom et al. discloses the apparatus of claim 10, wherein modifications of the first and second software project files are associated with a same developer identity (Figure 1c, depicts metadata that includes timothywstore@googlemail.com as the developer).
As per Claim 13, Nystrom discloses the apparatus of claim 1, wherein the controlling circuitry is further configured to cause determination of an intermediate cycle time for each of a plurality of combinations of task data item and version control data item of the software project, and provide the cycle time of the software project file as a combination of the intermediate cycle times (pg.4, paragraph 2 discusses The issue tracker also reports the full history of all branches and file paths that the issue resided in during its life-cycle).
As per Claim 14, Nystrom discloses the apparatus of claim 1, wherein the controlling circuitry is further configured to cause determination of the cycle time of a software project collection of files as a combination of the cycle times of software project files in the collection (Figure 4 depicts the Duration: 0:06:48).
As per Claim 15, Nystrom et al., discloses the apparatus of claim 1, wherein the version control data item further comprises, for each related software commit, a version identifier indicating the software commit (Figure 4, depicts version identifiers).
As per Claim 16, Nystrom discloses a computer-implemented method for determining a cycle time in a software project, wherein the cycle time relates to a software project file in the software project, the method comprising:
obtaining a task data item by accessing project management data stored on first memory circuitry, (pg.1, paragraph 3 discusses the product owner creates a new issue using the Gitlab issue tracker interface (Fig. 1a). Sciit detects this and creates a new branch for the issue in the project repository on the server, creates a new markdown file in the directory of the project repository source (as shown backlog in Fig. 1b), adds the file to the index and performs a commit),
wherein the project management data is indicative of migration of software project tasks through different project phases including an in-progress phase (pg.3, paragraph 7 discusses the developer identifies three tasks that must be completed in order to resolve the issue: updating the database schema, modifying a view to include uploading a photo on a claim and extending the user acceptance testing (UAT) suite),
wherein the in-progress phase is a phase where actual modifications to code is performed for the software project (pg.3, discusses this causes Sciit to automatically report the sub-issue as Open (in progress), as shown in Fig. 3b, without further action required by the user. Sciit determines this state change because there is a commit on the feature branch dated newer than when the issue first appeared in a commit on the master branch), and
wherein the task data item comprises:
a task identifier indicating a task corresponding to the task data item (Figure 1c, depicts Git repository metadata of an issue with a Title and ID: Photo Upload on Claim); and
a task time stamp indicating when the task migrated to the in-progress phase (Figure 3B, depicts the Status: Open (In Progress) and pg.2, paragraph 7 discusses As soon as a commit is made to the branch for the issue it becomes marked by Sciit as in progress…Sciit determines this state change because there is a commit on the feature branch dated newer than when the issue first appeared in a commit on the master branch);
a version control data item to be obtained by accessing version control data stored in second memory circuitry associated with the apparatus (pg.6, paragraph 1, discusses The library has two main functions: maintaining a cache of issue snapshots as commits are added to the repository),
wherein the version control data is indicative of software commits of the software project (Figure 4, depicts 6 software commits of the ‘photo upload on claim’ project stored within Git),
wherein the version control data item relates to one or more a plurality of software commit commits and comprises (Figure 4, depicts 6 software commits),
for each related software commit:
a commit-specific version control time stamp indicating when the software commit was performed (Figure 4, depicts 6 software commits and Tue Apr 21 14:15-14:22 time stamps); and
a commit-specific list of software project files that were modified in association with the software commit (Figure 4, depicts 6 software commits each with a specific file that was modified for example: 7b16b9ae80a31ba0bc0bc232bf205c625839cf92); [[and]]
responsive to the version control data item being linked to the task data item:
determination of the cycle time of a software project file in a commit-specific list by determination of time duration between the task time stamp and the version control time stamp specific for the commit of the commit-specific list (pg.7, paragraph 1 discusses The implementation time of closed issues can be calculated as the time difference between the first and last commits for an issue).
However, Nystrom fails to disclose provision, based on respective determined cycle times of software project files, of guidance to a user regarding respective time required for modification of different portions of a codebase.
Byeon teaches provision, based on respective determined cycle times of software project files, of guidance to a user regarding respective time required for modification of different portions of a codebase (pg.6, paragraph 6, discusses a project management server that generates and displays a project progress report based on the project progress schedule prepared by agreement between the manager and the developers of the source code, the detailed function implementation plan for each development stage, and the development document file and estimated workload list for each developer's task objective).
The cited portion of Byeon teaches where a project progress schedule is generated based on each stage of the project plan.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have the ability to calculate an amount of time to complete a portion of a project as in the improvement discussed in Byeon in the system executing the method of Nystrom. As in Byeon, it is within the capabilities of one of ordinary skill in the art to calculate an estimated time to complete a portion of code to the issue tracking tool with the predicted result of calculating an amount of time needed to complete a task as needed in Nystrom et al.
As per Claim 18, Nystrom discloses a computer program product comprising a non-transitory computer readable medium, having thereon a computer program comprising program instructions, the computer program being loadable into a processing unit and configured to cause execution of the method according to claim 16 when the computer program is run by the processing unit (pg.1, discloses Current software version 2.1.2).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Sturtevant et al., U.S. Patent Application Publication 2017/0235569 discusses an interrelated set of tools and methods is disclosed for: (1) measuring the relationship between software source code attributes (such as code quality, design quality, test quality, and complexity metrics) and software economics outcome metrics (such as maintainability, agility, and cost) experienced by development and maintenance organizations, (2) using this information to project or estimate the level of technical debt in a software codebase, (3) using this information to estimate the financial value of efforts focused on improving the codebase (such as rewriting or refactoring), and (4) using this information to help manage a software development effort over its lifetime so as to improve software economics, business outcomes, and technical debt while doing so. Abstract
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ASHFORD S HAYLES whose telephone number is (571)270-5106. The examiner can normally be reached M-F 6AM-4PM with Flex.
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, Fahd Obeid can be reached at 5712703324. 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.
/ASHFORD S HAYLES/Primary Examiner, Art Unit 3627
1 The Examiner notes, the italicized portions of the above claim is used to denote intended use and are given little patentable weight. The subject matter of a properly construed claim is defined by the terms that limit its scope. It is this subject matter that must be examined. As a general matter, the grammar and intended meaning of terms used in a claim will dictate whether the language limits the claim scope. Language that suggests or makes optional but does not require steps to be performed or does not limit a claim to a particular structure does not limit the scope of a claim or claim limitation.